Subject: [Cbor] Bignums and the generic data models (Re: 🔔 WGLC on draft-ietf-cbor-7049bis-09)

From: Carsten Bormann <[email-masked]>
Date: Tue, 14 Jan 2020 22:52:40 +0100

On 2019-11-24, at 12:23, Jeffrey Yasskin <[email-masked]> wrote:
> 
> 3.4.4.  Bignums
> 	[…]
> 	• "and preferred encoding never makes use of bignums that also can be expressed as basic integers (see below)." <- This seems inconsistent with "In the generic data model, bignum values are not equal to integers from the basic data model". If they're not the same value at the data model level, they can't be alternate encodings of each other.

Hi Jeffrey,

of your many useful comments in that message, let me pick this one because answering it is a prerequisite to getting the map validity text right.

Indeed, in the basic (unextended) generic data model, bignums are different from (mt0/1) integers.

The extended generic data model for tag 2/3 changes this.  It has to.  Consider:

2(h'00112233445566778899')
and
2(h'112233445566778899')

These are different in the basic generic data model, but both mean 316059037807746189465 in the extended generic data model, so that has to be different from the basic one.  

So given that we already had to extend the generic data model with the values (types) specific to the tag semantics, we also can (and should!) say that

2(h'12')

means 18 in the extended generic data model, the preferred encoding of which is 0x12 and not 0xc24112.

For a generic codec, both options are available for a specific tag number:

- offer the basic generic data model.  This leaves it to the application to build the tag content in the way that fits to the tag definition and to interpret it this way.  It is then also up to the application to take care of map validity (e.g., by not using both 2(h'00112233445566778899’) and 2(h'112233445566778899’) as keys in the same map), and to issue preferred serialization if desired.
— process the tag, i.e., offer the extended generic data model.  Now the generic codec can do all that work; for the example at hand, at the codec API you only see integers.

This is the direction in which I think we need to go if we want to enable tag processing in generic codecs.

