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] 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 <tjh@cryptsoft.com>
To:        "kmip@lists.oasis-open.org" <kmip@lists.oasis-open.org>
Date:        10/25/2012 04:59 PM
Subject:        [kmip] XML and/or JSON
Sent by:        <kmip@lists.oasis-open.org>




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: kmip-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: kmip-help@lists.oasis-open.org




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