OASIS Key Management Interoperability Protocol (KMIP) TC

> If it isn't SHALL be the same value then I think the circumstances under which it can be different and the mechanism whereby the client can meaningfully determine which is the most recent value would need to be well defined.   I’m okay with specifying SHALL. My reason for suggesting SHOULD was to allow (under control of server policy) different values to be returned for dynamic attributes that change during the course of request processing. This would of course be server specific, totally non-standard (in the sense of being unpredictable and going against the SHOULD recommendation), and require the client to have intimate knowledge of what the server is doing. It might be configured in real implementations out of band, or by querying (and understanding) specific vendor extensions.   If the consensus is to specify SHALL, then that’s okay with me.   > This seems more than a little inconsistent with the argument around SQL and SNMP stating that it is reasonable to request a value multiple times. Allowing different values would be different behaviour to SQL (which requires all values to be identical for repeated items), but is consistent with SNMP (which leaves it up to the agent implementation; i.e. allows different values to be returned, but is equally happy with identical values, but doesn’t require it).   -- John

As promised during today's call, here is the proposed change to disallow stuttering clients (snapshot of my editor window for simplicity). Regards, -Robert From: "John Leiseboer" <jleiseboer@bigpond.com> To: "Tim Hudson" <tjh@cryptsoft.com> Cc: "Jon Geater" <Jon.Geater@thales-esecurity.com>, <kmip@lists.oasis-open.org> Date: 07/13/2011 06:29 AM Subject: RE: [kmip] RE: pros and cons for get_attribute alternatives > If it isn't SHALL be the same value then I think the circumstances under which it can be different and the mechanism whereby the client can meaningfully determine which is the most recent value would need to be well defined.   I’m okay with specifying SHALL. My reason for suggesting SHOULD was to allow (under control of server policy) different values to be returned for dynamic attributes that change during the course of request processing. This would of course be server specific, totally non-standard (in the sense of being unpredictable and going against the SHOULD recommendation), and require the client to have intimate knowledge of what the server is doing. It might be configured in real implementations out of band, or by querying (and understanding) specific vendor extensions.   If the consensus is to specify SHALL, then that’s okay with me.   > This seems more than a little inconsistent with the argument around SQL and SNMP stating that it is reasonable to request a value multiple times. Allowing different values would be different behaviour to SQL (which requires all values to be identical for repeated items), but is consistent with SNMP (which leaves it up to the agent implementation; i.e. allows different values to be returned, but is equally happy with identical values, but doesn’t require it).   -- John

As mentioned during the call on Thursday, I'd like to start an informal group working on the new Entity proposal. The group will be modeled after the interop group. We'll have a short (initially recurring) meeting and a separate mailing list. If you are interested in participating, please send me a note. Regards, Denis 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.