RE: I-JSON Message Format Specification

[Mark Biamonte <Mark.Biamonte@progress.com>]

I updated the proposal for ODATA-828.  I used SHOULD in the proposal instead of RECOMMENDED since it doesn’t look like we use RECOMMENDED anywhere else in the document.

Mark

 

From: Handl, Ralf [mailto:ralf.handl@sap.com]
Sent: Wednesday, October 14, 2015 12:37 PM
To: Mark Biamonte
Cc: Michael Pizzo; odata@lists.oasis-open.org
Subject: RE: I-JSON Message Format Specification

 

Hi Mark,

I think we should call that out. Can you please open a Jira issue for it, or enhance the proposal for ODATA-828?

Thanks in advance!
--Ralf

From: Mark Biamonte [mailto:Mark.Biamonte@progress.com]
Sent: Dienstag, 13. Oktober 2015 18:05
To: Handl, Ralf <ralf.handl@sap.com>; Michael Pizzo <mikep@microsoft.com>; odata@lists.oasis-open.org
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]
Sent: Tuesday, October 13, 2015 3:33 AM
To: Michael Pizzo; Mark Biamonte; odata@lists.oasis-open.org
Subject: RE: I-JSON Message Format Specification

 

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.

--Ralf

From: odata@lists.oasis-open.org [mailto:odata@lists.oasis-open.org] On Behalf Of Michael Pizzo
Sent: Dienstag, 13. Oktober 2015 02:23
To: Mark Biamonte <Mark.Biamonte@progress.com>; odata@lists.oasis-open.org
Subject: [odata] RE: I-JSON Message Format Specification

 

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
Sent: Monday, October 12, 2015 2:22 PM
To: odata@lists.oasis-open.org
Subject: [odata] I-JSON Message Format Specification

 

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.

The draft document contained the following text

Specifications whose messages are specified to be I-JSON messages SHOULD specify the use of a media type of the form "application/XXX+i-json", where XXX is specific to the specification.

This text has been removed in the latest version

·         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