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

Gonzalo Camarillo <> Tue, 13 November 2012 08:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B1EB21F84B2 for <>; Tue, 13 Nov 2012 00:49:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106
X-Spam-Status: No, score=-106 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z31YOCwSfZn6 for <>; Tue, 13 Nov 2012 00:49:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 85EC821F8488 for <>; Tue, 13 Nov 2012 00:49:29 -0800 (PST)
X-AuditID: c1b4fb30-b7f936d0000018b3-2b-50a20996e474
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 74.B2.06323.69902A05; Tue, 13 Nov 2012 09:49:26 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 13 Nov 2012 09:49:26 +0100
Message-ID: <>
Date: Tue, 13 Nov 2012 10:49:26 +0200
From: Gonzalo Camarillo <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Tom Kristensen <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Rnca56IAg67rBhb/1h1lsrhy5Beb A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxtSu7YBt/xb7Nk5gaGJfxdDFyckgImEgc uL2TFcIWk7hwbz1bFyMXh5DASUaJZV/+MIMkhARWM0qc/6sBYvMKaEvMO3oKrIFFQFVi2atn 7CA2m4CFxJZb91lAbFGBKIlDGw+yQ9QLSpyc+QQsLiKgLtG39ztYnFlAUeJKVy9YXFjAW2L5 0l42iF0aEtMX/QabzymgKbHtZTsTxHGSEm/fv2KG6NWTmHK1hRHClpfY/nYO1J3aEsuftbBM YBSahWT1LCQts5C0LGBkXsXInpuYmZNebr6JERioB7f8NtjBuOm+2CFGaQ4WJXFePdX9/kIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYd2RtKDXzn6TzVXahz+mvQp9/+2uvC5IyOWPxLeM+ X9A0h5bkHffbORnXzFpcqRNYUtd5ec7L5sz1BX6zJkgdYN0bMvGs2qSb5lohH5Z4907pOR/M /EPr2beO9H+5Wnxe3J841a74f5X5KrJ7i8XZLJVLP/ylwkKWvLVX2nFphZrDOoncf6lRSizF GYmGWsxFxYkAMYewSSICAAA=
Cc: BFCPbis WG <>
Subject: Re: [bfcpbis] TBD issue #3: MAY discard malformed message, not sending Error
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: BFCPBIS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Nov 2012 08:49:31 -0000


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.



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