(The cognitive dissonance here is maybe with ECMAscript bigints, which are a separate type from numbers.  But sending a bignum is not on its own a good way to distinguish a number as a ES bigint; probably a language-specific tag is a better way to make that language-specific distinction.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Jan 2020 16:36:13 +0100

Hi Jeffrey,

Beyond the one comment that I singled out on 3.4.4, here are my responses/proposals:

> 1.  Introduction
> 	• "The format defined here follows some specific design goals that are not well met by current formats." <- "Follows" doesn't really work. Maybe "pursues"? "Satisfies"?

"Pursues", I’d say.

> 	• "It is important to note that this is not a proposal that the grammar in RFC 8259 be extended in general, since doing so would cause a significant backwards incompatibility with already deployed JSON documents." <- This is probably not necessary anymore. It could be removed entirely or replaced with "This format is not an extension of the grammar in RFC 8259."

I like that.

> 3.1.  Major Types
> 	• In Table 1, can we spell out "Major Type" instead of "mt"?

We can, but that reduces space for the other columns; I’d rather fix the caption to repeat the text about mt and N above the table.

I took the liberty to add the equivalent table for indefinite length as table 2; please review.

> 3.4.  Tagging of Items
> 	• I'm not sure what "while retaining its structure" accomplishes here. Can we remove it?

(It really means: “without the need to change its structure”.)
This is a bit of a trap door thing: Once you understand the concept, this appears redundant.
But I’m also at a loss how to say this better, so I agree we should remove it.

> 	• "That is, a tag is a data item consisting of a tag number and an enclosed value. The content of the tag (the enclosed data item) is the data item (the value) that is being tagged." might be unnecessary. I think it's covered by the earlier text in this section. If it's still needed, it should probably move earlier to where we define tagged data. It doesn't fit next to the discussion of what it means to put a tag inside a tag.

Right, we should reverse the order.

> 	• "it can just jump over the initial bytes of the tag (that encode the tag number)" isn't quite right: it's not just skipping it, it's reporting both the tag number and value to the application. Maybe "Understanding the semantics of tags is optional for a decoder: it can present the tag number and content to the application without interpreting the tag as a whole."

I made this a bit more specific about “interpreting”.

> 3.4.1.  Date and Time
> 	• The next two sections seem like they should be subsections.

(This was already changed earlier.)

> 
> 3.4.3.  Epoch-based Date/Time
> 	• "An application that requires tag number 1 support may restrict" has a lowercase MAY, which has an ambiguous effect after RFC 8174. Do we want MAY or can?

This is not an interoperability MAY, as it describes what an application can do.
That maybe raises the general question how we are using BCP14 language, but RFC 8174 was written to clarify that lower case may does not have the special meaning of upper case MAY.

> 3.4.4.  Bignums
> 	• This section has a forward reference to "preferred encoding", which should cite section 4.1. I note that 4.1 uses "preferred serialization" instead, so maybe we should switch this section to that term.

Interesting fine point.  I changed all “preferred encoding” to “preferred serialization” (except the one that is used in defining the latter) and added the reference.  We may want to keep some form of differentiation between preferred serialization (which is never visible at the basic data model level) and the choice of a basic data model realization for an extended data model value; maybe we should discuss this with the item below.

> 	• "and preferred encoding never makes use of bignums that also can be expressed as basic integers (see below)." <- This seems inconsistent with "In the generic data model, bignum values are not eq…

See separate message.

> 3.4.5.  Decimal Fractions and Bigfloats
> 	• "Decimal fractions (tag number 4) use base-10 exponents; the value of a decimal fraction data item is m*(10**e). Bigfloats (tag number 5) use base-2 exponents; the value of a bigfloat data item is m*(2**e)." is redundant with the first paragraph of the section.

Somewhat.  The first paragraph says what can be represented, the fourth exactly what is being represented.  Is the redundancy a big problem?

> 	• This section also suggests that integers be used instead of integral bigdecimals and bigfloats. That only works if the specific data model says they're equivalent. Maybe we should say specific data models SHOULD make them equivalent and then SHOULD set the preferred encoding to the integer version?

Generally, we have been moving away from making int and float equivalent, so I agree this recommendation needs to be reshaped.   A similar question occurs with basic floating point as well, so we should come to a common view on these.  Now issue #160: https://github.com/cbor-wg/CBORbis/issues/160

> 3.4.6.2.  Expected Later Encoding for CBOR-to-JSON Converters
> 	• This section only defines the tags obliquely and never says what tag 23 means. I suggest starting sentences with the tag number, e.g. "Tag number 21 means the contained byte string is expected to be encoded in base64url without padding ... Tag number 22 means ..."

Did this; added reference to Section 8 of RFC 4648, and emphasized the uppercase alphabetics used there.

> 3.4.6.3.  Encoded Text
> 	• "Tag numbers 33 and 34 are for base64url- and base64-encoded text strings" should maybe have "respectively"?

Added.

> 
> 4.1.  Preferred Serialization
> 	• "1_000_000_000" has enough digits that maybe we should use 10**9 (or 10<sup>9</sup> in v3) instead.

Three by three is obvious enough to me, but I have added “(one billion)” to add more fun to milliard-educated people like me.

> 4.2.  Deterministically Encoded CBOR
> 	• "Some protocols may want" has a lowercase "may". Consider "might".

See comment on RFC 8174 above.
(This is not a sufficiently remote corner case to use “might”, in my eyes.)

> 4.2.1.  Core Deterministic Encoding Requirements
> 	• This section says "Floating point values also MUST use the shortest form that preserves the value, e.g. 1.5 is encoded as 0xf93e00 and 1000000.5 as 0xfa49742408.", but 4.2.2 says "If a protocol allows for IEEE floats, then additional deterministic encoding rules might need to be added." We should only put the float rule in one of these sections.

Yes, we are now probably ready to reduce the variety here.  I moved over the text about trying successively shorter representations as an implementation note for 4.2.1.  I also added some text about an application wanting to limit precision.

> 4.2.2.  Additional Deterministic Encoding Considerations
> 	• "the deterministic format would not allow them" isn't clear what "them" is. Do we mean "would not allow the data to be tagged"? Or should we just say that the deterministic format for the protocol needs to specify whether the tag is or is not present?
> 	• The "If a protocol includes a field that can express floating-point values" paragraph also assumes "… and the protocol's specific data model declares integers and floating point values to be interchangeable".

Right.  Case 3 is a bit questionable, as this is not conforming to preferred serialization.

> 	• The "A protocol might give encoders the choice of representing a URL ..." item feels like it's repeating the "CBOR tags present …" paragraph. Maybe we should move it to an example in that paragraph?

Moved and made into an example.

> 	• Maybe the ""Protocols that include floating, big integer, or other complex values need to define extra requirements on their deterministic encodings. For example:" introductory sentence belongs at the top of the whole section.

Right.  I restructured the section a bit.
The part about bignums maybe also needs to be made stronger.

> 5.  Creating CBOR-Based Protocols
> 	• "This section discusses" might read better as "The rest of this section" since it's after a bit of the section.

Right.

> 
> 5.2.  Generic Encoders and Decoders
> 	• "Even though CBOR attempts to minimize these cases, not all well-formed CBOR data is valid" is redundant with a lot of text from earlier in the document.

Right.  Redundancy is not always bad, though; some repetition can be useful.

> 	• I wonder if this whole subsection is out of place. It reads like a definition of generic en/decoders rather than a consideration for designing protocols. Maybe it should be a subsection of "Terminology"?

Good point.  Maybe the results of processing #156 will also point in that direction.
But the concept is not just terminology, it is a constraint on the design decisions of CBOR and its protocols.  If a protocol is designed in such a way that it cannot use generic codecs, it really gives up a major advantage of using CBOR — this is why the subsection is here at the moment.

> 5.3.  Validity of Items
> 	• "The first layer that does process the semantics of an invalid CBOR item MUST take one of two choices:" covers our discussion of duplicate map keys. Right now, our requirements aren't consistent with the requirements in this section, so we should make sure to incorporate this section when we resolve those.

Right.  Issue #63.

> 
> 5.3.2.  Tag validity
> 	• "might present this tag to the application in a similar way to how it would present a tag with an unknown tag number" seems to suggest that it's wrong to replace the invalid tag with an error marker or to stop processing entirely, even though that's what 5.3 suggests.

Again, discussion about what a generic decoder should do.  Or, here, specifically how the validity function of a tag could evolve.

> 5.5.  Numbers
> 	• "the JavaScript number system treats all numbers as floating point" is no longer true: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt

BigInts are not JavaScript Numbers.  (This legacy-forced separation is a whole can of worms and does not really detract from what is said.)  I added “basic”.

> 	• "a compact application should accept" uses a lowercase "should" and would seem to discourage compact applications that check for a deterministic decoding. Do we mean that accepting wider encodings is likely to make the application more compact?

Not all applications SHOULD check for deterministic encoding…
Added "that does not require deterministic encoding”.

> 	• "The preferred encoding for a floating-point value is the shortest floating-point encoding" is redundant with section 4.1, although it does include more detail. I *think* I'd rather put the whole definition of the preferred encoding in 4.1 instead of having some of it in protocol considerations.

Moved (and added back some text here).

> 5.6.  Specifying Keys for Maps
> 	• "probably should be limited" -> "may need to be limited" or "the specification is probably simpler if"? To avoid BCP 14 terms. 

Restated this slightly.

> 	• We're already discussing the question of duplicate keys in another thread.

Yes; issue #63.

> 	• "except to specify that some, orders" has an extra comma.
> 	• "be enough reason on its own" -> "on their own"
> 	• The "should consider using small integers as keys" has the downside that it makes it harder for humans to understand the meaning of the data without the schema. "for constrained devices" might protect the rest of us from that downside, but would it make sense to say it explicitly?

One word: “BTU” :-)
I think we are already explicit about this, but we don’t mention the downside (or the upside that you are now forced to properly define the things).

