Subject: [Cbor] Glitch in cddl-control AUTH48

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Dec 2021 22:12:33 +0100

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 [email-masked] 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 <[email-masked]>
> Date: 2021-12-04 at 17:00:03 CET
> To: <[email-masked]>
> Cc: [email-masked], [email-masked], Christian Amsüss <[email-masked]>, [email-masked]
> Message-Id: <[email-masked]>
> 
[…]
> (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.
[…]

---

From: Ira McDonald <[email-masked]>
Date: Wed, 8 Dec 2021 10:48:10 -0500

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: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Tue, Dec 7, 2021 at 4:12 PM Carsten Bormann <[email-masked]> 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.
>
> 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
> >    '
> 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:
>
> 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
> >    '
> >
> 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 [email-masked] 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.
>
> (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:
> >
> > Cc: [email-masked], [email-masked], Christian Amsüss <
> [email-masked]>, [email-masked]
> > 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 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Dec 2021 14:52:27 -0500

Thanks for posting this, Carsten, and thanks to Ira for a quick
response.  So as not to leave this open ended, I'm going to put a
deadline of 16 Dec on comments.  Lacking objections by then, we will
consider this accepted.  Please speak up now if you have a problem
with it.

Thanks,
Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 16 Dec 2021 12:10:52 -0500

Closing the loop here: Francesca has given her approval to proceed
with publication, based on lack of objection here.

Barry