RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 11 records.

Status: Verified (3)

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

Source of RFC: crisp (app)

Errata ID: 1009

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Peter Saint-Andre
Date Verified: 2011-08-01

Section Appendix A says:

   C:           (chunk 1)
   C: 0x44      (LC=no,DC=yes,CT=sd)
   C: 0x00 0x11 (chunk length=11)

It should say:

   C:           (chunk 1)
   C: 0x44      (LC=no,DC=yes,CT=sd)
   C: 0x00 0x12 (chunk length=18)

Notes:

Apparently, there is an inconsistency in chunk 1 of the first request block, closely related to errata ID 2830, and this has nurtured my suspicion reported there that perhaps the 'mechanism data length' field has been added late in the draft history, without sufficient care.

The first chunk data field has the following components:
SASL mechanism "PLAIN" ... 1 + 5 octets
10 octets of SASL PLAIN data ... 2 + 10 octets
This sums up to (decimal) 18 octets, or 0x12.

[Separated out other errata from this one. This was the last erratum originally reported in 1009.]

Errata ID: 2829

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Peter Saint-Andre
Date Verified: 2011-08-01

Section 6.2 says:

  Chunks of this type contain XML conformant to the schema specified in
  [9] and MUST have the <versions> element as the root element.

It should say:

   Chunks of this type MUST contain XML conformant to the schema
   specified in [9] and MUST have the <versions> element as the root
   element, unless sent by the Client to solicit version information;
   client to server chunks may be zero length, as detailed below.

Notes:

Note: This erratum was separated off from erratum #1009.

The reporter of the erratum said:

As already mentioned earlier in the text and clarified in the
second-to-last paragraph of the same section, this requirements
language is improper because it is intended to allow clients to
send this type of chunk as well, with unspecified (perhaps empty)
content, to be ignored by the server.

The authors of the specification provided the following notes:

We recommend accepting the error reported in Erratum ID 2829,
but we do not recommend accepting the proposed fix. The issue
is that the MUSTs listed in the original apply when the server
emits this, but not to the client when it is soliciting this.
We recommend the following:

"Chunks of this type MUST contain XML conformant to the schema
specified in [9] and MUST have the <versions> element as the
root element, unless sent by the Client to solicit version
information; client to server chunks may be zero length, as
detailed below."

Errata ID: 2827

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Pete Resnick
Date Verified: 2011-06-11

Section 4 says:

|                 [...].  Conceptually, a CRB is a type of RQB; they
   share the same format, but a CRB is constrained in conveying only
   specific information and is only sent at the beginning of the session
   lifecycle.

It should say:

|                 [...].  Conceptually, a CRB is a type of RSB; they
   share the same format, but a CRB is constrained in conveying only
   specific information and is only sent at the beginning of the session
   lifecycle.

Notes:

Separating separate errata from 1009.

Status: Held for Document Update (7)

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

Source of RFC: crisp (app)

Errata ID: 2832

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Peter Saint-Andre
Date Held: 2011-06-11

Section 6.5 says:

   o  mechanism data length - the length of the SASL data.

It should say:

   o  mechanism data length - the length of the SASL data,
      or the special value 65535 (to indicate the absence of
      an initial SASL response -- see below).

Notes:

The final paragraph of Section 6.5 (i.e., the 2nd paragraph
on page 12) says:

When used as an initial challenge response for SASL mechanisms that
support such a feature, the mechanism data length may be set to a
decimal value of 65,535 to indicate an absent initial response. A
value of 0 indicates an empty initial response.

Apparently, the need to subtly distinguish an absent initial response
from an empty initial response is the only justification left for the
existence of the 'mechanism data length' field.
But this information could be conveyed in a single flag bit.

[Separating into individual errata from 1009]

Errata ID: 2828

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 6 says:

        +-----------+------------+--------+
   field | chunk     | chunk data | chunk  |
         | descriptor| length     | data   |
         +-----------+------------+--------+
   octets      1            2      variable

                                  chunk

It should say:

         +-----------+------------+--------+
   field | chunk     | chunk data | chunk  |
         | descriptor| length     | data   |
         +-----------+------------+--------+
   octets      1            2      variable

                                  Chunk

Notes:

The figure caption of the last diagram in Section 6, at the bottom
of page 8, resembles mis-spaced spurious text because it is not
written with headline capitalisation (as all othe similar figure
captions are).

[Separating into individual errata from 1009]

Errata ID: 2831

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 6.5 says:

    ... a server can determine authentication status ...

It should say:

    ... a server can determine the authentication status ...

Notes:

[Separating into individual errata from 1009]

Errata ID: 2836

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section Appendix A says:

   C:           (request block)
   C: 0x00      (block header: V=0,KO=no)

It should say:

   C:           (request block)
   C: 0x20      (block header: V=0,KO=yes)

Notes:

The introductory text, near the top of page 26, says:

[...]. Note that the
client requests that the connection stay open for further requests,
but the server does not honor this request.

This example should better be corrected to show the KO bit as announced, for educational purposes.

[Separating into individual errata from 1009]

Errata ID: 2833

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 6.6 says:

		   where as

It should say:

                   whereas

Notes:

[Separating into individual errata from 1009]

Errata ID: 2834

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 10 says:

   Section 6.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is
   the default transport for IRIS.  [...]

It should say:

   Section 7.2 of RFC 3981 [1] (IRIS-CORE) states that IRIS-BEEP [2] is
   the default transport for IRIS.  [...]

Notes:

[Separating into individual errata from 1009]

Errata ID: 2835

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Pete Resnick
Date Held: 2011-06-11

Section 14.1 says:

      Anonymous client access SHOULD be considered in one of two
      methods:

It should say:

   Anonymous client access SHOULD be considered in one of two methods:

Notes:

Near the bottom of page 17, the paragraph introducing the list of
numbered items is indented too much.

[Separating into individual errata from 1009]

Status: Rejected (1)

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

Source of RFC: crisp (app)

Errata ID: 2830

Status: Rejected
Type: Technical

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



Search RFCs
Advanced Search
×