kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [kmip] Groups - kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded
- From: Bruce Rich <brich@us.ibm.com>
- To: Tim Hudson <tjh@cryptsoft.com>
- Date: Tue, 2 Jul 2013 11:30:49 -0500
Tim,
I agree that it would be great for the
spec to be clarified in the area of ASI.
Absent that, what does the server mean
when it answers "LIBRARY-LTO" on a Query Application Namespaces
request?
If it means only that the server can
store and retrieve the values that the client(s) sent it, then that's a
trivial thing for a server to do, and if a server supports ASI at all,
then it could support them for all possible namespaces, so it becomes problematic
for the server to answer what namespaces it supports on Query, as it could
support ALL namespaces. The spec says this about "support"
in Query,
The Application Namespace fields in
the response contain the namespaces that the server SHALL 1645
generate values for if requested by
the client (see Section 3.36). These fields SHALL only be returned in 1646
the response if the request contains
a Query Application Namespaces value in the Query Function field. 1647
So it clearly says that a server responding
with a namespace on Query is all about being able to fill in blanks ("generate
values" is not just returning what the client stored). I don't
know why you think this is unclear.
If "support" means more than
just retrieval (possibly that the server knows how to fill in the "information"
part of an ASI attribute, given only the namespace and the key UUID), then
I have yet to see clear specification for how the server figures out what
the ASI value should be. It would have to do it from the information
it has, which is the key material, and the LTO information in the UsageGuide
on calculating the "information" part of an ASI seems to be about
the cartridge/tape label, so the server is the wrong actor to fill this
in. The spec says this about "support" in Application Specific
Information:
Clients MAY request to set (i.e., using
any of the operations that result in new Managed Object(s) on the 1059
server or adding/modifying the attribute
of an existing Managed Object) an instance of this attribute with a 1060
particular Application Namespace while
omitting Application Data. In that case, if the server supports this 1061
namespace (as indicated by the Query
operation in Section 4.25), then it SHALL return a suitable 1062
Application Data value. If the server
does not support this namespace, then an error SHALL be returned. 1063
So this part of the spec (in particular,
line 1061) says that "support" is indicated by the server's response
to Query. I don't know why you think this is unclear. One advertises
that one's server "supports" "generation of values"
if said server replies any namespaces on a Query response.
I think the ASI specification is still
incomplete, but it didn't matter a whole lot until one tries to harden
it in a profile. Now that this profile makes it mandatory to implement,
it is critical to have "it" spelled out, hence my objection to
this profile draft. I think the profile is premature, given the lack
of clarity in the spec.
Or we can simply modify the profile
to take out the part where the server answers "LIBRARY-LTO" on
the Query Application Namespaces (which was my original request).
Otherwise, as the profile now stands,
from what the spec says, the server has committed itself to being able
to "generate values", not just returned stored values, and this
profile does not exercise the "generation" aspect at all.
Bruce A Rich
brich at-sign us dot ibm dot com
From:
Tim Hudson <tjh@cryptsoft.com>
To:
Bruce Rich/Austin/IBM@IBMUS
Cc:
Feather <stan.feather@hp.com>,
kmip@lists.oasis-open.org
Date:
07/01/2013 04:01 PM
Subject:
Re: [kmip] Groups
- kmip-tape-lib-profile-v1 0-wd01-review.doc uploaded
On 2/07/2013 6:42 AM, Bruce Rich wrote:
Tim,
In the larger context that I quoted, it is (more) clear that the server
announcing "support" of this namespace via Query is related to
its ability to fill in the rest of the information if the client sends
only the namespace.
Actually it doesn't state what "support" means at all. And the
definitive text for that should be in the definition of the attribute.
I see what you want it to state - and how to infer that meaning - but that
isn't what the text actually says and other meanings are not reasonably
precluded.
It does not state that you shall not return an application name
space from the query response when the application name space is supported
but the client needs to specify the identifier. The term "support"
has not be exclusively tied to handling Application Data not specified
by the client.
There are numerous errors in the specification text if this is the interpretation
that you expected.
There is also an error in table 120 states Application Data is "Required".
That is an error - as the text clearly states the the Application Data
can be omitted.
Bruce, I think one of the challenges here is that no one so far has actually
put forward any real world example of server-side provided Application
Data values with a name space description and details as to how the server
is meant to provide the value. That use case simple isn't present/visible.
There is use of Application Specific Information in shipping product from
multiple vendors - but not with server provided Application Data values.
Filling in that gap I think would be the right starting point.
Tim.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]