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] TTLV encoding concern


On 28/06/2014 1:35 PM, Featherstone, David wrote:

Tim Hudson wrote:

> What you are actually asking for is an incompatible change to the basic

> encoding used for attributes - not a clarification.

 

Actually, the proposal is completely forward-compatible with existing usage. In fact, the existing encoding (---) and the proposed encoding (+++) could be intermixed in the same KMIP request or response without conflict:


Current servers and clients will not process what you are proposing as a change ... so any change like this would have to go into a later release of the specification - it cannot be handled in KMIP 1.0, 1.1 and 1.2 as specified.
The specification itself doesn't not allow for an attribute to be encoded in that format.

The challenge you face in trying to interpret that into the specification is the attribute structure itself is well defined - and it contains nothing within that text which would permit the sort of encoding you are suggesting.
The text within Custom Attribute is simply making it clear there is no Tag corresponding to a custom attribute - so it you wanted a custom attribute to appear encoded anywhere within the protocol it will always be within an attribute structure.

However (contrasting things) for example a Cryptographic Algorithm is an attribute and is also present within a number of structures outside the context of an attribute encoding - that is what the text is about there.

Tim.


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