RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search