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