RFC Errata
Found 13 records.
Status: Verified (1)
RFC 4976, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", September 2007
Note: This RFC has been updated by RFC 7977, RFC 8553, RFC 8996
Source of RFC: simple (rai)
Errata ID: 1272
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Verifier Name: Robert Sparks
Date Verified: 2010-04-28
Section 4.6 (p.12) says:
[...]. Specifically, an Expires header in an AUTH
request indicates how long the provided URIs will be valid.
It should say:
[...]. Specifically, an Expires header field in an
AUTH response indicates how long the provided URIs will be valid.
Notes:
At the bottom of page 12:
a) terminology -- cf GLOBAL errata report
b) s/request/response/ !!!
Status: Held for Document Update (11)
RFC 4976, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", September 2007
Note: This RFC has been updated by RFC 7977, RFC 8553, RFC 8996
Source of RFC: simple (rai)
Errata ID: 1269
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:
a) Header b) Headers c) header d) headers
It should say:
a) Header Field b) Header Fields c) header field d) header fields
Notes:
In some parts of the text, RFC 4976 makes confusing sluggish use of
established IETF standard terminology.
Since RFC 2045 ff., and reinforced by many more RFCs, the distinction
between "header" and the elements of a header, "header fields" should be
clear to all. I once again recommend BCP 90, RFC 3864, and in particular
Section 3.1.1 of RFC 4249 for clarification of this terminological issue.
Hint:
Additionally, the RFC sometimes is not precise enough in distinguishing
the parts of a header field from the whole, e.g. saying "header" where
it should say "header field value" ; this issue will be mentioned below
as case e) and additionally be addressed in specific errata reports.
Note: Remarkably, other parts of RFC 4976, and the whole companion
document, RFC 4975, do not suffer from this deficiency.
The following parts of RFC 4976 suffer from the four variants
of this abuse of language shown in the OLD / NEW boxes above:
a) headlines of Sections 4.2, 4.3, 4.4, and 4.5
b) headline of Sections 4.6 and 10.2
c) - text of section 4.2 (5 instances),
- text of section 4.3 (1 instance),
- text of section 4.4 (1 instance),
- text of section 4.5 (1 instance),
- text of section 4.6 (8 instances),
- text of section 5.1 (18 instances),
- text of section 6.3 (6 instances),
- text of section 6.4.1 (5 instances),
- text of section 6.4.2 -- see extra report,
- text of section 6.4.3 (5 instances),
- text of section 9.1 (6 instances),
- text of section 9.4 (2 instances)
d) - text of section 4.2 (1 instance),
- text of section 9.1 (2 instances)
e) - text of section 6.4.1 (2 instances)
Errata ID: 1273
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 5.2 - pg.17 says:
<< 3rd message shown >>
MSRP m4nbvx 200 OK
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://extra.example.com;tcp
| Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
| msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: [...]
<< 4th message shown >>
MSRP m3nbvx 200 OK
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
| Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: [...]
It should say:
<< 3rd message >>
MSRP m4nbvx 200 OK
To-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://extra.example.com;tcp
| Use-Path: msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: [...]
<< 4th message >>
MSRP m3nbvx 200 OK
To-Path: msrps://alice.example.com:9892/98cjs;tcp
From-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com;tcp
| Use-Path: msrps://intra.example.com:9000/jui787s2f;tcp \
msrps://extra.example.com:9000/mywdEe1233;tcp
Authentication-Info: [...]
Notes:
In both messages, the "Use-Path:" header fields are garbled.
This should draw the attention to the lack of specification in the RFC
(cf. extra report) for the Relay behavior w.r.t. Use-Path in repsonses.
From descriptive text in the RFC it becomes clear that the 3rd message
above should contain one URI in the Use-Path header field, and that the
second one shown there in fact needs to be added by the relay into the
4th message (final response to the client).
The simple URI repetition shown in the 4th message doen not make sense
at all.
Errata ID: 1274
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 6.4.1, pa.2 says:
If the Failure-Report header is "yes", then the relay MUST run a timer to detect if transmission to the next hop fails. [...]
It should say:
If the Failure-Report header field value is "yes", then the relay MUST run a timer to detect if transmission to the next hop fails. [...]
Notes:
Cf. GLOBAL errata report on terminology.
Errata ID: 1275
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 6.4.1,p.22 says:
[...]. In this case, the relay SHOULD discard
| the message, and if the Failure-Report header is set to "yes", the
relay SHOULD generate a failure report.
It should say:
[...]. In this case, the relay SHOULD discard
| the message, and if the Failure-Report header field value is set to
"yes", the relay SHOULD generate a failure report.
Notes:
The offending text is at the end of the last paragraph of Section 6.4.1.
For rationale, cf. the GLOBAL errata report on terminology.
Errata ID: 1277
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 7, page 23 says:
WWW-Authenticate = "WWW-Authenticate:" SP "Digest" SP digest-param
*("," SP digest-param)
digest-param = ( realm / nonce / [ opaque ] / [ stale ] / [
algorithm ] / qop-options / [auth-param] )
It should say:
WWW-Authenticate = "WWW-Authenticate:" SP "Digest" SP digest-param
*("," SP digest-param)
| ; realm, nonce, and qop digest-params are required
| digest-param = ( realm / nonce / opaque / stale / algorithm
| / qop-options / auth-param )
Notes:
a) The prose of the RFC indicates that the restriction stated in the
added ABNF comment indeed should hold. See also note below.
b) The <digest-param> syntax as stated in the RFC makes no sense;
allowing optional productions in the ABNF alternative would allow
empty <digest-param>s , i.e. immediately adjacent commas in the
WWW-Authenticate header field value; I suspect that the square
brackets might have been intended to indicate what I suggest to
express in the ABNF comment a).
To express the full set of requirements for WWW-Authenticate in pure,
formal ABNF would perhaps make it much less readable.
These issues are replicated for <credentials> and <digest-response>
-- this is addressed in a separate report.
Errata ID: 1278
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 7, p.23/24 says:
credentials = "Digest" SP digest-response
*( "," SP digest-response)
digest-response = ( username / realm / nonce / response / [
algorithm ] / cnonce / [opaque] / message-qop /
[nonce-count] / [auth-param] )
It should say:
credentials = "Digest" SP digest-response
*( "," SP digest-response)
| ; mandatory digest-response items are:
| ; username, realm, nonce, response, cnonce,
| ; and message-qop
| digest-response = ( username / realm / nonce / response
| / algorithm / cnonce / opaque / message-qop
| / nonce-count / auth-param )
Notes:
For rationale, see the related report on <WWW-Authenticate> and
<digest-param> ABNF.
Errata ID: 1270
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
Throughout the document, when it says:
... in Section 5.1
It should say:
... in Section 5.1 and 9.1
Notes:
The text in Sections 4.3 through 4.5 refers to Section 5.1
for the details of HTTP Digest authentication.
Most of these in fact are in Section 9.1; thus the reader
should be directly advised to consult Section 9.1 as well.
It might even be better to only point to 9.1 in these 3 instances.
Note: The pointer to Section 5.1 given in Section 4.2 seems to be
appropriate.
Errata ID: 1271
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 4.2, 1st par says:
The Use-Path header is a list of URIs provided by an MSRP relay in response to a successful AUTH request. [...]
It should say:
The Use-Path header field contains a list of URIs provided by an MSRP relay in response to a successful AUTH request. [...]
Notes:
a) terminology -- cf. GLOBAL errata reoprt
b) misleading verb: "is" --> "contains"
Errata ID: 1279
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 App. A,p.35 says:
[...]. When implementing something like this,
| implementors should be careful not to use a scheme like EBE that
| would allows portions of encrypted tokens to be cut and pasted into
other URIs.
It should say:
[...]. When implementing something like this,
implementors should be careful not to use a scheme like EBE (..???..)
that would allow portions of encrypted tokens to be cut and pasted
into other URIs.
Notes:
a) Newly introduced abbreviation -- never explained ==> need expansion
Please supply!
b) Grammar: s/allows/allow/
Errata ID: 2695
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rockson Li
Date Reported: 2011-01-30
Held for Document Update by: Robert Sparks
Section 6.4.3 says:
The relay sends the request over the best connection that corresponds to the next URI in the To-Path header.
It should say:
The relay sends the response over the best connection that corresponds to the next URI in the To-Path header.
Notes:
This is section is talking about handling response.
typo "request" should be "response"
Errata ID: 2993
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2011-10-12
Held for Document Update by: Robert Sparks
Section 3 says:
Alice a.example.org b.example.net Bob
| | | |
|--- SEND 1-3 ------->| | |
|<-- 200 OK ----------| | (slow link) |
|--- SEND 4-7 ------->|--- SEND 1-5 ------>| |
|<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
|--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>|
|<-- 200 OK ----------|<-- 200 OK ---------| ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT 1-3 ------|
| |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
|<-- REPORT 1-3 ------| | ...>|
| | |<-- REPORT 4-7 ----->|
| |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
|<-- REPORT 4-7 ------| | ..>|
| | |<-- 200 OK ----------|
| |<-- REPORT done-----|<-- REPORT done -----|
|<-- REPORT done -----| | |
| | | |
It should say:
Alice a.example.org b.example.net Bob
| | | |
|--- SEND 1-3 ------->| | |
|<-- 200 OK ----------| | (slow link) |
|--- SEND 4-7 ------->|--- SEND 1-5 ------>| |
|<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
|--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>|
|<-- 200 OK ----------|<-- 200 OK ---------| ..>|
| | |<-- 200 OK ----------|
| | |<-- REPORT 1-3 ------|
| |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
|<-- REPORT 1-3 ------| | ...>|
| | |<-- 200 OK ----------|
| | |<-- REPORT 4-7 ----->|
| |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
|<-- REPORT 4-7 ------| | ..>|
| | |<-- 200 OK ----------|
| |<-- REPORT done-----|<-- REPORT done -----|
|<-- REPORT done -----| | |
| | | |
Notes:
The flow in page 10 lacks the mandatory 200 OK for the SEND 4-7 received by Bob.
Status: Rejected (1)
RFC 4976, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", September 2007
Note: This RFC has been updated by RFC 7977, RFC 8553, RFC 8996
Source of RFC: simple (rai)
Errata ID: 1276
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-01-14
Rejected by: Robert Sparks
Date Rejected: 2011-02-21
Section 6.4.3 says:
<< NONE >>
It should say:
<< add to the end of the section: >> Before forwarding a 200 response containing a Use-Path header field, the relay MUST prepend to the existing header field value the URI it supplies and wants the upstream neighbor to use in future requests in this session.
Notes:
As sadly confirmed by the flaws in the example in Section 5.1 (on p. 17),
the Relay Behavior / Handling Responses underspecifies the required
synthesis of the Use-Path header field value.
The above text is a strawman proposal and should be elaborated upon
before signing off this report.
--VERIFIER NOTES--
From reviewer Dale Worley:
The suggested change is incorrect. The value of the Use-Path header
generated by the server-relay in the 200 response is not intended to
be modified by any intermediate relay on the way to the client. This
can be seen by (1) the lack of any text specifying any transformation
of the Use-Path value by intermediate relays, and (2) the skeleton
example in section 5.1, page 14, which says "Use-Path returned by C: B
C". (In that example, a better rendering would be "Use-Path returned
by C: Btoken Ctoken".)
A relay can generate a complete Use-Path because the initial elements
can be extracted from the From-Path value of the request.