|
|
|
|
Found 7 records.
Errata ID: 1954
Status: Verified
Type: Technical
Reported By: Dennis Noordsij
Date Reported: 2009-12-03
Verifier Name: Robert Sparks
Date Verified: 2010-10-28
Section 9 says:
ext-header = hname ":" SP hval CRLF
It should say:
ext-header = hname ":" SP hval
Notes:
The rule:
headers = To-Path CRLF From-Path CRLF 1*( header CRLF )
already suffixes every header with a CRLF. The result is that the extension headers are followed by 2 CRLFs, introducing empty lines inside the header segment. This appears to be unintended, since none of the other headers have a terminating CRLF in their production rules, only the ext-header.
Errata ID: 1281
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks
Throughout the document, when it says:
<headers> <header> <ext-header>
It should say:
<hfields> <hfield> <ext-hfield>
Notes:
Note on Terminology:
To help avoid the terminological issues observed in the companion
document, RFC 4976, and reduce the likelihood of similar issues in
future derived work, it would perhaps have been useful to subtly
change the ABNF in Section 9 (and all related references in the prose),
replacing three rule names:
<headers> --> <hfields>
<header> --> <hfield>
<ext-header> --> <ext-hfield>
Errata ID: 1282
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks
Section 9, p.38 says:
hname = ALPHA *token
It should say:
hname = ALPHA [token] (or use: hname = ALPHA *1token )
Notes:
This resolves a potential parsing ambiguity,
and should also improve the readability.
Errata ID: 1286
Status: Held for Document Update
Type: Technical
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks
Section 15.5.1,p.57 says:
Contact: Ben Campbell (ben@estacado.net).
Author/Change Controller: This is a permanent registration request.
Change control does not apply.
It should say:
Contact: Ben Campbell (ben@estacado.net). | Author/Change Controller: IESG.
Notes:
(This only is a proposal.)
Rationale: Congratulations! The registrant seems to have achieved
immortality, and/or his email address guaranteed to be perpetual. :-)
More seriously: cf. Section 3 of RFC 2434.
Errata ID: 1280
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks
Section 7.1.1,p.19 says:
<<< at the end of the (indented) second paragraph >>
[...] For example, an endpoint could concatenate an instance
identifier such as a MAC address, its idea of the number of
seconds since the epoch, a process ID, and a monotonically
increasing 16-bit integer, all base-64 encoded. Alternately, an
endpoint without an on-board clock could simply use a 64-bit
random number.
It should say:
[...] For example, an endpoint could concatenate an instance
identifier such as a MAC address, its idea of the number of
seconds since the epoch, a process ID, and a monotonically
increasing 16-bit integer, all base-64 encoded. Alternately, an
endpoint without an on-board clock could simply use a 64-bit
| random number and base-64 encode it.
Notes:
Clarification; otherwise, "Alternately" could be grossly misunderstood
to indicate a direct alternative for the header field value.
Errata ID: 1284
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks
Section 13, p.48 says:
... "message/ cpim" ...
It should say:
... "message/cpim" ...
Notes:
Within quoted text literals, white space might be considered
significant; thus, to avoid any potential ambiguity .... :-)
Errata ID: 1285
Status: Held for Document Update
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Held for Document Update by: Robert Sparks
Section 15.2, p.55 says:
| This specification establishes the header field-Field sub-registry under MSRP Parameters. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). [...]
It should say:
| This specification establishes the Header Field sub-registry under MSRP Parameters. New parameters in this sub-registry must be published in an RFC (either as an IETF submission or RFC Editor submission). [...]