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

Indeed, troublesome sentence removed in upcoming version.

-- Tom

On 11/16/2012 06:41 PM, Gonzalo Camarillo wrote:
> 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
>>>        
>
>    