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

Robert Sparks <rjsparks@nostrum.com> Thu, 13 November 2014 21:24 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: simple@ietfa.amsl.com
Delivered-To: simple@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728A31AD5EB for <simple@ietfa.amsl.com>; Thu, 13 Nov 2014 13:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level:
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBggcWyTHTpU for <simple@ietfa.amsl.com>; Thu, 13 Nov 2014 13:24:10 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958A51AD5D4 for <simple@ietf.org>; Thu, 13 Nov 2014 13:24:04 -0800 (PST)
Received: from unnumerable.local ([130.129.11.137]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sADLO3sD041789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <simple@ietf.org>; Thu, 13 Nov 2014 15:24:04 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [130.129.11.137] claimed to be unnumerable.local
Message-ID: <54652173.9090509@nostrum.com>
Date: Thu, 13 Nov 2014 11:24:03 -1000
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: simple@ietf.org
References: <20141113175650.3A11A181C8D@rfc-editor.org>
In-Reply-To: <20141113175650.3A11A181C8D@rfc-editor.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/simple/q4QdGGgbZHmL6kxQ3zz6VOpEQJU
Subject: Re: [Simple] [Editorial Errata Reported] RFC4975 (4177)
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/simple/>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Nov 2014 21:24:14 -0000

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 <archie.cobbs@gmail.com>;
>
> 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
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple