Re: [kmip] XML and/or JSON

[Tim Hudson <tjh@cryptsoft.com>]

On 31/10/2012 2:21 AM, Bruce Rich wrote:

Tim,

I appreciate the ability to roundtrip from JSON<->TTLV<->XML, but it makes for a very verbose, fairly unnatural usage of JSON and XML, at least for those folks wanting to use RESTful patterns.

Having the full expressiveness that TTLV permits can be useful, especially for parsing/composing custom extensions, but for elements composed using standard bits, it makes for verbosity.
And having all the batch stuff in there all the time is also, shall we say, "gorpy"?

If you look at the various usages of JSON and XML in the context of anything which user defined types and an alternate representation existing as a non-text based format you'll see that these are simply issues you have to accept if you want to not make the JSON or XML encoding a limited subtype.

The TC position on this topic was very clearly communicated in that the TTLV encoding was the base and any other encoding would be optional and as long as that remains the position being able to perform a round-trip between the formats effectively becomes a requirement simply because you will need gateways to be able to handle such a bi-directional translation as no matter what gets written into the specification you will end up with clients which only support one of the non-TTLV encodings being produced and such clients will need a gateway to be able to communicate with servers which do not implement the optional encoding formats.

We have taken a pragmatic approach to this in what we have proposed and then implemented so that we could ensure a level of interoperability between encoding formats and to not have any text based format miss out on any of the features or capabilities within the specification - i.e. using JSON and/or XML it should be possible to encoding anything currently allowed within the specification.

If you look at the base TTLV encodings and use register and/or create as examples with a pile of user defined attributes you have a more realistic example to work from. You also do need the entire context of a request and a response - it is not KMIP without those.

I think from your comments you'd find the XML representation closer to your tastes (more naturally readable) but that is a reflection of XML having the element with optional list of attributes concept whereas JSON requires name:value as its handling. Carrying the flexibility of KMIP within JSON requires taking something like the approach outlined.

<RequestMessage>
  <RequestHeader>
    <ProtocolVersion>
      <ProtocolVersionMajor type="Integer" value="1"/>
      <ProtocolVersionMinor type="Integer" value="0"/>
    </ProtocolVersion>
    <BatchCount type="Integer" value="1"/>
  </RequestHeader>
  <BatchItem>
    <Operation type="Enumeration" value="Get"/>
    <RequestPayload>
      <UniqueIdentifier type="TextString" value="1ed28ea5-2b31-4145-bcf2-36d0756d3890"/>
    </RequestPayload>
  </BatchItem>
</RequestMessage>

Comments on "gorpy" with respect to having all the existing request headers and batch infrastructure in place apply equally to the TTLV so I'm not viewing that as an issue which is specific to a different message encoding and perhaps you should propose a review of the base specification message encoding to have short form messages which skip all the current request and response handling. Perhaps a request which contains simply one batch item would be worthwhile exploring to remove any gorpy taint from the specification.

For those interested in comparing formats see http://interop.cryptsoft.com/kmip_uc/group__UC__1__0__3__1__3.html which has this example in it or the entire list of test cases in each format at http://interop.cryptsoft.com/kmip_uc/

Tim.