Subject: [Simple] [Editorial Errata Reported] RFC4975 (4177)

From: RFC Errata System <[email-masked]>
Date: Thu, 13 Nov 2014 09:56:50 -0800 (PST)

The following errata report has been submitted for RFC4975,
"The Message Session Relay Protocol (MSRP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4975&eid=4177

--------------------------------------
Type: Editorial
Reported by: Archie Cobbs <[email-masked]>

Section: 7.1

Original Text
-------------
   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

Corrected Text
--------------
   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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4975 (draft-ietf-simple-message-sessions-19)
--------------------------------------
Title               : The Message Session Relay Protocol (MSRP)
Publication Date    : September 2007
Author(s)           : B. Campbell, Ed., R. Mahy, Ed., C. Jennings, Ed.
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Extensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Nov 2014 11:24:03 -1000

Hi Archie -

You'll find lots of cases where we don't specify what to do when the 
peer violates the protocol.
(Not just in this document, but in RFCs in general). Trying to encompass 
the entire scope of such violations is impossible,
and we rely on Postel's maxim instead.

Is there a particular point of interoperability failure where having 
this as a requirement would help the protocol, or is it
(as I read it) just one of several ways that an implementation could do 
something reasonable when the peer goes off the rails?

If it's the latter, I think we should mark this errata as invalid (not 
that the point isn't good, but a new requirement in the document isn't 
how to
express it).

RjS

On 11/13/14 7:56 AM, RFC Errata System wrote:
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Nov 2014 11:34:52 -1000

Hi All -

My original reply to this only went to the simple list.
You can find it here:

https://mailarchive.ietf.org/arch/msg/simple/q4QdGGgbZHmL6kxQ3zz6VOpEQJU

RjS

---

From: Archie Cobbs <[email-masked]>
Date: Thu, 13 Nov 2014 15:45:10 -0600

Thanks, I agree with your assessment.

-Archie

-- 
Archie L. Cobbs