Re: [bfcpbis] TBD issue #3: MAY discard malformed message, not sending Error
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Fri, 16 November 2012 17:41 UTC
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B715C21F899A for <bfcpbis@ietfa.amsl.com>; Fri, 16 Nov 2012 09:41:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.038
X-Spam-Level:
X-Spam-Status: No, score=-106.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s0UviEgwpTH for <bfcpbis@ietfa.amsl.com>; Fri, 16 Nov 2012 09:41:09 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 52C5E21F84D8 for <bfcpbis@ietf.org>; Fri, 16 Nov 2012 09:41:09 -0800 (PST)
X-AuditID: c1b4fb25-b7f926d00000661f-d0-50a67ab4a2d1
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C4.EB.26143.4BA76A05; Fri, 16 Nov 2012 18:41:08 +0100 (CET)
Received: from [131.160.126.232] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Fri, 16 Nov 2012 18:41:07 +0100
Message-ID: <50A67AB3.3070405@ericsson.com>
Date: Fri, 16 Nov 2012 19:41:07 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
References: <50A20598.6040603@cisco.com> <50A20996.8010503@ericsson.com> <92B7E61ADAC1BB4F941F943788C0882812C776@xmb-aln-x08.cisco.com>
In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882812C776@xmb-aln-x08.cisco.com>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM+Jvje6WqmUBBnt+CFv8W3eUyWLTrC9s FleO/GJzYPaY8nsjq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKmL2hgKWiRr5g07QBLA+NPiS5G Tg4JAROJ1Q9OsEDYYhIX7q1n62Lk4hASOMkosfTNZyhnLaNE45v/jCBVvALaEr0LpjKD2CwC qhLXr68Bs9kELCS23LoPNklUIEri0MaD7BD1ghInZz4Bi4sIGEosmrQOzGYWCJNY8X4XE4gt LBAu8fbCMrA5QgLtjBIfj/iB2JwC3hK3Ni1lhbhOUuLt+1fMEL16ElOutjBC2PIS29/OgerV llj+rIVlAqPQLCSrZyFpmYWkZQEj8ypG9tzEzJz0cqNNjMCwPbjlt+oOxjvnRA4xSnOwKInz Wm/d4y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsduz/u/pa+uqNE881DlVsHBDa93hQpGe 2z8OVdTOy5y8Y9KWDSl9BUfsL8bpS07Ib/+zp5+FedcpIT0u8wU8zl7CG/lS9yUIdn/9LriN 8fC+/1Kyd2V3b2+4P23aQ4GTXc+/rzjZ0qNhmXEl4U1cy9+a59rqpzg3z7po9bPdvPXwmcaa oxq7+JVYijMSDbWYi4oTAQBWC3gpAgAA
Cc: BFCPbis WG <bfcpbis@ietf.org>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
Subject: Re: [bfcpbis] TBD issue #3: MAY discard malformed message, not sending Error
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Nov 2012 17:41:10 -0000
Hi, if you want to describe a procedure that is likely to have the system recover from the error, I am OK with that. Otherwise, describing a procedure that is not likely to help and will confuse implementers is clearly not a good idea ;-) In short, I am fine with removing the text. Cheers, Gonzalo On 15/11/2012 10:10 PM, Charles Eckel (eckelcu) wrote: > I agree that we need to do something here. The text reads: > > If the message can be parsed to the extent that it is able to discern > that it was a response to an outstanding request transaction, the > client MAY discard the message as the client will retransmit the > message when the retransmit timer T1 specified in Section 8.3.1 > fires. > > If the message is determined to be a response, then in general there will not be any retransmission, correct? I think the real question is whether or not the receiver of such a response should send its original request again in hopes of it resulting in a response that can be parsed. This seems like a bad idea as it is likely to result in receiving the same response again. This could go on indefinitely. > My preference is to remove the sentence entirely. We could and perhaps replace it with something warning against retransmitting the original request, but I don't think that is necessary and it might merely confuse matters more. > > Cheers, > Charles > >> -----Original Message----- >> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On >> Behalf Of Gonzalo Camarillo >> Sent: Tuesday, November 13, 2012 12:49 AM >> To: Tom Kristensen (tomkrist) >> Cc: BFCPbis WG >> Subject: Re: [bfcpbis] TBD issue #3: MAY discard malformed message, not >> sending Error >> >> Hi, >> >> the point here is that a retransmission is, by definition, identical to >> the original message. So, if you receive a message and do nothing, when >> you receive the retransmission you will behave in an identical manner >> (i.e., you will do nothing), since the retransmission will be identical >> to the original message... and detecting an error and letting the client >> retransmit a few messages instead of reporting the error does not seem >> like a good strategy. >> >> Cheers, >> >> Gonzalo >> >> On 13/11/2012 10:32 AM, Tom Kristensen wrote: >>> Minor issue, just need a decision! >>> >>> Gonzalo: >>>> The following paragraph (the second sentence in particular) needs to >>>> be clarified. The paragraph starts talking about a floor control >>>> server receiving a message and then talks about a client discarding >>>> the message. Also, why would an entity discard a message only to >>>> receive a retransmission of the *same* message later? It is not clear >>>> what the paragraph means. >>>> >>>> "If a Floor Control Server receives data that cannot be parsed, the >>>> receiving server SHOULD send an Error message with parameter value 10 >>>> (Unable to parse message) indicating receipt of a malformed message. >>>> If the message can be parsed to the extent that it is able to discern >>>> that it was a response to an outstanding request transaction, the >>>> client MAY discard the message as the client will retransmit the >>>> message when the retransmit timer T1 specified in Section 8.3.1 >>>> fires." >>> >>> Tom: >>> | My understanding is that one might skip sending the Error message >>> | and just wait for the retransmission, that will come. However, this >>> | sort of optimization might be removed. Not needed and even >> mentioned >>> | just as a MAY. >>> >>> So again, should it stay or should it go? No problem removing the second >>> sentence, no real functional change. Or we could clarify the sentence by >>> adding that in this case no Error message is sent. >>> >>> -- Tom >>> >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis
- [bfcpbis] TBD issue #3: MAY discard malformed mes… Tom Kristensen
- Re: [bfcpbis] TBD issue #3: MAY discard malformed… Gonzalo Camarillo
- Re: [bfcpbis] TBD issue #3: MAY discard malformed… Charles Eckel (eckelcu)
- Re: [bfcpbis] TBD issue #3: MAY discard malformed… Gonzalo Camarillo
- Re: [bfcpbis] TBD issue #3: MAY discard malformed… Tom Kristensen