OASIS Key Management Interoperability Protocol (KMIP) TC

Hi Judy,   I wonder, if instead of changing the types for the specified fields, we add new fields with the preferred types, and deprecate use of the old fields? If KMIP 1.0 wasn’t already an approved standard I would have no hesitation in supporting your proposed changes. But it is an approved standard, and there will be implementations using the current types (text strings), and so all future backwards-compatible implementations will have to support them anyway. From an implementation point of view, it might just be easier to keep the old field names, tags and type, add a new parallel set with byte string type, deprecate the old fields, and move forward with the new.   johnl   From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Judith Furlong Sent: Thursday, 6 October 2011 6:16 AM To: kmip@lists.oasis-open.org Subject: [kmip] Groups - KMIP v.1.1 Proposal for Changing Data Type of Certificate Attribute Related Fields from Text Strings to Byte Strings uploaded   Document Name : KMIP v.1.1 Proposal for Changing Data Type of Certificate Attribute Related Fields from Text Strings to Byte Strings Description Proposal for changing the data type of the fields within the Certificate Identifier, Certificate Subject, and Certificate Issuer attributes from Text String to Byte String Download Latest Revision Public Download Link Submitter : Ms. Judith Furlong Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Proposals Date submitted : 2011-10-05 13:13:11  

On 6/10/2011 1:46 PM, John Leiseboer wrote: Hi Judy,   I wonder, if instead of changing the types for the specified fields, we add new fields with the preferred types, and deprecate use of the old fields? If KMIP 1.0 wasn’t already an approved standard I would have no hesitation in supporting your proposed changes. But it is an approved standard, and there will be implementations using the current types (text strings), and so all future backwards-compatible implementations will have to support them anyway. From an implementation point of view, it might just be easier to keep the old field names, tags and type, add a new parallel set with byte string type, deprecate the old fields, and move forward with the new. I think John's suggestion here is a good way to handle things - define new tags for the differently encoded concepts for KMIP 1.1 and 'deprecate' the existing ones - although we will need to handle the concept of the varying attribute names - as given names are referenced by text name rather than tag id in attribute lists we have to have both the old and the new versions of the tag with separate distinct names. I also think that the Serial field in the Device Credential should be renamed to Device Serial and also be allocated a new tag id as it is separate concept that just happens to currently have the same name. Thanks, Tim.