Skip to main content

Concise Binary Object Representation (CBOR)
draft-ietf-cbor-7049bis-16

Revision differences

Document history

Date Rev. By Action
2024-01-26
16 Gunter Van de Velde Request closed, assignment withdrawn: Jouni Korhonen Last Call OPSDIR review
2024-01-26
16 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2020-12-04
16 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-11-03
16 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-10-21
16 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-10-20
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-10-16
16 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-10-15
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-10-15
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-10-15
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-10-15
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-10-15
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-10-10
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-10-10
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-10-09
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-09-30
16 (System) RFC Editor state changed to EDIT
2020-09-30
16 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-09-30
16 (System) Announcement was received by RFC Editor
2020-09-30
16 (System) IANA Action state changed to In Progress
2020-09-30
16 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-09-30
16 Cindy Morgan IESG has approved the document
2020-09-30
16 Cindy Morgan Closed "Approve" ballot
2020-09-30
16 Cindy Morgan Ballot approval text was generated
2020-09-30
16 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-09-30
16 Carsten Bormann New version available: draft-ietf-cbor-7049bis-16.txt
2020-09-30
16 (System) New version accepted (logged-in submitter: Carsten Bormann)
2020-09-30
16 Carsten Bormann Uploaded new revision
2020-09-27
15 Benjamin Kaduk [Ballot comment]
Just one nit left in the -15:

