This looks good, and the explanation of what's going on (numbers,
'true', 'false' and 'null' lack delimiters) is a useful addition.
One small nit:
'<RS>truefales<RS>' is not two top-level values, 'true',
and 'false'; it is simply not a valid JSON text.
truefales -> truefalse
Thanks,
--David
> On Tue, Dec 09, 2014 at 06:49:35PM +0000, Black, David wrote:
> > > So I think we really do need to say something about top-level numbers
> > > (and true, false, and null), namely: that they must be delimited by
> > > whitespace, that '<RS>1234<RS>' is not a valid sequence element because
> > > the number may have been truncated. (Ditto '<RS>true<RS>', since the
> > > intended text could have been 'trueish', which is invalid of course, but
> > > still.)
> >
> > That would be more robust, as then all JSON texts in a sequence have
> > delimiters and absence of the closing delimiter clearly indicates
> > truncation.
>
> OK.
>
> New section 2.4 text:
>
> While objects, arrays, and strings are self-delimited in JSON texts,
> numbers, and the values 'true', 'false', and 'null' are not. Only
> whitespace can delimit the latter four kinds of values.
>
> Parsers MUST check that any JSON texts that are a top-level number,
> or which might be 'true', 'false', or 'null' include JSON whitespace
> (at least one byte matching the "ws" ABNF rule from RFC7159) after
> that value, otherwise the JSON-text may have been truncated. Note
> that the LF following each JSON text matches the "ws" ABNF rule.
>
> Parsers MUST drop JSON-text sequence elements consisting of
> non-self-delimited top-level values that may have been truncated
> (that are not delimited by whitespace). Parsers can report such
> texts as warnings (including, optionally, the parsed text and/or the
> original octet string).
>
> For example, '<RS>123<RS>' might have been intended to carry the
> top-level number 123.4, but must have been truncated. Similarly,
> '<RS>true<RS>' might have been intended to carry the invalid text
> 'trueish'. '<RS>truefales<RS>' is not two top-level values, 'true',
> and 'false'; it is simply not a valid JSON text.
>
> This is the only place where the ws rule comes up, so merely saying "at
> least one byte matching" it should suffice.
>
> I'm also adding this following the above, based on your comment about
> incremental parsers:
>
> Implementations may produce a value when parsing '<RS>"foo"<RS>'
> because their JSON text parser might be able to consume bytes
> incrementally, and since the JSON text in this case is a
> self-delimiting top-level value, the parser can produce the result
> without consuming an additional byte. Such implementations should
> skip to the next RS byte, possibly reporting any intervening
> non-whitespace bytes.
>
> (yes, I think this should be a 'should', not a 'SHOULD').
>
> Nico
> --
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
