RE: [kmip] Groups - Proposal for Renaming the Application SpecificIdentification attribute v2 (Proposal for Renaming AppSpecID-2.pdf)uploaded

["Fitzgerald, Indra" <indra.fitzgerald@hp.com>]

Hi Rene,

In your proposal you describe how clients can request the server to create the application data for the Application Specific Information attribute. Clients can only specify Application Name Space and omit Application Data. If omitted and the server recognizes the name space, the server will generate the data for the corresponding Application Name Space. If the name space is not recognized by the server and the client omits Application Data, the server is expected to return an error. Similarly, if the attribute is modified and Application Data is removed, the server will either return an error or create new data for the corresponding name space.

I can think of a use case where users may add the attribute, but may not have the Application Data available at this point. Similarly, the Application Data may no longer apply and the client may decide to remove it for now using the Modify Attribute operation without deleting the attribute. Your proposal does not allow for these use cases; the server would be required to return an error if Application Data is not specified or removed, assuming that the server does not recognize the name space.

Application Specific Information is supposed to be a client-specific attribute that should only be set by the client. In the table on page 2 you say that the attribute is initially set by the Client or by the Server if requested by the Client. Even if the server is able to create the Application Data, the attribute is still set by the client and requires clients to explicitly set it using the Add Attribute operation.

If it is a requirement to include server-generated Application Data in the spec, I would propose to allow clients to explicitly set this option instead of relying on implied functionality. Alternatively, if vendors whish to implement this, it could be a vendor-specific implementation.

Regards,
Indra 

-----Original Message-----
From: rpa@zurich.ibm.com [mailto:rpa@zurich.ibm.com] 
Sent: Thursday, June 11, 2009 7:42 AM
To: kmip@lists.oasis-open.org
Subject: [kmip] Groups - Proposal for Renaming the Application Specific Identification attribute v2 (Proposal for Renaming AppSpecID-2.pdf) uploaded

The document revision named Proposal for Renaming the Application Specific
Identification attribute v2 (Proposal for Renaming AppSpecID-2.pdf) has
been submitted by Rene Pawlitzek to the OASIS Key Management
Interoperability Protocol (KMIP) TC document repository.  This document is
revision #3 of Proposal for Renaming AppSpecID.doc.

Document Description:
Purpose: Rename the Application Specific Identification attribute because
the current name does describe the purpose of this attribute accurately. It
can be used for a variety of different purposes and not only for storing
the intended use of a managed object. Thus, the attribute would benefit
from a more generic name.

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=32894

Download Document:  
http://www.oasis-open.org/committees/download.php/32894/Proposal%20for%20Renaming%20AppSpecID-2.pdf

Revision:
This document is revision #3 of Proposal for Renaming AppSpecID.doc.  The
document details page referenced above will show the complete revision
history.


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration