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
--