RFC 4992, "XML Pipelining with Chunks for the Internet Registry Information Service", August 2007

Note: This RFC has been updated by RFC 8996

Errata ID: 2830
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Rejected by: Peter Saint-Andre
Date Rejected: 2011-08-01

Section 6.5 says:

   These fields MUST NOT span multiple chunks.  Therefore, it should be
   noted that SASL data length exceeding the length of the chunk minus
   the length of SASL profile name minus one is an error.

It should say:

   These fields MUST NOT span multiple chunks.  Therefore, it should be
   noted that a mechanism data length exceeding the length of the chunk
   minus the mechanism name length minus three is an error.

Notes:

This section presents the diagram below (and subsequent field
explanations):

+-----------+-----------+-----------+-----------+
field | mechanism | mechanism | mechanism | mechanism |
| name | name | data | data |
| length | | length | |
+-----------+-----------+-----------+-----------+
octets 1 variable 2 variable

SASL Authentication


Apparently, the fate of the 'mechanism data length' field once has
been unsure, and it (almost) seems to be a redundant field anyway.

As specified, the data handed out by a SASL mechanism as a single
protocol message must be contained within the 'mechanism data' field
of a single chunk.
Apparently, there are no provisions for chunk padding in the protocol.
Therefore, according to the figure quoted above in item (A.2) and
the above figure, for these chunks the following equation holds
(for clarity, I denote the content of a field by giving the field
name in angular braces):

<chunk data length> = 1 ; length of 'name length' field
+ <name length>
+ 2 ; length of 'mechanism data length' field
+ <mechanism data length>

This leads to the conclusion that the 'mechanism data length' field
is redundant; I suspect it was left out from the SASL chunk structure
at the time when the paragraph quoted below was drafted.

Taking all together, the paragraph above makes no sense:

o The undefined term 'SASL data length' should be replaced with the
defined term, 'mechanism data length'.

o SASL *profiles* are not discussed in this memo,
the text consistently should talk about SASL *mechanism*s,
and use the defined field name, 'mechanism name length'.

o The constant overhead is *three* bytes, not *one*.

Furthermore, proper articles should be inserted to improve the language.

[Separating into individual errata from 1009]
--VERIFIER NOTES--
The authors of the specification note that the terms
being interchanged are defined to be equivalent in
section 6.5, so there is no substantive issue. This
could be adjusted editorially if the documents are
updated.

Report New Errata