[bfcpbis] TBD issue #3: MAY discard malformed message, not sending Error

Tom Kristensen <tomkrist@cisco.com> Tue, 13 November 2012 08:32 UTC

Return-Path: <tomkrist@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B8D5921F844B for <bfcpbis@ietfa.amsl.com>; Tue, 13 Nov 2012 00:32:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.932
X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aZqB+x-24c9J for <bfcpbis@ietfa.amsl.com>; Tue, 13 Nov 2012 00:32:26 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 05D7021F8444 for <bfcpbis@ietf.org>; Tue, 13 Nov 2012 00:32:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1403; q=dns/txt; s=iport; t=1352795546; x=1354005146; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=GWDAi6CTCiR8b5Jwp7vsi9fLsvHkX4MzMpUw7ENAN+U=; b=YEQcwrGGmWUFsGQ4VE4tsidGk81VpxqbWo2tLEJhhS4cwP6zd5mziCLH txU9IJO1Pg0KSK8vx6x/5AkN4bw0hekeNJrDETvjRm/kBFP01UYu8P7V6 ShRjs9c80dV7FJFyVEkEBlNIULhac+67SUQAesfL0hMwT00xa+mds+MHn w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EADsFolCQ/khR/2dsb2JhbABEw3OBCII3ASVAATwWGAMCAQIBSw0BBwEBHodomiePZZA4knUDlXyFa4htgWuCcIFaBg
X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="78188387"
Received: from ams-core-1.cisco.com ([]) by ams-iport-2.cisco.com with ESMTP; 13 Nov 2012 08:32:24 +0000
Received: from [] (dhcp-10-54-86-33.cisco.com []) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAD8WOBO007856; Tue, 13 Nov 2012 08:32:24 GMT
Message-ID: <50A20598.6040603@cisco.com>
Date: Tue, 13 Nov 2012 09:32:24 +0100
From: Tom Kristensen <tomkrist@cisco.com>
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10
MIME-Version: 1.0
To: BFCPbis WG <bfcpbis@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: [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: Tue, 13 Nov 2012 08:32:26 -0000

Minor issue, just need a decision!

 > 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."

| 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