[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: I-JSON Message Format Specification
With regards to the optional seconds for dateTimeOffset and timeOfDay do we need some text like While the dateTimeOffset and timeOfDay data types allow for the seconds component to be omitted, it is RECOMMENDED that OData clients and servers include the seconds component as called
out in I-JSON Message Format for maximum interoperability. Or do we call out somewhere else that it is RECOMMENDED that implementations follow the guidelines provided by the I-JSON Message format for maximum interoperability. I don’t see a statement like that in the
published JSON Format document. Mark
From: Handl, Ralf [mailto:ralf.handl@sap.com] Great summary, thanks! Binary data: we use base64url. The TODO in the ABNF was to add the link to the definition of base64url, this was done with
Errata02.
From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org]
On Behalf Of Michael Pizzo That's great Mark; thanks for the research! I think all of these changes are very much in line with our JSON use within OData. -Mike
From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org]
On Behalf Of Mark Biamonte I compared the
draft-bray-i-json-01 version of I-JSON referenced in the current OData 4.0 specification with the
latest RFC version of I-JSON and found the following substantive differences between the documents
·
Section 2 – removed reference to i-json media type.
·
Section 4 in the new the RFC version was added. The sub-sections of this section define that
o
The top level of the JSON response SHOULD BE either an Object or an Array
o
Defines a Must-Ignore Policy, that is if an implementation encounters an element in the message it does not understand, it MUST ignore that element
o
It is RECOMMENDED that date and time values be represented as string values in ISO 8601 format. Additionally date and time value should use
§
Uppercase Letter
§
Timezone always be included
§
Trailing seconds always be included
o
It is RECOMMENDED that duration conform to the duration production in RFC 3339
o
It is RECOMMENDED that binary data be encoded in a string value using base64url Of these, I think the ABNF defines seconds as optional where as I-JSON recommends that they always be included. I am not sure about the base64URL encoding for binary data . I know we talked about base64url for binary data in the last
meeting, but the ABNF lists base64url as todo. Mark |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]