> 5.6.1.  Equivalence of Keys
> 	• This section might be shorter if it just says that map keys are duplicates if they have the same value in the generic data model or if the specific data model for the protocol (Section 2.2) says they're equivalent. The rest of the section just duplicates information that's already in Section 2. The note in the last paragraph does still seem useful.

Will handle with #63.

> 8.1.  Encoding Indicators
> 	• "Note that the encoding indicator "_" is thus an abbreviation of the full form "_7", which is not used." is confusing where it is. It might make more sense if we swap its paragraph with the previous one and move it to after the definition of "[_ 1, 2]".

I’m not sure I understand how to do this without forward references.

> 	• "As a special case, byte and text strings of indefinite length" doesn't seem like a special case to me. It's just the way you represent the encoding of an indefinite-length byte or text string.

Yes.  Removed “as a special case”.
(We still don’t have a way to notate an empty indefinite length string.)

> 
> 9.2.  Tags Registry
> 	• Did we decide not to tighten registration for the 256–65535 space?

I couldn’t find anything conclusive; the discussion seemed to center on the designated expert.

> 9.3.  Media Type ("MIME Type")
> 	• Is there a reason this section switches to artwork in the middle?

Lazyness.

(Oh, this probably should be fixed, too, now #161.
There is a long-standing bug in XML2RFC that creates incorrect formatting if this is done right.)

