Re: [apps-discuss] [Technical Errata Reported] RFC6839 (4367)

[Graham Klyne <[e-mail]>]

On 17/05/2015 02:21, Ned Freed wrote:
>> On 15/05/2015 17:53, Tony Hansen wrote:
>> > There is one more constraint for a file written with utf-8 to use the
>> > encoding of 8bit: the lines are limited to 998 bytes in length (not
>> > counting the CRLF line terminators). See RFC 2045 for details.
>
>> I think that would be a problem for JSON - there's no way (I know of) to break
>> long text strings over multiple lines, so that restriction would rule out very
>> long string values.  So maybe "binary" is the right choice.
>
> The same can be said for XML - multimegabyte XML objects containing no line
> breaks at all are pretty common. And while you can in theory encode text()
> nodes as CDATA, introducing line breaks into XML isn't something you can just
> do and leave the semantics unchanged.
>
> It's also the case that the line terminators in an XML or JSON object may not
> always be CRLF, and thus an object may not be compatible with 7bit or 8bit on
> that basis.
>
> But the fact remains that a lot of XML and JSON objects are 8bit or even 7bit
> compatible. In fact a lot of formats based on XML or JSON are by their nature
> _always_ 8bit or 7bit compatible. And I see some value in pointing that out
> where it's appropriate to do so.
>
> I suppose we could insist on a full rundown of the issues in every
> registration. But do you really think this is a useful thing to do, rather
> than leaving it a judgement call on the part of the person constructing
> the registration?

No, I don't.

I raised the point because I've found that I can construct XML in a way that 
avoids very long lines (YMMV).  But I've noticed in my work with JSON that there 
is no way to encode long string values over multiple lines (even when the 
strings themselves are multiline values).

Checking back... the encoding considerations for +xml in 
https://tools.ietf.org/html/rfc6839#section-4.1 call for 7bit or 8bit for UTF-8, 
and binary for UTF-16/32.  Your comment suggests some UTF-8 encoded XML would 
not satisfy the 8bit constraint on line length, and binary should at least be an 
option there.

And, as noted, https://tools.ietf.org/html/rfc7159#section-11 just says "binary" 
for JSON, which seems OK to me, but as you say 7bit or 8bit might be OK for some 
JSON data.

(I suspect that in practice these concerns don't arise as 7bit and 8bit are 
primarily email concerns, and my experience is that JSON is mostly used in HTTP 
exchanges.)

#g
--