Subject: [Simple] Errata report 1954 on RFC 4975 "MSRP" and errata 1273 and 1276 on RFC 4976 "Relay Extensions for MSRP"

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 26 Oct 2010 15:57:29 -0400

======================================================================
RFC4975, "The Message Session Relay Protocol (MSRP)"
Source of RFC: simple (rai)

Errata ID: 1954

Status: Reported
Type: Technical

Reported By: Dennis Noordsij
Date Reported: 2009-12-03

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.
----------------------------------------------------------------------
Recommended status:  (Correct.)  Verified

A sufficiently experienced person would recognize the error in any
operational system, but it is not good to have the BNF be incorrect,
especially since there are no instances of ext-header in the examples
to contradict the incorrect BNF.
======================================================================
RFC4976, "Relay Extensions for the Message Session Relay Protocol (MSRP)"
Source of RFC: simple (rai)

Errata ID: 1273

Status: Reported
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-14

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.
----------------------------------------------------------------------
Recommended status:  (Correct (partially)) Hold for document update

(This should refer to section 5.1.)

The erraum is partially correct.  The Use-Path value shown in the RFC
for the 3rd message is correct.  (That is because the full Use-Path
value is generated by the server-relay.  See report on erratum 1276
for details.)  But the Use-Path value shown in the RFC for the 4th
message is incorrect; it should contain the same two URIs that are in
the Use-Path value for the 3rd message.

The correct form of the two messages is:

<< 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://intra.example.com:9000/jui787s2f;tcp \
              msrps://extra.example.com:9000/mywdEe1233;tcp
    Authentication-Info: [...]

======================================================================
RFC4976, "Relay Extensions for the Message Session Relay Protocol (MSRP)"
Source of RFC: simple (rai)

Errata ID: 1276

Status: Reported
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-14

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.
----------------------------------------------------------------------
Recommended status:  (Incorrect) Rejected

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.
======================================================================

Dale