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

From: Tom Kristensen <[email-masked]>
Date: Tue, 13 Nov 2012 09:32:24 +0100

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Nov 2012 10:49:26 +0200

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 15 Nov 2012 20:10:00 +0000

I agree that we need to do something here. The text reads:

   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: [email-masked] [mailto:[email-masked]] 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,
> 
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 16 Nov 2012 19:41:07 +0200

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