s/also MUST have matching streaming security mechanism/also MUST have a matching streaming security mechanism/
2020-09-27
15 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from Discuss
2020-09-24
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-09-24
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-09-24
15 Carsten Bormann New version available: draft-ietf-cbor-7049bis-15.txt
2020-09-24
15 (System) New version accepted (logged-in submitter: Carsten Bormann)
2020-09-24
15 Carsten Bormann Uploaded new revision
2020-09-10
14 Murray Kucherawy
[Ballot comment]
I regret that due to time constraints this week, I only reviewed the diff against RFC7049.  But what I saw there looked …
[Ballot comment]
I regret that due to time constraints this week, I only reviewed the diff against RFC7049.  But what I saw there looked good to me.
2020-09-10
14 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-09-10
14 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-09-10
14 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-09-09
14 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-09-09
14 Warren Kumari [Ballot comment]
Thanks!
2020-09-09
14 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-09-09
14 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-09-09
14 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. While it is rather long, it is exhaustive and usually quite clear (with exceptions …
[Ballot comment]
Thank you for the work put into this document. While it is rather long, it is exhaustive and usually quite clear (with exceptions see below).

Thanks to Eve Schooler for her very detailed IoT directorate review at https://datatracker.ietf.org/doc/review-ietf-cbor-7049bis-14-iotdir-telechat-schooler-2020-09-08/ I strongly suggest to the authors to follow Eve's recommendation to clarify and make the text easier to read.

Please find below a couple of non-blocking COMMENT points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 3.4  --
Is there a reason why "specifically, tag number 25 and tag number 29" have no reference to a RFC ? The reader would benefit from some short description. This oddity was also mentioned by Eve in her review, so, I strongly suggest to address the issue.

-- Section 3.4.5.2 --
As noted by other AD, I am puzzled by the added value of checking whether a string is PCRE or ECMA262.

-- Section 3.4.6 --
I like this idea of 'magic number' but, as I am not a Unicode expert, I wonder whether "In particular, 0xd9d9f7 is not a valid start of a Unicode text in any Unicode encoding if it is followed by a valid CBOR data item." will always stand true.

-- Section 4.2.1 --
Humm this section says "MUST be as short as possible" while the introduction says "optimize for CPU not for bytes". Same applies for sorted keys... How can we reconciliate ? Suggestion: add some text about this apparent goals conflict.
2020-09-09
14 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-09-09
14 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-09-09
14 Robert Wilton
[Ballot comment]
Hi,

Thank you for your work on this document, and bringing this to full standard.  Since I'm a big fan of CBOR and …
[Ballot comment]
Hi,

Thank you for your work on this document, and bringing this to full standard.  Since I'm a big fan of CBOR and try to evangelize it whenever possible I'm please to see this happening.

However, I have one minor annoyance with CBOR, which is the range of negative numbers that are encoded in major type 1.  My gripe is that the encoding allows for negative integers that are not easily representable in a simple form in most programming languages without using something equivalent to BigInteger.

E.g., all values below -2^63 won't fit into a int64 type, and the value 2^64 won't even fit into an uint64 that was used to represent a negative number (obviously unless it followed the CBOR encoding semantics of being offset by 1)

For a generic decoder I presume that this isn't an issue since it can fallback to something like BigInteger.  But for other decoders handling normal sized integer datatypes I would presume that they would effectively presumably regard anything smaller than -2^63 as not well-formed for their specific problem domain.

I'm not suggesting that this should be changed (hence comment not a discuss), but there are a couple of places in the document that it might be helpful to warn implementors about this, that I have mentioned below.

Other minor comments:

    3.  Specification of the CBOR Encoding

      Major type 0:  an integer in the range 0..2**64-1 inclusive.  The
          value of the encoded item is the argument itself.  For example,
          the integer 10 is denoted as the one byte 0b000_01010 (major type
          0, additional information 10).  The integer 500 would be
          0b000_11001 (major type 0, additional information 25) followed by
          the two bytes 0x01f4, which is 500 in decimal.

      Major type 1:  a negative integer in the range -2**64..-1 inclusive.
          The value of the item is -1 minus the argument.  For example, the
          integer -500 would be 0b001_11001 (major type 1, additional
          information 25) followed by the two bytes 0x01f3, which is 499 in
          decimal.
     
Would writing "0 to 2**64-1" be more clear than 0..2**64-1?  Or otherwise perhaps mention that in the terminology section that "x..y" is used to represent an inclusive range set of all values from x to y, including x and y.  Also, noting that here where ".." has been used it explicit states that it is inclusive, but that doesn't appear to be the case everywhere.

I suggest changing "Major type 0:  an integer ..." back to "Major type 0:  an unsigned integer", as in RFC7049, because the type is referred to as "Unsigned integer".  It also makes it more consistent with the definition of Major type 1.


    3.2.1.  The "break" Stop Code

      The "break" stop code is encoded with major type 7 and additional
      information value 31 (0b111_11111).  It is not itself a data item: it
      is just a syntactic feature to close an indefinite-length item.

      If the "break" stop code appears anywhere where a data item is
      expected, other than directly inside an indefinite-length string,
      array, or map -- for example directly inside a definite-length array
      or map -- the enclosing item is not well-formed.
     
I was wondering whether it would be helpful to clarify that by indefinite-length string it means text or byte string?  Although this becomes clear in section 3.2.3 anyway ...  My thinking is that section 3.2 lists 4 types that can have indefinite length, and then in this section both types are string are treated together.

    3.2.3.  Indefinite-Length Byte Strings and Text Strings

Would it be helpful to clarify that the chunks must be the same type.  E.g. you cannot have a byte string that contains text string chunks and vice-versa?

    3.4.5.2.  Expected Later Encoding for CBOR-to-JSON Converters

"Tags number 21 to 23 ..." => "Tag numbers 21 to 23 ..."
     
     
    4.2.1.  Core Deterministic Encoding Requirements

          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.  (One implementation of this is to have all
          floats start as a 64-bit float, then do a test conversion to a
          32-bit float; if the result is the same numeric value, use the

I find this paragraph slightly opaque, and I would suggest spelling out that 1.5 has been encoded as a 16 bit IEEE float, whereas 1.00000005 has been encoded as a 32 bit IEEE float.  The same comment applies to 4.2.2 as well.

I also noticed that in most places the document refers to "floating-point" but in a few places "floating point" is used instead.


    5.5.  Numbers

As per my top comment, I think that it would be useful to raise in this section that CBOR can encode negative values that cannot normally be represented in a compact form.
 

    6.1.  Converting from CBOR to JSON

      Most of the types in CBOR have direct analogs in JSON.  However, some
      do not, and someone implementing a CBOR-to-JSON converter has to
      consider what to do in those cases.  The following non-normative
      advice deals with these by converting them to a single substitute
      value, such as a JSON null.

      *  An integer (major type 0 or 1) becomes a JSON number.

It is worth referencing back to section 5.5 on Javascript numbers and explicitly warn that not all CBOR integers can be precisely represented as JSON numbers, and there may be a loss of precision?
 

    Appendix C.  Pseudocode

      Major types 0 and 1 are designed in such a way that they can be
      encoded in C from a signed integer without actually doing an if-then-
      else for positive/negative (Figure 2).  This uses the fact that
      (-1-n), the transformation for major type 1, is the same as ~n
      (bitwise complement) in C unsigned arithmetic; ~n can then be
      expressed as (-1)^n for the negative case, while 0^n leaves n
      unchanged for non-negative.  The sign of a number can be converted to
      -1 for negative and 0 for non-negative (0 or positive) by arithmetic-
      shifting the number by one bit less than the bit length of the number
      (for example, by 63 for 64-bit numbers).
     
This was another place where I thought that it might be useful to warn the reader about decoding negative integers and the risk of overflow taking a major 1 value into an int64 native type.

Regards,
Rob
2020-09-09
14 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-09-08
14 Erik Kline
[Ballot comment]
[[ questions ]]

[ section 3.3 ]

* Is it worth comparing and contrasting this encoding format with RFC 4506
  section 4.6?  …
[Ballot comment]
[[ questions ]]

[ section 3.3 ]

* Is it worth comparing and contrasting this encoding format with RFC 4506
  section 4.6?  Are they identical?


[[ comments ]]

[ section 1 ]

* I suppose XDR (4506) isn't well-known anymore.  :-(
  (no edits necessary, just a comment)


[[ nits ]]

[ section 1.2 ]

* "does not include following extraneous data"
  Is "following" important, or is it just "does not include other
  extraneous data"?

[ section 3.4.1 ]

* Perhaps "another type or that" -> "another type or a text string that"

[ section 5.6 ]

* Perhaps "Not accept maps duplicate keys"
  -> "Not accept maps with duplicate keys"?
2020-09-08
14 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2020-09-08
14 Roman Danyliw
[Ballot comment]
I support Ben Kaduk’s DISCUSS position.

** Section 1.0. Is it possible to enumerate the fixed errata?

** Section 3.4.5.3.  For Tag 35, …
[Ballot comment]
I support Ben Kaduk’s DISCUSS position.

** Section 1.0. Is it possible to enumerate the fixed errata?

** Section 3.4.5.3.  For Tag 35, how does one know if the syntax is a PCRE or ECMA regular expression?

** Section 3.4.5.3.  PCRE is the only informative reference of all of the tags defined in this section (even ECMA is normative).  Please make it normative.

** Section 4.1.  As an implementer of an application, what is the take away from this section?  I’m not following on the definition of “preferred”.

** Section 10.  Per “The input check itself may consume resources.  This is usually linear in the size of the input, which means that an attacker has to spend resources that are commensurate to the resources spent by the defender on input validation.”  I’m not sure this is true for all types of resources.  For example, with compute resources, as an attacker I can craft an input that will take longer for the target to process then for me to produce.
2020-09-08
14 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-09-08
14 Eve Schooler Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Eve Schooler. Sent review to list.
2020-09-07
14 Benjamin Kaduk
[Ballot discuss]
Thanks for this document; it's generally well-written and the changes
since 7049 are helpful.  I do have a few points that may need …
[Ballot discuss]
Thanks for this document; it's generally well-written and the changes
since 7049 are helpful.  I do have a few points that may need discussion
before publication, though.

Let's discuss whether the framing of tag number 35 for "regular
expressions that are roughly in [PCRE] form or a version of the
JavaScript regular expression syntax" meets the interoperability
expectations for Internet Standard status (bearing in mind that we are
defining a data format and not a protocol).  I note that it is okay
to leave the codepoint allocated with the current meaning and the
previous document as its reference, but decline to discuss it in the
document going for STD (we are in the process of doing that with COSE
countersignatures at the moment).

The example in Section 5 of "the item is a map that has byte strings for
keys and contains at least one pair whose key is 0xab01" seems to be in
violation of the definition of a valid map, since applications are not
allowed to rely on invalid behavior.  (That is, the implied "more than
one pair whose key is 0xab01" would be invalid.)

I think that the new deterministic encoding rules for sorting map keys
should be clear about whether "no content" sorts before or after
"content present" -- that is, how 0x10 and 0x1020 are ordered when the
0x10 byte is identical and we have to compare  with 0x20.

The discussion in Appendix C suggests that C (programming language)
implementations all use two's-complement representation of signed
integers; this requirement is present in POSIX but not C itself (I
verified this for C99 and C11).

Additionally, the encode_sint() function (also Appendix C) relies on C
implementation-defined behavior while right-shifting a signed integer.

The C decode_half() function in Appendix D assumes that 'int' is wider
than 16 bits (since assigning a value to an int16_t variable when the
value is not representable in int16_t incurs implementation-defined
behavior).  Given that this spec is specifically targetting constrained
devices, it's not clear that such an assumption is justified.  (It also
right shifts a signed integer, incurring the same implementation-defined
behavior mentioned above.  (The bitwise AND against 0x8000 is also
problematic for an int16_t.))
2020-09-07
14 Benjamin Kaduk
[Ballot comment]
Is there a comprehensive list of things that generic (en/de)coders need
to document their behavior for (e.g., how they handle duplicate map
keys; …
[Ballot comment]
Is there a comprehensive list of things that generic (en/de)coders need
to document their behavior for (e.g., how they handle duplicate map
keys; whether/what validity checking is done, including which tag
numbers are supported)?

We use the expression "simple value" around 30 times, but "simple type
value" only twice (and "simple type" a few other times); are we happy
with the consistency of usage?

Please also note my comments on the IANA considerations in the
per-section comments; at least the first couple are fairly
consequential.

I'm pretty sympathetic to the secdir reviewer's desire for guidance on
how to implement validity checking.  I think it would be possible to
slot this into the existing discussion of validity in §5.3/5.4, possibly as
an additional subsection reiterating that it's required to check the
bits in 5.3.1/5.3.2, and the expectation that such checks are likely to
be incomplete in the face of new tag number allocations.

Section 1.2

  Where bit arithmetic or data types are explained, this document uses
  the notation familiar from the programming language C, except that

In recent memory we've asked for some form of reference for "the
programming language C" (even though the concepts we draw on are likely
to remain invariant for anything called C).

Section 2

  In the basic (un-extended) generic data model, a data item is one of:
  [...]
  *  a sequence of zero or more Unicode code points ("text string")

Hmm, since we use "data item" for both the abstract idea and the
representation-format version, this description is only precise for the
abstract version (the representation is further constrained to UTF-8).
I am not sure whether there is a concise way to accurately express this
state, though.

Section 3

  The initial byte and any additional bytes consumed to construct the
  argument are collectively referred to as the "head" of the data item.

side note: Interesting that we define "head" but do not use "tail" :)

Section 3.3

  meaning, as defined in Table 3.  Like the major types for integers,
  items of this major type do not carry content data; all the
  information is in the initial bytes.

(editorial) The "head", as it were, right?

Section 3.4

  Conceptually, tags are interpreted in the generic data model, not at
  (de-)serialization time.  A small number of tags (specifically, tag
  number 25 and tag number 29) have been registered with semantics that
  may require processing at (de-)serialization time: The decoder needs

I suggest adding additional language to reiterate that this is a
point-in-time statement (and thus that there may be other such tags in
existence).

  This means these tags cannot be implemented on top of every generic
  CBOR encoder/decoder (which might not reflect the serialization order
  for entries in a map at the data model level and vice versa); their
  implementation therefore typically needs to be integrated into the
  generic encoder/decoder.  The definition of new tags with this
  property is NOT RECOMMENDED.

So we should give guidance to the DEs for the registry in question to
that effect?

  IANA allocated tag numbers 65535, 4294967295, and
  18446744073709551615 (binary all-ones in 16-bit, 32-bit, and 64-bit).
  These can be used as a convenience for implementers that want a
  single integer to indicate either that a specific tag is present, or
  the absence of a tag.  That allocation is described in Section 10 of

(editorial) Chasing the reference, I suggest that it is a "single
integer *data structure*" in the implementation's internal
representation; just reading this text alone left me confused as to how
this was intended to be used.

  [I-D.bormann-cbor-notable-tags].  These tags are not intended to
  occur in actual CBOR data items; implementations may flag such an
  occurrence as an error.

I could maybe see this as "MAY".

Section 3.4.2

Thank you for mentioning leap seconds!

  Note that platform types for date/time may include null or undefined
  values, which may also be desirable at an application protocol level.
  While emitting tag number 1 values with non-finite tag content values
  (e.g., with NaN for undefined date/time values or with Infinite for
  an expiry date that is not set) may seem an obvious way to handle
  this, using untagged null or undefined is often a better solution.
  Application protocol designers are encouraged to consider these cases
  and include clear guidelines for handling them.

It's rather unfortunate that the text here doesn't provide any
justification for the claim of "better solution" (or reference to such
justification).

Section 3.4.3

  occurs in a bignum when using preferred serialization).  Note that
  this means the non-preferred choice of a bignum representation
  instead of a basic integer for encoding a number is not intended to
  have application semantics (just as the choice of a longer basic
  integer representation than needed, such as 0x1800 for 0x00 does
  not).

