Re: [Json] [Technical Errata Reported] RFC7158 (3907)

["Paul E. Jones" <[e-mail]>]

Tim,

Yeah, I saw that.  However, I still think this only opens the door for 
future implementations to produce things that do not work reliably.  As 
Marc Lehmann rightfully pointed out (and, BTW, his Errata text appears 
to have disappeared), a serializer that is requested to serialize a 
series of integers like 1 and 999 might produce 1999.  Reading that back 
in, the single value 1999 would be read.  Likewise, a serializer might 
produce truefalse as output, but then fail when one tries to read that 
back.  One might argue to start all serialization with whitespace to 
avoid having values serialized adjacent to each other.  That would work, 
but unfortunate.

Maybe I missed it, but I could not see _why_ the change was made to this 
production.  What was wrong with allowing only an object or array?

Looking at some of the messages hanging off of the link Björn provided, 
I can see people are worried, too, about the BOM.  The previous text 
made it very clear how to determine whether the text is UTF-16LE or 
UTF-16BE, for example.  That text seems to have disappeared.  Is there a 
reason?  I think the same approach spelled out in Section 3 of RFC 4627 
would still work, no?

Paul

------ Original Message ------
From: "Tim Bray" <[e-mail]>
To: "Paul E. Jones" <[e-mail]>
Cc: "Bjoern Hoehrmann" <[e-mail]>; "RFC Errata System" 
<[e-mail]>; "Pete Resnick" <[e-mail]>; 
"Paul Hoffman" <[e-mail]>; "[e-mail]" <[e-mail]>; 
"Matthew Miller" <[e-mail]>; "Barry Leiba" 
<[e-mail]>; [e-mail]
Sent: 3/4/2014 12:27:51 PM
Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907)

>On this issue, also please read the interoperability note in the 
>paragraph before the new production.
>
>
>On Tue, Mar 4, 2014 at 6:17 AM, Paul E. Jones <[e-mail]> 
>wrote:
>>I've not been following the list closely, as I thought this was more 
>>of an editorial exercise than anything else.  This is definitely more 
>>than editorial.  This could definitely break things and the commenter 
>>is right that there are instances where there could be 
>>misinterpretation.
>>
>>Why was it decided to change this:
>>
>>     JSON-text = object / array
>>
>>to
>>
>>     JSON-text = ws value ws
>>
>>Was there some misunderstanding of what 4627 said?
>>
>>Paul
>>
>>
>>------ Original Message ------
>>From: "Bjoern Hoehrmann" <[e-mail]>
>>To: "RFC Errata System" <[e-mail]>
>>Cc: [e-mail]; [e-mail]; [e-mail]; 
>>[e-mail]; [e-mail]; [e-mail]; 
>>[e-mail]; [e-mail]
>>Sent: 3/2/2014 4:31:07 PM
>>Subject: Re: [Json] [Technical Errata Reported] RFC7158 (3907)
>>
>>>* RFC Errata System wrote:
>>>>Since RFC7158 breaks compatibility with the specifications, this 
>>>>should be
>>>>duly noted.
>>>
>>>It is in Appendix A., "Changes from RFC 4627":
>>>
>>>    o Changed the definition of "JSON text" so that it can be any JSON
>>>       value, removing the constraint that it be an object or array.
>>>
>>>Failing to note this in the Introduction is not ideal, but the errata
>>>system is not a good place to record that (holding it for document 
>>>up-
>>>date probably does not make sense, if and when the document does get
>>>updated, this particular issue will not require prominent notice).
>>>--
>>>Björn Höhrmann · mailto:[e-mail] · 
>>>http://bjoern.hoehrmann.de
>>>Am Badedeich 7 · Telefon: [phone] · 
>>>http://www.bjoernsworld.de
>>>25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · 
>>>http://www.websitedev.de/
>>>
>>>_______________________________________________
>>>json mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/json
>>
>