> 
> 9.4.  CoAP Content-Format
> 	• Could this section link to https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats?

Yes.  (Not sure how to do the sub registry part, though.)

> Appendix A.  Examples
> 	• This starts with some references to Unicode code points, which could use the new <u> tag.

If we want to take a full v3 plunge…

> 
> Appendix F.  Changes from RFC 7049
> 	• This looks quite incomplete.

Indeed!  Now #163: https://github.com/cbor-wg/CBORbis/issues/162

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Jan 2020 16:42:15 +0100

On 2020-01-15, at 16:36, Carsten Bormann <[email-masked]> wrote:
> 
> here are my responses/proposals

And here is the pull request for the items that have not become separate issues:

https://github.com/cbor-wg/CBORbis/pull/163

Thanks again for that thoughtful review!

Grüße, Carsten

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 15 Jan 2020 12:22:29 -0800

> (The cognitive dissonance here is maybe with ECMAscript bigints, which are a separate type from numbers.  But sending a bignum is not on its own a good way to distinguish a number as a ES bigint; p…

I think either of the following situations would be plausible:

1. 2(h'12') is a different value from major-type-0 "18", in the same
way major-type-0 18 is a different value from floating "18.0".
2. 2(h'12') is the same value as major-type-0 "18", but both are
distinct from floating "18.0".

(It would also have been plausible to declare that integral 18 is the
same value as floating 18.0, but we discussed that a while ago and
decided to keep them separate.)

I don't think the wording in
https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#extended-generic-data-models
nails down whether tags can offer alternate representations for
elements of the basic generic data model.

It's true that a tag can define a non-injective mapping into its
domain, but I don't think that by itself requires that its domain be
able to overlap the domain of the basic generic data model.

The extended generic data model *does* specify that particular tag
values in the basic generic data model are equal to other values in
the extended generic data model, but in that case the identified
values have the same encoding, so I don't think it helps much in
deciding whether they can be equal to a value in the basic generic
data model.

My preference is to follow the decision we made to distinguish
integers from floating point, and also distinguish bignums from
primitives. However, if we decide not to do that, we need to remove
the sentence in
https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#bignums
saying "In the generic data model, bignum values are not equal to
integers from the basic data model" and the sentence in
https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html#fractions
saying "As with bignums, values of different types are not equal in
the generic data model."

Jeffrey

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Jan 2020 21:52:23 +0100

> distinct from floating "18.0".

(1) would then extend to numbers bigger than can be represented in basic integers?
I don’t think the simple fact that the range of an integer exceeds the 64-bit + sign (“65-bit”) range of basic CBOR integers should catapult it into a different universe.  Once 128-bit numbers are becoming more common, that would create an ugly discontinuity.  So I strongly believe that only (2) is compatible with long-term stability of the format.

> decided to keep them separate.)

Indeed.  We kept this somewhat open in RFC 7049, but experience seems to indicate that separating the integer world from the floating point world is the right thing at least for the generic data models (application data models can unite them).

> primitives.

(I’d say: Yes, no — See above.)

> However, if we decide not to do that, we need to remove
> the sentence in

Yes, that is work that needs to be done.   Now #164: https://github.com/cbor-wg/CBORbis/issues/164