It may be "not intended to", but it does, if you're using a decoder in
the generic data model.  We should be sure to cover the security
considerations of this disparity (and the corresponding need for an
application using CBOR to specify the data model it uses).

Section 3.4.5.3

  Note that tag numbers 33 and 34 differ from 21 and 22 in that the
  data is transported in base-encoded form for the former and in raw
  byte string form for the latter.

Do we want to mention tag 23 as well (as being the raw byte string)?

Section 4.2.1

[I did not validate the hex-encoded IEEE754 against the decimal values.]

  *  Indefinite-length items MUST NOT appear.  They can be encoded as
      definite-length items instead.

One could perhaps argue that a deterministic encoding procedure that
uses indefinite-length items is possible, and even useful in some cases.
This might argue for moving this requirement to Section 4.2.2's
list of "additional considerations".  That said, an application is not
obligated to use these core rules and can define its own rules if
needed, so I don't object to this requirement.

Section 4.2.3

  (Although [RFC7049] used the term "Canonical CBOR" for its form of
  requirements on deterministic encoding, this document avoids this
  term because "canonicalization" is often associated with specific
  uses of deterministic encoding only.  The terms are essentially
  interchangeable, however, and the set of core requirements in this
  document could also be called "Canonical CBOR", while the length-
  first-ordered version of that could be called "Old Canonical CBOR".)

