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: [kmip] Groups - kmip-spec-v1.1-os-bar--re-everything.doc uploaded


On 23/05/2013 1:36 PM, Bruce Rich wrote:
I proposed new behaviors as "SHOULD", which mandates no immediate changes,

I don't think that is an accurate characterisation of the changes - the updates require a number of changes which are not denoted as optional. And suggesting a range of varying behaviours around SHOULD which are not compatible from a base interoperability perspective seems to me at least to be an approach to avoid.

I do think use of SHOULD in this context substantially varies with the existing usage - see the attached document where I've extracted all SHOULD references from the 1.2 draft which helps to see how we have been using SHOULD within the specification to date. That review of existing usage is illustrative.

It is this sort of usage in your proposal "the server SHOULD ignore all others passed by the caller" that is concerning - it makes it clear that a server can elect to process or to not process information passed by the caller and both approaches would be considered acceptable. That level of variability in server processing certainly won't help interoperability.

If we are going to change the ReKey behaviour to alter it to not accept attributes analogous to Create then the new behaviour should be mandatory rather than defining two different (and incompatible) interpretations.

i.e. "the server SHALL ignore all others passed by the caller"

(note: "caller" should be replaced with "client" in each proposed change)

Tim.

Attachment: Use-of-SHOULD.pdf
Description: Adobe PDF document



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