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

[Gonzalo Camarillo <[e-mail]>]

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
>