Re: [Cbor] 🔔 WGLC on draft-ietf-cbor-7049bis-09

[Carsten Bormann <[e-mail]>]

Hi Francesca,

thank you for this review.

Some items to consider later:

>> * Section 3.4.7
>> 
>> While reading this again, I realized that CBOR sequences cannot be tagged, as by definition they are not one data item. I think being able to tag CBOR sequence with the self-describing tag in the scenario described in this section would be good.
> 
>    You can tag any single data item in the CBOR sequence.
>    Since CBOR sequences are just concatenated encoded data items, I see no easy way to add some overall information to the sequence itself.
> 
> FP: Right. Maybe this was more of a high level consideration rather than a request to change anything.

Indeed, we should keep this in mind as a limitation/complication of CBOR sequences compared to single CBOR data items.

>> * Section 4.2.2
>> 
>> Second to last sub-bullet: "If a protocol includes a field that can express integers..."
>> 
>> I noted an inconcistency here with the text on preferred encoding preferring using maj types 0 and 1 (see text in section 3.4.4. "The preferred encoding of an integer...")
> 
>    That section has recently been edited, and there are some new edits waiting in #165.
>    I hope to be able to cover this in #165.  The intention is to recommend using the preferred encoding for integers that fit into mt0/1, i.e., basic integers.  But a protocol could deviate, at the cost of requiring more work in the application and possibly the generic codec (which would need to separately handle the non-preferred case).
> 
> FP: The revised text works for me (either before or after #165, the text I am looking at is just moved).

I’m not entirely sure what “the revised text” is now.

>> * Section 9.5
>> 
>> Considering the Apps Area Working Group does not exist anymore, should the contact here being updated?
> 
>    Yes, I have added this to #161.
>    My assumption is that the change controller simply is IESG.
>    I note a lot of variation in how this is handled in recent RFCs, e.g., in RFC 8628 there are registrations that have change controller IETF (OAuth extensions); all others there have IESG.
> 
> FP: I think IESG + cbor-wg as contact would be OK. Or possibly, [e-mail].

I updated this in the branch for PR #166.

>> * Section 1.1, Point 2, sub-bullet 1
>> 
>> For readability, I would put an example of "very small amount of code" number directly in the text, in the parenthesis when mentioning class 1 constrained nodes.
> 
>    What would be in that example?
>    I’d be very hesitant in adding much to this section, which should stay concise.
> 
> FP: For example:
> OLD: "(for example, in class 1 constrained
>          nodes as defined in [RFC7228])"
> OLD: "(for example, in class 1 constrained
>          nodes with ~ 100 KiB code size as defined in [RFC7228])"
> This would give a direct example to the text above, without having to go look for it in the ref. But again, this is very minor, take it or leave it..

As explained in the interim, I’m always a bit wary of rephrasing material that is defined in another RFC.  While the present case is not normative (where the rephrasing may lead to differing interpretations and thus interoperability problems), the referenced RFC is still just a couple of clicks away and provides more background.

> […] it's the first time I see "?" used in references in markdown, what is that for?

This is a shortcut for referencing an item for which bibliography is available in bibxml.
? stands for an informative reference, ! for a normative one.  Maybe it is cleaner to put this into the YAML, which I did now (making it easier to swap in RFC 8742 once that is published).

> 
>> * Section 3.1, Major type 5
>> 
>> Using underscoring to highlight a term (in this case "pairs") should be explained in terminology.
> 
>    Solved by RFCXMLv3 :-)
>    (Still needed for the plain text version, as is the equivalent for typeset versions.)
> 
> FP: nice __

We could steal some more text from Section 1.2 of RFC 8610, but I think the end of Section 1.2 is fine with the update.

>> 
>> * Table 4
>> 
>> I would have explicitely stated what data items where allowed for each tag number, rather than writing multiple.
> 
>    We could do that.  There are two cases: Essentially anything (21–23, 55799), and the numbers allowed by tag 1; for the latter we could write “integer or float”, and “(any)” for the former.
> 
> FP: That works, thanks. Even if the information was already in the text, I think this improves readability.

See also issue #170, though.

>> 
>> * Section 7.1, last sub-bullet
>> 
>> Please reference section 7.2.
> 
>    Yes.  (Let’s see whether the RFC editor throws that out again…)
> 
> FP: oh you mean for fw reference? 

No, it is just a bit weird to end a section with a reference to the section that is immediately following.  But better than the indeterminate “see below”…


I have pushed an update to PR #166, which should now be ready for merging.

Grüße, Carsten