Re: [secdir] secdir review of draft-ietf-json-text-sequence-11

[Carl Wallace <[e-mail]>]

On 12/16/14, 2:37 PM, "Nico Williams" <[e-mail]> wrote:

><snip>
>Although such an encoder is not considered in the I-D, we could add some
>text about it.  I'd rather say: don't do that, always encode the JSON
>texts to encode the JSON text sequence.
>><snip>>Of course a properly functioning encoder on a properly function
>>system
>> >is in a position to terminate each element.  How can this be in doubt?
>> 
>> The JSON text encoder may be on one system and the JSON text sequence
>> encoder may be on another system (one of the examples in the draft is
>>for
>> logs, so this must already be assumed as possible). In the example
>>above,
>> if the text encoder fails after sending 123, the text sequence encoder
>> will add an <LF> and a decoder will not detect truncation. How can this
>>be
>> in doubt?
>
>It's not.  I just don't think one should encode JSON text sequences this
>way.  After lunch I'll propose text explicitly requiring sequence
>encoders to also invoke the JSON text encoder.

Most of the words in this now very long thread stem from this. I will wait
to review new text. I don’t think there is any lack of clarify on the
signature issue. Most of the remainder is related to the document’s
recognition of <RS>123<RS> as a detachable truncation problem but not
<RS>123<LF><RS> where the truncation occurred prior to invoking the
sequence encoder.