(Peter Occil has another interesting observation about fractions in https://github.com/cbor-wg/CBORbis/issues/160#issuecomment-574787487 — this probably requires more text about deterministic encoding for these, as well.)

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 15 Jan 2020 13:00:08 -0800

I’m in favor of bignums being quite separate:
- There are very very few use cases for them, many fewer than floating point, as we just don’t need the the range and the precision at the same time
- CPUs and programming languages don’t generally or generically support them — if you are writing code for bignums you are writing very specific code

For example, I don’t think it would be useful for a generic decoder to convert bignums less than 0xffffffff to uint32_t and those larger than that to a byte array when returned to the caller.

I don’t think anyone is going to send smaller integer values as the bignum type (some integer values like 0xffffff encode smaller as a bignum type than they would as type 0 and 1, but I don’t think we want to encourage that). 

LL

Bignum spelling auto correct: big numb lignum bingo bigness!

> On Jan 15, 2020, at 12:22 PM, Jeffrey Yasskin <[email-masked]> wrote:
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Jan 2020 22:26:25 +0100

Hi Laurence,

> I don’t think anyone is going to send smaller integer values as the bignum type (some integer values like 0xffffff encode smaller as a bignum type than they would as type 0 and 1, but I don’t think…

Exactly.  By making the basic integer the preferred serialization, we make sure that bignums only occur where they are actually needed.  That is a strong reason to keep bignums in the same space as basic integers and to make basic integers, when they fit, the preferred serialization for a single integer domain.

> - There are very very few use cases for them, many fewer than floating point, as we just don’t need the the range and the precision at the same time

That depends a lot on the application.

If we hadn’t provided bignums as a catch-all, I’m sure we would already have activated ai=30 for 128-bit integers.  With bignums, we probably will never need that (we can still make that step if we really have to).

Bignums are the “design for decades” relief for limiting basic integers to 64 bits.

> - CPUs and programming languages don’t generally or generically support them — if you are writing code for bignums you are writing very specific code

Again, that depends a lot on your application.

> For example, I don’t think it would be useful for a generic decoder to convert bignums less than 0xffffffff to uint32_t and those larger than that to a byte array when returned to the caller.

I would expect the generic decoder to decode a bignum as an integer in the representations provided by the platform (*), just as with basic integers.

Now if the platform doesn’t have such representations, handing up the tag (for plus/minus) and the byte string is exactly what I would recommend a generic decoder to do.

Not being able to decode 2(h’12’) as 18 is somewhat equivalent to not being able to decode 0x1B0000000000000012 as a 32-bit integer on a 32-bit platform — not recommended, but an option that CBOR gives to a generic decoder (both 2(h’12’) and 0x1B0000000000000012 are not in preferred encoding).

> Bignum spelling auto correct: big numb lignum bingo bigness!

My Mac has quickly adapted: bignum (look, ma, no autocorrect!).

Grüße, Carsten

(*) Popular platforms that don’t have arbitrary limits on integer sizes include: Common Lisp, Erlang (of WhatsApp fame), Haskell, Prolog, Python, Racket, Ruby, TCL.
Other platforms such as C#, D, Go, Java, JavaScript, Julia, OCaml provide standard libraries for handling unrestricted integers.  For other languages, there are multiple libraries available to get these, e.g., for C/C++ you can find Boost, GMP, mbedTLS, OpenSSL.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jan 2020 15:49:37 +0100

Hi Francesca,

here are my comments on your review.

> * 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.

> * 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).
 
> * 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.

> Minor/Editorials
>  
> * Contributing
>  
> It might be good to put in a note for the RFC Editor to remove this section.

(BTW, the thing is a “note", not a section — at the same level as abstracts.)
Added in new branch “francesca-editorial”.
 
> 
> * 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.

>  
> * Section 1.1, Point 4, sub-bullet 1
>  
> "and by implementation complexity maintining a lower bound" does not read correctly to me. Am I missing something?

Citing the full text:

4. The serialization must be reasonably compact, but data compactness
   is secondary to code compactness for the encoder and decoder.

    * "Reasonable" here is bounded by JSON as an upper bound in size,
      and by implementation complexity maintaining a lower bound.

This is a bound to “reasonable”: we don’t want to increase implementation complexity considerably to improve compactness.  So implementation complexity maintains a lower bound to what is reasonable to achieve for the size.  I have tried rephrasing that in the new branch.
 
> * Section 1.1, Point 5, sub-bullet 1
>  
> I would suggest to add "for example for devices of class 1" as an example of what "reasonably frugal in CPU" means.

But it means much more than that, as the next sentence explains.
Again, I’d prefer to avoid adding much complexity to this section.
 
> * Section 1.2
>  
> The term "representation format" is only used in this section twice, everywhere else "encoded data item" is used. I would go ahead and remove this formulation, and only use encoded data item. This would also make the part on decoder and encoder more symmetric (right now Decoder talks about "encoded data item" and Encoder talks about "represetnation format").

While this would simplify things, it would also increase the reliance on a term that the reader is still trying to understand at this point (essentially increasing circularity).  “Representation format” should be sufficiently generic for introductory text, which no need for definitions.
 
> * Section 1.2, "Valid: "
>  
> This paragraph talks about "semantic restrictions that apply to CBOR data items"; it would be good to add a hint on where these are defined in the specification.

Right.  That would be a reference to Section 5.3, I’d assume, not to all ~ 81 places that talk about validity?
 
> * Section 2
>  
> "A simple value, identified by a number between 0 and 255, but distinct from that number"
>  
> I had to read this sentence several times to understand that the part "but distinct from that number" is meant to note to the reader that the value of the item is not the number it's identified by. I would formulate as written here, rather than as it is now. ("Note that the value of the item is not the number it's identified by")

Well, we need to define it, not just adding notes.
Hmm.
 
> * Section 3.1, Major type 4
>  
> The text states that arrays can also be called sequences. With the publication of CBOR Sequences, can we remove this statement, as sequences are (although related) different things?

Good point.
CBOR sequences are, but arrays are still called sequences in many other places (which might include the applications sitting on top of CBOR).
Need to think about a better way to say “are also called”.
Attempt in new branch.
 
> * 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.)
 
> * Section 3.1, Major type 6
>  
> To be consistent with other major types, it might be good to shortly mention ranges for tags here.

Good point!
 
> * Section 3.2
>  
> While the motivation for arrays and maps is obvious, I would have appreciated some more text on motivation (or an example of use case) where indefinite-length strings are useful.

That would be an expansion of calling out “streaming”, right?
Attempt is in the branch.

> * Section 3.2.3
>  
> I don't understand the link between the previous sentence and this one:
>  
> "   Note that this implies that the bytes of a single UTF-8 character
>    cannot be spread between chunks: a new chunk can only be started at a
>    character boundary."
>  
> Nor am I sure of the meaning of the term "spread" here.

All component strings need to be valid, i.e., sequences of UTF-8 characters; this means a single character cannot be started in one component string and then go on in the next component string.
"split up" may be better.

>  
> * Section 3.3
>  
> Re-appearance of the term "sequence", which I would still avoid.

Yes.  We also wanted to avoid “byte string”, because that is always confusing (in particular if the data item encodes a byte string).  Maybe “sequence of bytes”?  Or maybe:

For example, assume an encoded data item consisting of the bytes:

>  
> * 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.

> * Section 3.4.4
>  
> The term "preferred encoding" appears here for the first time without any reference or introduction.

(I think this is now 3.4.3.)
The next now has a pointer to Section 4.1, and we are using “preferred serialization”.

>  
> * Section 3.4.5
>  
> "while the mantissa also can be" -> "while the mantissa can also be"

Yes.
 
> * Section 3.4.5
>  
> Expand NaN on first appearance here (instead of 5.6.1)

#165 now has a mention (and expansion) in the terminology section.
We could expand here, as well, I’d probably leave the expansion in 5.6.1. because there is not much context about non-finites here, while there is in 3.4.5.
 
> * Section 4.2.2
>  
> "may want to exclude them from interchange, interchanging"
>  
> I would reformulate this.

Because it is wrong, misleading, or because the same word is used twice?

If the latter,
"may want to exclude them from the protocol format, interchanging"
maybe?
 
> * Section 4.2.3
> Capitalize section title

I’m sure the RFC editor will have a lot of these.
Fixed in the branch now.
 
> * Section 4.2.3
>  
> First paragraph: please add a reference to 4.2.1 when talking about core deterministic encoding requirements.

Yes.
 
> * Section 5.4
>  
> "A generic encoder also may want" -> "A generic encoder may also want"

Yes.
 
> * Section 5.6
>  
> "Duplicate keys are also prohibited by CBOR decoders that
>    enforce validity (Section 5.4)."
>  
> I have a slight problem with the term "prohibited by" decoders... Decoders do not prohibit, at most they do not accept.

Good point.  So let’s say “not accepted”.

>  
> * Section 5.6
>  
> "except to specify that some, orders are disallowed" -> remove comma

(Fixed previously.)

>  
> * Section 7.1, last sub-bullet
>  
> Please reference section 7.2.

Yes.  (Let’s see whether the RFC editor throws that out again…)

>  
> * Section 8.1
>  
> I like examples. I would have liked an example for the second paragraph of this section.

Good point.
 
> * Appendix G
>  
> "this may not be actually be an error" -> "this may not actually be an error"

Yes.

Now PR #166: https://github.com/cbor-wg/CBORbis/pull/166

Grüße, Carsten