RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Reported (3)

RFC 9171, "Bundle Protocol Version 7", January 2022

Source of RFC: dtn (int)

Errata ID: 7272
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML

Reported By: Brian Sipos
Date Reported: 2022-12-12

Section 4.2.5.1.1 says:

dtn-hier-part = "//" node-name name-delim demux ; a path-rootless

node-name = reg-name

demux = *VCHAR

It should say:

dtn-hier-part = "//" node-name name-delim demux [ "?" query ]

node-name = reg-name

demux = path-rootless / path-empty

Notes:

The demux portion of an EID should match only URI path segments and not match query or fragment URI parts. A fragment part should not actually be sent as encoded EID to be consistent with other URI uses (e.g. HTTP). The administrative endpoint is the allowed empty demux path.

Errata ID: 7337
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Carsten Bormann
Date Reported: 2023-02-06

Section Appendix B says:

   ; Actual CBOR data embedded in a byte string, with optional tag to
   indicate so.
 
...
 
   ; Extension block type, which does not specialize other than the
   code/number

...

   payload-block = payload-block-structure .within canonical-block-
   structure

It should say:

   ; Actual CBOR data embedded in a byte string, with optional tag to
   ; indicate so.

... 
 
   ; Extension block type, which does not specialize other than the
   ; code/number

...

   payload-block = payload-block-structure .within
                   canonical-block-structure

Notes:

Various line breaking events cause syntax errors while parsing Appendix B.

Errata ID: 8043
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: John Huff
Date Reported: 2024-07-22

Section 4.3.1 says:

   CRC:  A CRC SHALL be present in the primary block unless the bundle
      includes a BPSec Block Integrity Block [BPSEC] whose target is the
      primary block, in which case a CRC MAY be present in the primary
      block.  The length and nature of the CRC SHALL be as indicated by
      the CRC type.  The CRC SHALL be computed over the concatenation of
      all bytes (including CBOR "break" characters) of the primary block
      including the CRC field itself, which, for this purpose, SHALL be
      temporarily populated with all bytes set to zero.

It should say:

   CRC:  A CRC SHALL be present in the primary block unless the bundle
      includes a BPSec Block Integrity Block [BPSEC] whose target is the
      primary block, in which case a CRC MAY be present in the primary
      block.  The length and nature of the CRC SHALL be as indicated by
      the CRC type.  The CRC SHALL be computed over the concatenation of
      all bytes (including CBOR "break" characters) of the primary block
      including the CRC field itself, which, for this purpose, SHALL be
      temporarily populated with all value bytes set to zero. The
      initial byte of the CBOR encoded CRC field SHALL remain unchanged.

Notes:

There was some confusion about the wording of "temporarily populated with all bytes set to zero" when talking about the CRC field in the CBOR encoded primary block. An implementer thought this might mean to also zeroize the intial byte(s) of the CBOR encoded byte string that represents the CRC field. This correction makes it clear that only the bytes that represent the value of the CRC field should be zeroized when calculating the CRC.

My correction uses "initial byte" because the current CRC types will only ever have a single intial byte when encoding the CRC value as a CBOR byte string. However, technically CBOR byte strings can byte more than 1 initial byte so it may be better to use "initial byte(s)".

Status: Held for Document Update (1)

RFC 9171, "Bundle Protocol Version 7", January 2022

Source of RFC: dtn (int)

Errata ID: 7881
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: John Huff
Date Reported: 2024-04-03
Held for Document Update by: Erik Kline
Date Held: 2024-04-07

Section 6.1.1 says:

   The first element of each bundle status item SHALL be a status
   indicator, a Boolean value indicating whether or not the
   corresponding bundle status is asserted, encoded as a CBOR Boolean
   value.

It should say:

   The first element of each bundle status item SHALL be a status
   indicator, a Boolean value indicating whether or not the
   corresponding bundle status is asserted, encoded as a CBOR simple
   value.  A value of 'true' SHALL be encoded as a CBOR simple value
   with additional information 21.  A value of 'false' SHALL be encoded
   as a CBOR simple value with additional information 20.

Notes:

The CBOR spec does not define a 'Boolean' type (RFC8949). It's become common practice to encode boolean values as simple values (major type 7), with additional information 21 indicating 'true' and additional information 20 indicating 'false' (RFC9254, RFC8152). However, this should be explicitly stated for clarity.

--- comments ---

The original text refers to "Boolean values" and not to any "Boolean type"; it is technically correct as is.

As noted, CBOR doesn't have a specific "type" per se for a Boolean, but RFC 8948 S3.3 clearly specifies an encoding for `true` and `false`.

That said, there might be room here for additional clarity for implementers if there is ever to be a 9171bis.

Report New Errata



Advanced Search