Re: [Cbor] WGLC review of draft-ietf-cbor-7049bis-09

[Carsten Bormann <[e-mail]>]

Hi Jim,

now looking at the items not yet covered by the PR so far:

>> *  In paragraph 2 of section 1, I don't understand how the first 
>> sentence leads into the second sentence.  The first talks about 
>> specific design goals, so I expected a discussion of some of those 
>> goals.  Instead I get a discussion of the data model.  Paragraph 3 
>> seems to follow better from the first sentence of paragraph 2.
> 
> I don’t think the first sentence is meant to lead into the second sentence.  This brief introduction provides a set of facts that distinguish CBOR from previous efforts but are not necessarily interrelated.
> Paragraph 3 could be moved as a second sentence of paragraph 2, but that would distract a bit from the brief explanation of what CBOR is.
> 
> [JLS] Let's have Paul look at it.  It just reads really badly to me.  Forward references would be one way to say that they are not related items.

OK, I’ll let the native speakers sort that one out…

>> * In section 1 - paragraph 3.  I think this would fit better in 
>> section 1.1 rather than doing the forward reference.
> 
> Section 1.1 is about the objectives behind CBOR.  Section 1 paragraph 3 is about previous formats.
> 
> If we do want to restructure this, maybe it would be worth to do a subsection “history” (or “related work”?) with the JSON material and the pointer to appendix E.
> 
> [JLS] That would be part of the "are not well met" in the first sentence.   I don’t know that a history section would help here.

See above.

>> * Section 1.2 - The terminology of Encoder and Decoder do not seem to 
>> match each other.  The decoder decodes a well-formed CBOR data item.  
>> The Encoder generates the representation of a CBOR data item.  I 
>> assume that the decoder should decode the representation of a 
>> well-formed CBOR data item.  The other way around would be that the Encoder creates a well-formed CBOR data item.
> 
> Right.  This is one instance where we don’t properly handle the distinction between the abstract data item and its representation format/encoded data item.
> 
> This is an issue that would need to go through the whole definition section and probably much more; e.g., well-formed is a property of an instance of the representation format.  Should we go for that?
> 
> [JLS] I hope that is not needed.
> 
> Symmetry between encoder and decoder should be easy to achieve even without such massive surgery, e.g., s/well-formed CBOR data item/well-formed encoded CBOR data item/ (maybe even without the “CBOR”).
> 
> [JLS] I think you need some changes on the Encoder side as well.

So here is my proposal of a limited change:

 
 Decoder:
-: A process that decodes a well-formed CBOR data item and makes it available to an
+: A process that decodes a well-formed encoded CBOR data item and makes it available to an
   application.  […]
 
 Encoder:
-: A process that generates the representation format of a CBOR data
+: A process that generates the (well-formed) representation format of a CBOR data
   item from application information.

Added to PR below.

>> * Section 2.2 last paragraph.  /be considered duplicates/be considered
>> duplicates, even if encoded as different major types,/   This is a belts and
>> suspenders suggestion but not something I would die for.
> 
> I’m not sure I like the “if” (integer 0 and float 0.0 are always encoded as different major types).  How about “while”?
> 
> [JLS] That is just fine.  Other approach would be /even if/when/

I stuck with “while”.  Added to PR below.

>> * Section 3.2.3 - The text is silent on a chuck being of length zero.
>> Should this be stated as discouraged but legal?
> 
> I don’t know why this needs to be discouraged but it certainly is not ruled out.
> To this reader, chunks of length 0 need to be discussed as much as chunks of length 4711, which are also not ruled out.
> 
> [JLS] Yes, but checks of length 4711 are, if not expected, useful.  A chuck of length 0 is not useful.

Added:
(Note that zero-length chunks, while not particularly useful, are permitted.)

Added to PR below.

>> * Section 9.2 - Are you intending to update the template to point to 
>> this document rather than saying with RFC 7049?  This is not stated here.
> 
> Not sure about updating the template, but the registries should indeed be updated to this specification.
> 
> Added at the end of Section 9 in PR below:
> 
> \[To be removed by RFC editor:]
> IANA is requested to update these registries to point to the present document instead of RFC 7049.
> 
> [JLS] As noted in the PR, I think IANA is going to want this instruction to remain in the document.

I think I’d prefer to let them speak for themselves…
(That sentence is not really useful for any future user of the RFC, so I’d prefer to leave it out.)

I updated https://github.com/cbor-wg/CBORbis/pull/149 with the changes identified above.

Grüße, Carsten