If this document avoids the term, maybe the final sentence should not be
present?

Section 5

  CBOR-based protocols MUST specify how their decoders handle invalid
  and other unexpected data.  CBOR-based protocols MAY specify that
  they treat arbitrary valid data as unexpected.  Encoders for CBOR-
  based protocols MUST produce only valid items, that is, the protocol
  cannot be designed to make use of invalid items.  An encoder can be

Just to check: my interpretation is that CBOR Sequences are compatible
with this requirement, since they use valid data items and just encode
them in sequence.  Right?

Section 5.1

  Other decoders can present partial information about a top-level data
  item to an application, such as the nested data items that could
  already be decoded, or even parts of a byte string that hasn't
  completely arrived yet.

This has potential to make some security types antsy, if coupled with
encryption mechanisms that release alleged plaintext prior to
authenticity check.  It's not immediately clear that this text needs to
change, though if it's also not a key point, perhaps it is easier to
just drop the mention rather than think about it more, though I'd also
be happy to see discussion of issues with streaming decryption in the
security considerations section.

Section 5.3

  A CBOR-based protocol MUST specify which of these options its
  decoders take, for each kind of invalid item they might encounter.

Are the lists of types of validity error presented in the following
subsections exhaustive for the respective data models?  If so, it might
be worth mentioning that explicitly.

Section 5.4

  *  It can report an error (and not return data).  Note that this
      error is not a validity error per se.  This kind of error is more
      likely to be raised by a decoder that would be performing validity
      checking if this were a known case.

(soapbox) Could we maybe be a little less encouraging of this behavior?
I am remembering horror stories of TLS stacks that did this for
extension types, which is an interoperability nightmare.  I recognize
that there are cases where it is the desired behavior, but in the
general case tags are an extensibility point and we shouldn't encourage
that joint to rust shut.

Section 5.6.1

  As discussed in Section 2.2, specific data models can make values
  equivalent for the purpose of comparing map keys that are distinct in
  the generic data model.  Note that this implies that a generic
  decoder may deliver a decoded map to an application that needs to be
  checked for duplicate map keys by that application (alternatively,
  the decoder may provide a programming interface to perform this
  service for the application).  Specific data models cannot
  distinguish values for map keys that are equal for this purpose at
  the generic data model level.

This last bit seems like something that is forbidden by the protocol (vs
"cannot"); I wonder if a slight rewording is in order.

Section 6.2

  *  Numbers with fractional parts are represented as floating-point
      values, performing the decimal-to-binary conversion based on the
      precision provided by IEEE 754 binary64.  Then, when encoding in

I forget if this conversion requires round-to-nearest or if multiple
rounding modes are available (the latter would of course be problematic
if we proceed on to the "can be represented in smaller float without
changing value" step).

Section 8

  The notation borrows the JSON syntax for numbers (integer and
  floating-point), True (>true<), False (>false<), Null (>null<), UTF-8

(soapbox) Is literal '>' and '<' really the best quoting strategy here
(and later on)?

Section 9.1, 9.2

What guidance can we give to the experts?

Section 9.3

  Applications that use this media type:  None yet, but it is expected
      that this format will be deployed in protocols and applications.

I don't believe this to be currently accurate.

  Additional information:  *  Magic number(s): n/a

I guess 0xd9d9f7 doesn't count, then?

Section 9.4

  The CoAP Content-Format for CBOR is defined in
  [IANA.core-parameters]:

Is "defined in" the right way to word this?

Section 10

I guess the attack where you use indefinite-length encoding to achieve
total 'n' greater than 2**64 is not really practical at present...

Please add a mention of the risks of mixing a constrained decoder with a
variant (non-preferred-serialization) encoder, as alluded to in Section
4.1.

I also mention this down in G.3, but there seem to be some relevant
considerations regarding whether/when bignums and integers of the same
value are considered to be equivalent, in particular that the situation
is different depending on the data model in use.  This could probably
fit nicely into general discussion of handling the multiple possible
serializations of various data items.

I would consider (but am not sure if I would end up adding) a mention
that CBOR can convey time values, and thus that protocols using CBOR to
convey time values are likely to rely on a source of accurate time.

I might incorporate by reference the RFC 4648 security considerations
since we talk about base64 in several places.

Protocols using CBOR text strings will likely have internationalization
considerations; whether CBOR itself should mention this is not entirely
clear to me.

The potential loss of (e.g., type) information when converting from CBOR
to JSON is probably worth a mention, noting that applications performing
such conversions should consider whether they are affected and/or it's
desired to include specific type information in the generated JSON.

  numbers may exceed linear effort.  Also, some hash-table
  implementations that are used by decoders to build in-memory
  representations of maps can be attacked to spend quadratic effort,
  unless a secret key (see Section 7 of [SIPHASH]) or some other
  mitigation is employed.  Such superlinear efforts can be exploited by

It seems likely that an alternate reference not behind a paywall would
be usable to make this point.

Section 11.2

Would not [PCRE] need to be normative (if that functionality remains,
per the DISCUSS)?

Appendix A

[I did not verify the examples.]

  ATTIC FIFTY STATERS).  (Note that all these single-character strings
  could also be represented in native UTF-8 in diagnostic notation,
  just not in an ASCII-only specification like the present one.)  In

The present specification is not ASCII-only...

Appendix C

    return 0;                    // no break out

Should this be 'return mt'?  IIUC the return value is a message type
or -1 for the break code, and errors are indicated out of band via
fail().

  void encode_sint(int64_t n) {
    uint64t ui = n >> 63;    // extend sign to whole length
    mt = ui & 0x20;          // extract major type

If this is supposed to be C, you probably want to declare mt.

Appendix F

  *  major type 7, additional information 24, value < 32 (incorrect or
      incorrectly encoded simple type)

I see "incorrectly encoded", but I'm not sure I understand what is meant
by "incorrect simple type".

Appendix G.3

  integers and floating point values.  Experience from implementation
  and use now suggested that the separation between these two number
  domains should be more clearly drawn in the document; language that
  suggested an integer could seamlessly stand in for a floating point
  value was removed.  Also, a suggestion (based on I-JSON [RFC7493])

So instead we have skew between the generic data model and the extended
model, where the generic model thinks some numers are different that the
extended model treats as the same.  Should we mention that here as well?
2020-09-07
14 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-08-31
14 Samita Chakrabarti Request for Telechat review by IOTDIR is assigned to Eve Schooler
2020-08-31
14 Samita Chakrabarti Request for Telechat review by IOTDIR is assigned to Eve Schooler
2020-08-31
14 Éric Vyncke Requested Telechat review by IOTDIR
2020-08-28
14 Cindy Morgan Placed on agenda for telechat - 2020-09-10
2020-08-28
14 Barry Leiba Ballot has been issued
2020-08-28
14 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2020-08-28
14 Barry Leiba Created "Approve" ballot
2020-08-28
14 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2020-08-14
14 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2020-08-13
14 Tim Evens Request for Last Call review by GENART Completed: Ready. Reviewer: Tim Evens. Sent review to list.
2020-08-13
14 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2020-08-13
14 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cbor-7049bis-14. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-cbor-7049bis-14. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, the Concise Binary Object Representation (CBOR Simple Values was created through the publication of RFC7049.

The registry is located at:

https://www.iana.org/assignments/cbor-simple-values/

[ RFC-to-be ] does not change the rules for maintenance for the registry other than indicate that Standards Actions allocate values starting with the number 16 in order to reserve the lower numbers for contiguous blocks (if any). The reference for the registry and the existing registrations will be changed from RFC7049 to [ RFC-to-be ]. IANA understands that there are no other changes to be made to this registry.

Second, the Concise Binary Object Representation (CBOR) Tags was also created through the publication of RFC7049.

The registry is located at:

https://www.iana.org/assignments/cbor-tags/

IANA understands that [ RFC-to-be ] does not change the rules for maintenance for the registry. However, the reference for the registry, the reference for the template for new registrations, and the references for existing registrations from RFC7049 will be changed from RFC7049 to [ RFC-to-be ]. IANA understands that there are no other changes to be made to this registry.

Third, in the application registry of the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

there is an existing registration for application/cbor. The template for this registration will be updated to reflect the template supplied in section 9.3 of [ RFC-to-be ] and the reference for this registration will be changed from RFC7049 to [ RFC-to-be ].

Fourth, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

the existing registration for ID = 60:

Media Type: application/cbor
Encoding: -
Id: 60
Reference: RFC7049

will have its reference changed from RFC7049 to [ RFC-to-be ].

Fifth, in the Structured Syntax Suffix Registry located at:

https://www.iana.org/assignments/media-type-structured-suffix/

there is an existing registration for =suffix = +cbor. The reference for that registration will be changed to [ RFC-to-be ]. The security considerations section should refer to Section 10 of [ RFC-to-be ]. The contact for the registration is changed to:

IETF CBOR Working Group cbor@ietf.org (mailto:cbor@ietf.org) or IETF Applications and Real-Time Area art@ietf.org (mailto:art@ietf.org)

The Author/Change Controller is changed to:

The IESG iesg@ietf.org (mailto:iesg@ietf.org)

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-08-10
14 Yaron Sheffer Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Yaron Sheffer. Sent review to list.
2020-08-06
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2020-08-06
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Yaron Sheffer
2020-08-04
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2020-08-04
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2020-07-24
14 Jean Mahoney Request for Last Call review by GENART is assigned to Tim Evens
2020-07-24
14 Jean Mahoney Request for Last Call review by GENART is assigned to Tim Evens
2020-07-24
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2020-07-24
14 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-08-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-cbor-7049bis@ietf.org, Francesca Palombini , barryleiba@gmail.com, cbor-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2020-08-14):

From: The IESG
To: IETF-Announce
CC: draft-ietf-cbor-7049bis@ietf.org, Francesca Palombini , barryleiba@gmail.com, cbor-chairs@ietf.org, francesca.palombini@ericsson.com, cbor@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Concise Binary Object Representation (CBOR)) to Internet Standard


The IESG has received a request from the Concise Binary Object Representation
Maintenance and Extensions WG (cbor) to consider the following document: -
'Concise Binary Object Representation (CBOR)'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-08-14. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Concise Binary Object Representation (CBOR) is a data format
  whose design goals include the possibility of extremely small code
  size, fairly small message size, and extensibility without the need
  for version negotiation.  These design goals make it different from
  earlier binary serializations such as ASN.1 and MessagePack.

  This document is a revised edition of RFC 7049, with editorial
  improvements, added detail, and fixed errata.  This revision formally
  obsoletes RFC 7049, while keeping full compatibility of the
  interchange format from RFC 7049.  It does not create a new version
  of the format.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-cbor-7049bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4648: The Base16, Base32, and Base64 Data Encodings (Proposed Standard - IETF stream)
    rfc4287: The Atom Syndication Format (Proposed Standard - IETF stream)
    rfc3339: Date and Time on the Internet: Timestamps (Proposed Standard - IETF stream)
    rfc2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (Draft Standard - IETF stream)



2020-07-24
14 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-07-24
14 Cindy Morgan Last call announcement was changed
2020-07-23
14 Barry Leiba Last call was requested
2020-07-23
14 Barry Leiba Last call announcement was generated
2020-07-23
14 Barry Leiba Ballot approval text was generated
2020-07-23
14 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation
2020-07-23
14 Barry Leiba Ballot writeup was changed
2020-07-23
14 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2020-06-17
14 Francesca Palombini
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Internet Standard. This is the proper type of RFC, as CBOR has achieved a high degree of technical maturity and its implementations have obtained successful operational experience. This is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

It is worth noting the controversy about the text on how generic decoders handle duplicate map keys. While RFC7049 stated that decoders cannot prescribe a specific handling of duplicated map keys, except it might consider the map malformed, part of the working group wanted the document to state more precisely what the decoder should do, and possibly what the protocol using CBOR should do (e.g. use first entry). This was considered, but would have made existing implementation non-compliant with this specification. Consensus was difficult to call, but in the end some text was added to explain the different options (reject the map, accept the map including the duplicates, lose some entries) and give guidance to implementations on what is expected of the application in every one of these cases. (See section 5.6)

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There exist a significant number of implementations of this specification, see https://cbor.io/impls.html for a non-exhaustive list.
Several of the working group participants have provided continuous reviews to the document, and have agreed that the document is ready for publication.

Personnel:

Francesca Palombini is the Document Shepherd. Barry Leiba is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document several times during its lifetime, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Not particularly.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors are in full compliance with BCPs 78 and 79 and there is no known IPR directly related to this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The working group consensus is solid. One issue has created more contention, and is reported in (2).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Although some points were contentious (see above), noone has threatened an appeal or indicated extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits were found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No required formal review was needed for this revision.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references. There are 3 non-RFC normative references: ECMA262, IEEE754, and IEEE Std. 1003.1 (TIME_T).
IEEE 754 (now 2019 edition) is in a very high state of maturity.
The regular expression part referenced from ECMA 262 also is at the needed level of maturity (the document only references the approximate format as a tag validity criteria).
The UNIX ("Posix") time format described in IEEE Std. 1003.1 is also very stable and well-understood in the community.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, this document will obsolete RFC7049. That is clearly stated in the title page, abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section is different from RFC7049 in the fact that it points to the registries that were created in RFC7049. It additionally requires IANA to update the references of these existing registries to point to this specification. For one existing registry, the contact and change control have been updated. For the Tags Registry, the registration policy has changed, with consensus of the working group.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries have been created.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No automated checks were performed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not contain any YANG module.
2020-06-17
14 Francesca Palombini Responsible AD changed to Barry Leiba
2020-06-17
14 Francesca Palombini IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2020-06-17
14 Francesca Palombini IESG state changed to Publication Requested from I-D Exists
2020-06-17
14 Francesca Palombini IESG process started in state Publication Requested
2020-06-17
14 Francesca Palombini Changed consensus to Yes from Unknown
2020-06-17
14 Francesca Palombini Intended Status changed to Internet Standard from None
2020-06-17
14 Francesca Palombini
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Internet Standard. This is the proper type of RFC, as CBOR has achieved a high degree of technical maturity and its implementations have obtained successful operational experience. This is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

It is worth noting the controversy about the text on how generic decoders handle duplicate map keys. While RFC7049 stated that decoders cannot prescribe a specific handling of duplicated map keys, except it might consider the map malformed, part of the working group wanted the document to state more precisely what the decoder should do, and possibly what the protocol using CBOR should do (e.g. use first entry). This was considered, but would have made existing implementation non-compliant with this specification. Consensus was difficult to call, but in the end some text was added to explain the different options (reject the map, accept the map including the duplicates, lose some entries) and give guidance to implementations on what is expected of the application in every one of these cases. (See section 5.6)

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There exist a significant number of implementations of this specification, see https://cbor.io/impls.html for a non-exhaustive list.
Several of the working group participants have provided continuous reviews to the document, and have agreed that the document is ready for publication.

Personnel:

Francesca Palombini is the Document Shepherd. Barry Leiba is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document several times during its lifetime, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Not particularly.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors are in full compliance with BCPs 78 and 79 and there is no known IPR directly related to this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The working group consensus is solid. One issue has created more contention, and is reported in (2).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Although some points were contentious (see above), noone has threatened an appeal or indicated extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits were found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No required formal review was needed for this revision.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references. There are 3 non-RFC normative references: ECMA262, IEEE754, and IEEE Std. 1003.1 (TIME_T).
IEEE 754 (now 2019 edition) is in a very high state of maturity.
The regular expression part referenced from ECMA 262 also is at the needed level of maturity (the document only references the approximate format as a tag validity criteria).
The UNIX ("Posix") time format described in IEEE Std. 1003.1 is also very stable and well-understood in the community.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, this document will obsolete RFC7049. That is clearly stated in the title page, abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section is different from RFC7049 in the fact that it points to the registries that were created in RFC7049. It additionally requires IANA to update the references of these existing registries to point to this specification. For one existing registry, the contact and change control have been updated. For the Tags Registry, the registration policy has changed, with consensus of the working group.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries have been created.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No automated checks were performed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not contain any YANG module.
2020-06-17
14 Francesca Palombini
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Internet Standard. This is the proper type of RFC, as CBOR has achieved a high degree of technical maturity and its implementations have obtained successful operational experience. This is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

It is worth noting the controversy about the text on how generic decoders handle duplicate map keys. While RFC7049 stated that decoders cannot prescribe a speecific handling of duplicated map keys, except it might consider the map malformed, part of the working group wanted the document to state more precisely what the decoder should do, and possibly what the protocol using CBOR should do (e.g. use first entry). This was considered, but would have made existing implementation non-compliant with this specification. Consensus was difficult to call, but in the end some text was added to explain the different options (reject the map, accept the map including the duplicates, lose some entries) and give guidance to implementations on what is expected of the application in every one of these cases. (See section 5.6)

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There exist a significant number of implementations of this specification, see https://cbor.io/impls.html for a non-exhaustive list.
Several of the working group participants have provided continuous reviews to the document, and have agreed that the document is ready for publication.

Personnel:

Francesca Palombini is the Document Shepherd. Barry Leiba is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed this document several times during its lifetime, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Not particularly.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors are in full compliance with BCPs 78 and 79 and there is no known IPR directly related to this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The working group consensus is solid. One issue has created more contention, and is reported in (2).

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

