Re: [kmip] XML and/or JSON

From
Bruce Rich <>
Date
2012-10-30T16:27:13+00:00
ID
Thread
Re: [kmip] XML and/or JSON
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.

If we want to entertain the idea of
supporting REST APIs for KMIP, less verbose forms might be more useable.
 For example, a get of a symmetric key could simply be

HTTPS GET /servername.com/KMIP/v1.2/SymmetricKey?UniqueIdentifier=1ed28ea5-2b31-4145-bcf2-36d0756d3890,verbose=n,json

and the response could be

HTTP 200 OK

      {SymmetricKey":[

        {"KeyBlock":[

          {"KeyFormatType":"Raw"},

          {"KeyValue":[

           
{"KeyMaterial":"c8e51523f73d6ee9f40eab7cd06825499d8c0bd0739e1046"}

          ]},

          {"CryptographicAlgorithm":"DES3"},

          {"CryptographicLength":"0x000000a8"}

        ]}

      ]}

Contrast this with a snippet from the
usecases doc that you uploaded on June 6, 2011 (http://www.oasis-open.org/committees/download.php/42410/usecases-formatted-json.txt)

[req_3_1_3_2]

{"tag":"RequestMessage", "value":[

  {"tag":"RequestHeader", "value":[

    {"tag":"ProtocolVersion", "value":[

      {"tag":"ProtocolVersionMajor",
"type":"Integer", "value":"0x00000001"},

      {"tag":"ProtocolVersionMinor",
"type":"Integer", "value":"0x00000000"}

    ]},

    {"tag":"BatchCount", "type":"Integer",
"value":"0x00000001"}

  ]},

  {"tag":"BatchItem", "value":[

    {"tag":"Operation", "type":"Enumeration",
"value":"Get"},

    {"tag":"RequestPayload", "value":[

      {"tag":"UniqueIdentifier", "type":"TextString",
"value":"1ed28ea5-2b31-4145-bcf2-36d0756d3890"}

    ]}

  ]}

]}

[res_3_1_3_2]

{"tag":"ResponseMessage", "value":[

  {"tag":"ResponseHeader", "value":[

    {"tag":"ProtocolVersion", "value":[

      {"tag":"ProtocolVersionMajor",
"type":"Integer", "value":"0x00000001"},

      {"tag":"ProtocolVersionMinor",
"type":"Integer", "value":"0x00000000"}

    ]},

    {"tag":"TimeStamp", "type":"DateTime",
"value":"2009-11-12 10:47:36"},

    {"tag":"BatchCount", "type":"Integer",
"value":"0x00000001"}

  ]},

  {"tag":"BatchItem", "value":[

    {"tag":"Operation", "type":"Enumeration",
"value":"Get"},

    {"tag":"ResultStatus", "type":"Enumeration",
"value":"Success"},

    {"tag":"ResponsePayload", "value":[

      {"tag":"ObjectType", "type":"Enumeration",
"value":"SymmetricKey"},

      {"tag":"UniqueIdentifier", "type":"TextString",
"value":"1ed28ea5-2b31-4145-bcf2-36d0756d3890"},

      {"tag":"SymmetricKey", "value":[

        {"tag":"KeyBlock", "value":[

          {"tag":"KeyFormatType",
"type":"Enumeration", "value":"Raw"},

          {"tag":"KeyValue",
"value":[

            {"tag":"KeyMaterial",
"type":"ByteString", "value":"c8e51523f73d6ee9f40eab7cd06825499d8c0bd0739e1046"}

          ]},

          {"tag":"CryptographicAlgorithm",
"type":"Enumeration", "value":"DES3"},

          {"tag":"CryptographicLength",
"type":"Integer", "value":"0x000000a8"}

        ]}

      ]}

    ]}

  ]}

]}

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"?

Bruce A Rich

brich at-sign us dot ibm dot com

From:      
 Tim Hudson <>

To:      
 ""
<>

Date:      
 10/25/2012 04:59 PM

Subject:    
   [kmip] XML and/or
JSON

Sent by:    
   <>

If you could either reply to me or to the list with
your thoughts on

JSON and/or XML along these lines that would be ideal.

Given this is a topic we have covered off on before I don't think we

need a straw poll - just an indication that there is some support for it.

1) JSON

a) we think it should be supported as an optional encoding format

b) we plan to add this to our implementation

c) object to adding anything other than TTLV format being specified

d) don't have a strong opinion for or against

2) XML

a) we think it should be supported as an optional encoding format

b) we plan to add this to our implementation

c) object to adding anything other than TTLV format being specified

d) don't have a strong opinion for or against

Given that to date the previous times this has been raised and presented

there was insufficient interest or support from the group I haven't

written this up as a formal proposal - just as a description as to what

is involved. There are full examples of the entire test case set online

at http://interop.cryptsoft.com/kmip_uc/
showing the JSON and XML

representation of each request and response message (and the end of each

time step where it is displayed in a range of formats).

This isn't a proposal for a concept - this is actual documentation of

something which has been implemented in multiple products and is in

production use in multiple organisations.

If there is enough interest expressed I will create separate proposals

or a single proposal for review and then a ballot.

Thanks,

Tim.

---------------------------------------------------------------------

To unsubscribe, e-mail: 

For additional commands, e-mail: