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: New ballot "Repeated attributes in Get_Attribute request"


The ballot has now passed (it has reached >50% yes votes with currently 78% of those who voted stating yes).

http://www.oasis-open.org/apps/org/workgroup/kmip/ballot.php?id=2074

There have been a few No votes and a couple of comments which I'm taking this opportunity to further comment on myself.
This is an issue which we have discussed at length in the interop group, raised and discussed in the TC, balloted a range of options, re-discussed at length within the TC, voice voted, and the subsequently changed to this formal ballot. I for one don't know of any other issue which has gone through that sort of path to reach a resolution within the TC.

Repeating the comments from the ballot:

HP: Steven Wierenga
    I believe this is beyond the scope of allowed client request message syntax; it is a worthy
    recommendation for the Usage Guide, but not the Spec. If the proposal is further modified to
    specify only client behavior, but does not further constrain server policy/behavior, I will vote Yes.

Oracle:Hal Lockhart
    I believe the only logical reason for this restriction is the belief that the two attributes are one
    and the same and that the same result will be returned for each. If this is true, I do not see
    why it is necessary to return an error, force the client to reformulate the request and resend
    the request when the server knows from the first "erroneous" request what response is desired.

    If on the other hand you think there are cases where asking for the same attribute more than
    once is sensible, all the more reason not to prohibit it.

Both of these comments I see as related and I think the clear consensus from the group was that the behaviour needs to be specified.
That left three remaining items from the previous ballot to consider and based on discussion the option with the most support within the group formed the item to ballot. It is not the item which a number of members of the TC would have selected - there was vigorous discussion on the merits of each of the options - but it is the option which had the least objections.

Anything in KMIP which impacts practical interoperability needs to be carefully considered - and at the moment TC members have deployed in shipping products a range of behaviours which effectively already force an interoperable client already to never send an attribute more than once as the specification is sufficient open on this topic that a server can currently select any behaviour it wants including rejecting the request.

This is why Cryptsoft has voted to select a behaviour that does not match either of our currently released and shipping server products. Interoperability is the purpose of KMIP and should form the lens through which we all view updates to the specification.

The KMIP specification is about more than message syntax - it defines the semantics of the operations. Anything which is necessary for interoperability belongs within the specification or the profiles documents - the Usage Guide and Use Cases are informative and not normative and if an implementation needs to reference to those documents in order to be interoperable then we will need to address that.

We could of course make the Usage Guide and Use Case documents normative and move them towards being formal OASIS specifications but that is a separate topic.

It is good to see healthy debate on KMIP!

Tim.



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