RFC Errata
Found 8 records.
Status: Verified (1)
RFC 4975, "The Message Session Relay Protocol (MSRP)", September 2007
Note: This RFC has been updated by RFC 7977, RFC 8591, RFC 8873, RFC 8996
Source of RFC: simple (rai)
Errata ID: 1954
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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.
Status: Held for Document Update (7)
RFC 4975, "The Message Session Relay Protocol (MSRP)", September 2007
Note: This RFC has been updated by RFC 7977, RFC 8591, RFC 8873, RFC 8996
Source of RFC: simple (rai)
Errata ID: 1281
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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: 4177
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Archie Cobbs
Date Reported: 2014-11-13
Held for Document Update by: Orie Steele
Date Held: 2024-04-01
Section 7.1 says:
line, and a flag character. If a body is present, the end-line MUST be preceded by a CRLF that is not part of the body. If the chunk represents the data that forms the end of the complete message, the flag value MUST be a "$". If the sender is aborting an incomplete message, and intends to send no further chunks in that message, the flag MUST be a "#". Otherwise, the flag MUST be a "+". If the request contains a body, the sender MUST ensure that the end- line (seven hyphens, the transaction identifier, and a continuation flag) is not present in the body. If the end-line is present in the
It should say:
line, and a flag character. If a body is present, the end-line MUST be preceded by a CRLF that is not part of the body. If the chunk represents the data that forms the end of the complete message, the flag value MUST be a "$". If the sender is aborting an incomplete message, and intends to send no further chunks in that message, the flag MUST be a "#". Otherwise, the flag MUST be a "+". If the request contains a body, the sender MUST ensure that the end- line (seven hyphens, the transaction identifier, and a continuation flag) is not present in the body. A receiver detecting an end-line present in the body preceded by a non-empty sequence other than CRLF SHOULD terminate the session. If the end-line is present in the
Notes:
The way the text is written leaves unspecified how a receiver should handle the situation where it encounters an end-line within the body that's preceded by something OTHER than CRLF.
Obviously, this indicates the sender is not complying with this RFC, but what should the receiver do?
Should the receiver terminate the connection? Or just proceed giving no special interpretation to the end-line, which would actually work just fine?
The suggested change reflects the first choice. If the second choice were made, the change could be:
If the request contains a body, the sender MUST ensure that the
end-line (seven hyphens, the transaction identifier, and a continuation
flag) neither appears at the beginning of the body nor is not present
in the body preceded by CRLF. An end-line MAY appear in the body if
preceded in the body by any non-empty sequence other than CRLF.
This would force the interpretation that an end-line not preceded by CRLF has no special significance.
Errata ID: 1280
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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). [...]