OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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]