Re: [Cbor] Glitch in cddl-control AUTH48

[Ira McDonald <[e-mail]>]

Hi Carsten,

+1 to correcting the oversight as you proposae, even in AUTH-48.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*








*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [e-mail]
<[e-mail]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*


On Tue, Dec 7, 2021 at 4:12 PM Carsten Bormann <[e-mail]> wrote:

> Hi,
>
> In the last step (“AUTH48”) before a document like cddl-control becomes an
> RFC, the author(s) are supposed to do a full reread to capture any problems
> that remained hidden during the incremental development of the I-D.
>
> Normally, we find a few editorial problems (which we did; they since have
> been dealt with).
> This time, however, there is also a technical contradiction between an
> illustration (Figure 4) and the normative text that would need to be
> considered in making up the example in the illustration (
>
> Background: cddl-control deliberately allows byte string literals in
> places where text string literals would really make more sense.  The reason
> is that the content of these literals often is specification text (ABNF)
> with embedded newlines, which are much easier to write as byte strings
> (where embedded newlines are allowed in RFC 8610) than as text strings
> (which inherit the JSON syntax that requires replacing every newline with a
> linear \n, creating essentially unreadable source text).  This is
> demonstrated in Figure 2:
>
> >    c = "foo" .cat '
> >      bar
> >      baz
> >    '
> >    ; on a system where the newline is \n, is the same string as:
> >    b = "foo\n  bar\n  baz\n"
> >
> >        Figure 2: An Example of Concatenation of Text and Byte Strings
>
> So we handled that properly for .cat and .det, but it turns out we did not
> for .abnf and .abnfb themselves.  Here, bullet 1 (which mostly is about the
> target and its interpretation) in Section 3 tersely says:
>
> >    The controller string MUST be a text string.
>
> This is not only not what is implemented in the cddl tool (which accepts a
> byte string just fine), it is also directly contradicting Figure 4:
>
> >    oid = bytes .abnfb 'oid
> >    oid = 1*arc
> >    roid = *arc
> >    arc = [nlsb] %x00-7f
> >    nlsb = %x81-ff *%x80-ff
> >    '
> >
> >              Figure 4: Dedenting example: result of first .det
>
> To me, this is an oversight where we simply didn’t update that sentence to
> the more useful way of accepting byte strings just for their better syntax
> handling newlines.  So I am suggesting we change the sentence to:
>
> > The controller MUST be a string.  When a byte string, it MUST be valid
> UTF-8 and is interpreted as the text string that has the same sequence of
> bytes.
>
> … which I’m suggesting as a fix in the excerpt of the AUTH48 processing
> mail copied below.  I apologize for not seeing this earlier.
>
> Our AD Francesca brought to my attention that [e-mail] is not copied
> on AUTH48 processing; I had forgotten that (other WGs do that copying
> habitually).  So I didn’t think to bring this up separately here, which I
> am now doing.
>
> You can find the text that will be published if we do make the last-minute
> change, at the end of the bullet:
>
> https://www.rfc-editor.org/authors/rfc9165.html#section-3-4.1
>
> (Note that this text is an RFC-to-be, not the final RFC, please don’t
> start citing it as an RFC before it has been published.)
>
> Does anybody in the CBOR WG see a technical problem coming up with making
> this last minute fix?  If you see a problem (with implementation or use of
> byte string literals not only in the controller arguments of .cat/.det, but
> also in those of .abnf/.abnfb), please speak up quickly; this is the last
> item standing in the way towards publishing this RFC.
>
> Grüße, Carsten
>
>
>
> > Begin forwarded message:
> >
> > From: Carsten Bormann <[e-mail]>
> > Date: 2021-12-04 at 17:00:03 CET
> > To: <[e-mail]>
> > Cc: [e-mail], [e-mail], Christian Amsüss <
> [e-mail]>, [e-mail]
> > Message-Id: <[e-mail]>
> >
> […]
> > (0)
> > The last sentence in the first bullet in 3 says "The controller string
> MUST be a text string.”.
> > However, the previous section’s example in Figure 4 happens to use a
> byte string literal, and leniently allowing both kinds of strings is also
> what is implemented.
> > I believe loosening this up has the upside of simplifying cases such as
> in Figure 4, and no downside, so I would suggest:
> >
> > OLD:
> > The controller string MUST be a text string.
> > NEW:
> > The controller MUST be a string.  When a byte string, it MUST be valid
> UTF-8 and is interpreted as the text string that has the same sequence of
> bytes.
> […]
>
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor
>