errata logo graphic

Found 13 records.

Status: Verified (1)

RFC4976, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", September 2007

Source of RFC: simple (rai)

Errata ID: 1272

Status: Verified
Type: Technical

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)

RFC4976, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", September 2007

Source of RFC: simple (rai)

Errata ID: 1269

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:

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

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

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

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

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

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

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

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

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

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

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)

RFC4976, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", September 2007

Source of RFC: simple (rai)

Errata ID: 1276

Status: Rejected
Type: Technical

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.


Report New Errata