kmip message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [kmip] XML and/or JSON
- From: Bruce Rich <brich@us.ibm.com>
- To: Tim Hudson <tjh@cryptsoft.com>
- Date: Tue, 30 Oct 2012 11:21:02 -0500
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]