Re: [Curdle] Alexey Melnikov's Discuss on draft-ietf-curdle-ssh-ext-info-12: (with DISCUSS and COMMENT)

[denis bider <[e-mail]>]

Just to be sure, I've uploaded a new version that does contain the extra
explanation as well. Let me know if it's clearer.

On Thu, Sep 14, 2017 at 11:24 AM, Adam Roach <[e-mail]> wrote:

> Ah, okay. I thought I'd asked earlier for an example of nested strings,
> and was interpreting your lack of response as a lack of such thing. If this
> kind of nesting is commonplace for the base protocol, then I'm okay with
> the current formulation. My concern was that this looked like something
> novel, but with only a loosely implied encoding.
>
> I'll clear my discuss. Thanks for the explanation.
>
> /a
>
>
> On 9/14/17 12:16, denis bider wrote:
>
> But seriously, the spec defines the encoding. There needs to be no
> guessing. The definition is right there. The example further fool-proofs so
> there's no excuse for anyone to misunderstand.
>
> Nested strings in SSH are not weird. They are used ubiquitously. For
> example, in public key authentication, the public key is encoded as a
> string. This string itself contains other strings which are part of the
> public key format. This is not unusual. Anyone who works with SSH would be
> familiar with this.
>
> On Thu, Sep 14, 2017 at 8:15 AM, Adam Roach <[e-mail]> wrote:
>
>> On 9/14/17 08:08, denis bider wrote:
>>
>>> Submitted. :-)
>>>
>>
>> Thanks. This newest version includes an example, but no further
>> explanation of the encoding. Normative examples that implementors have to
>> reverse engineer are generally bad for interoperability, since implementors
>> have to guess at the handling for corner cases. Could you please add text
>> that describes the encoding itself? It doesn't need to be overly complex,
>> but it does need to be explained.
>>
>> /a
>>
>
>
>