RE: [kmip] RE: pros and cons for get_attribute alternatives

[Robert Haas <rha@zurich.ibm.com>]

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