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

[Robert Sparks <[e-mail]>]

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:
> 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 <[e-mail]>
>
> 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
>
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple