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

[Gonzalo Camarillo <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bfcpbis