[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Application Specific Information
Given that this area is underspecified I've taken a walk through attempting to see how it could work. The assumptions as I understand it are: 1) use of ASI is for clients where the unique identifier is unable to be stored for later use in operations 2) server-side allocation of ASI ApplicationData information can only be dependent on information from the certificate or contained within the request message 3) server -side allocation of ASI ApplicationData only occurs during the operations which create objects (that is what is stated in the specification) and it does not otherwise occur. That combination seems to contradict - in that ASI is about clients which cannot store details (otherwise they could simply store the UniqueIdentifier and work from that like non-ASI clients) - but if a client is unable to store values then there is no mechanism for a Locate to be performed for server-side ASI ApplicationData allocation as the creation of the server side values does not occur during locate (only on operations which create objects). This to me at least looks like there is no current mechanism for ASI with server-side to be usable for its intended purpose. This doesn't apply to client-side ASI ApplicationData allocation - that works cleanly and is currently deployed and we now have a profile showing its use in a clear life-cycle. If no one is using it and no one can see how to use it without basically requiring a client to store a value (and in which case it should be storing the UniqueIdentifier and simply not using ASI at all or using Name or Alternative Name under KMIP 1.2) then I think this is open to being able to be safely deprecated in KMIP 1.2 (and then subsequently removed in KMIP 2.x). Others thoughts? Tim.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]