Although some points were contentious (see above), noone has threatened an appeal or indicated extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits were found.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No required formal review was needed.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references. There are 2 non-RFC normative references: ECMA262 and IEEE754.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, this document will obsolete RFC7049. That is clearly stated in the title page, abstract and introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations section is different from RFC7049 in the fact that it points to the registries that were created in RFC7049. It additionally requires IANA to update the references of these existing registries to point to this specification. For one existing registry, the contact and change control have been updated. For the Tags Registry, the registration policy has changed, with consensus of the working group.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new IANA registries have been created.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No automated checks were performed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not contain any YANG module.
2020-06-16
14 Carsten Bormann New version available: draft-ietf-cbor-7049bis-14.txt
2020-06-16
14 (System) New version accepted (logged-in submitter: Carsten Bormann)
2020-06-16
14 Carsten Bormann Uploaded new revision
2020-03-17
13 Francesca Palombini Added to session: interim-2020-cbor-06
2020-03-10
13 Francesca Palombini WGLC ends on March 23.
2020-03-10
13 Francesca Palombini Tag Revised I-D Needed - Issue raised by WG cleared.
2020-03-10
13 Francesca Palombini IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead
2020-03-08
13 Carsten Bormann New version available: draft-ietf-cbor-7049bis-13.txt
2020-03-08
13 (System) New version accepted (logged-in submitter: Carsten Bormann)
2020-03-08
13 Carsten Bormann Uploaded new revision
2019-12-18
12 Carsten Bormann New version available: draft-ietf-cbor-7049bis-12.txt
2019-12-18
12 (System) New version accepted (logged-in submitter: Carsten Bormann)
2019-12-18
12 Carsten Bormann Uploaded new revision
2019-12-18
11 Carsten Bormann New version available: draft-ietf-cbor-7049bis-11.txt
2019-12-18
11 (System) New version accepted (logged-in submitter: Carsten Bormann)
2019-12-18
11 Carsten Bormann Uploaded new revision
2019-12-18
10 Carsten Bormann New version available: draft-ietf-cbor-7049bis-10.txt
2019-12-18
10 (System) New version accepted (logged-in submitter: Carsten Bormann)
2019-12-18
10 Carsten Bormann Uploaded new revision
2019-12-16
09 Francesca Palombini Tag Revised I-D Needed - Issue raised by WG set.
2019-12-16
09 Francesca Palombini IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2019-12-03
09 Francesca Palombini Notification list changed to Francesca Palombini <francesca.palombini@ericsson.com>
2019-12-03
09 Francesca Palombini Document shepherd changed to Francesca Palombini
2019-12-03
09 Francesca Palombini Working group started 2019-11-14, ending 2019-12-13.
see https://mailarchive.ietf.org/arch/msg/cbor/HSMkPkDdHCKwP9nvO-oUWLsRv3c
2019-12-03
09 Francesca Palombini IETF WG state changed to In WG Last Call from WG Document
2019-11-07
09 Francesca Palombini Added to session: IETF-106: cbor  Thu-1740
2019-11-04
09 Carsten Bormann New version available: draft-ietf-cbor-7049bis-09.txt
2019-11-04
09 (System) New version accepted (logged-in submitter: Carsten Bormann)
2019-11-04
09 Carsten Bormann Uploaded new revision
2019-11-04
08 Carsten Bormann New version available: draft-ietf-cbor-7049bis-08.txt
2019-11-04
08 (System) New version accepted (logged-in submitter: Carsten Bormann)
2019-11-04
08 Carsten Bormann Uploaded new revision
2019-08-25
07 Paul Hoffman New version available: draft-ietf-cbor-7049bis-07.txt
2019-08-25
07 (System) New version approved
2019-08-25
07 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Paul Hoffman
2019-08-25
07 Paul Hoffman Uploaded new revision
2019-07-20
06 Francesca Palombini Added to session: IETF-105: cbor  Tue-1000
2019-07-02
06 Paul Hoffman New version available: draft-ietf-cbor-7049bis-06.txt
2019-07-02
06 (System) New version approved
2019-07-02
06 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Paul Hoffman
2019-07-02
06 Paul Hoffman Uploaded new revision
2019-03-20
05 Francesca Palombini Added to session: IETF-104: cbor  Thu-0900
2019-01-15
05 Paul Hoffman New version available: draft-ietf-cbor-7049bis-05.txt
2019-01-15
05 (System) New version approved
2019-01-15
05 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Paul Hoffman
2019-01-15
05 Paul Hoffman Uploaded new revision
2018-11-03
04 Francesca Palombini Added to session: IETF-103: cbor  Wed-0900
2018-10-22
04 Carsten Bormann New version available: draft-ietf-cbor-7049bis-04.txt
2018-10-22
04 (System) New version approved
2018-10-22
04 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Paul Hoffman
2018-10-22
04 Carsten Bormann Uploaded new revision
2018-09-20
03 Carsten Bormann New version available: draft-ietf-cbor-7049bis-03.txt
2018-09-20
03 (System) New version approved
2018-09-20
03 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Paul Hoffman
2018-09-20
03 Carsten Bormann Uploaded new revision
2018-09-03
02 (System) Document has expired
2018-07-16
02 Francesca Palombini Added to session: IETF-102: cbor  Tue-1330
2018-03-12
02 Francesca Palombini Added to session: IETF-101: cbor  Tue-1330
2018-03-02
02 Paul Hoffman New version available: draft-ietf-cbor-7049bis-02.txt
2018-03-02
02 (System) New version approved
2018-03-02
02 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Paul Hoffman
2018-03-02
02 Paul Hoffman Uploaded new revision
2017-10-14
01 Paul Hoffman New version available: draft-ietf-cbor-7049bis-01.txt
2017-10-14
01 (System) New version approved
2017-10-14
01 (System) Request for posting confirmation emailed to previous authors: Carsten Bormann , Paul Hoffman
2017-10-14
01 Paul Hoffman Uploaded new revision
2017-04-13
00 Paul Hoffman New version available: draft-ietf-cbor-7049bis-00.txt
2017-04-13
00 (System) WG -00 approved
2017-04-12
00 Paul Hoffman Set submitter to "Paul Hoffman ", replaces to (none) and sent approval email to group chairs: cbor-chairs@ietf.org
2017-04-12
00 Paul Hoffman Uploaded new revision