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: Arbitrary Text Strings for Name Spaces


Thanks for the input.  I would like to discuss this on tomorrow's call.


Can you add this to the agenda?


-----Original Message-----
From: Frindell,Alan [mailto:Alan.Frindell@safenet-inc.com] 
Sent: Friday, August 28, 2009 4:27 PM
To: Scott Kipp; 'kmip@lists.oasis-open.org'
Subject: RE: Arbitrary Text Strings for Name Spaces

Hi Scott, I also see the arbitrary nature of application name spaces as a challenge to interoperability.

I would like to see a mechanism for vendors to register the name space they are using and to publish the expected server behavior when a client asks for the server to choose the App Specific Info value.  Other information relevant to server vendors could also be included, such as whether the application expects the value to be unique within the KM, and if it will be used as a primary lookup field by the application.

Is it within the scope of our TC to create and maintain such a registry?  Or is there a more efficient way to handle this problem?



> -----Original Message-----
> From: Scott Kipp [mailto:skipp@Brocade.COM]
> Sent: Thursday, August 27, 2009 11:52 AM
> To: kmip@lists.oasis-open.org
> Subject: [kmip] Arbitrary Text Strings for Name Spaces
> All,
> In the Application Specific Information ballot, I made the
> following comment.
> Problem:
> The application name spaces are arbitrary text strings so
> that new types of application data can be used without
> requiring the standard to be updated.
> Are the text strings arbitrary? We should have tighter
> control over the text strings for interoperability. What
> happens if one client uses "Volume Identification" and
> another uses "Volume ID" and another uses "Vol_ID". Are these
> all unique name spaces?
> Proposed Solution:
> We should enumerate the types of name spaces so that we can
> increase interoperability. Clients should still be able to
> have their own vendor specific name spaces, but common ones
> should be standard.
> Should we address this comment over the reflector?
> Thanks,
> Scott
The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]