Re: [bfcpbis] RFC 4582bis: More comments on error handling

[Tom Kristensen <[e-mail]>]

On 06/25/2012 03:19 PM, Horvath, Ernst wrote:
> The following items are some comments on error procedures in draft-ietf-bfcpbis-rfc4582bis-03. I noticed that some of them concern text inherited from RFC4582, which should nevertheless be fixed in 4582bis.
>
> 1) Ambiguous text in 5.1:
>
> In the sentence on top of page 17: "If a BFCP entity receives a
>     message with an unsupported version field value, the receiving
>     participant MAY send an Error message with parameter value 12 to
>     indicate this",
> Shouldn't "BFCP entity" better be "Floor Control Server" and "paricipant" be "server", given that Error is a message for the server to client direction according to table 1?
>    
I agree, that is a more correct description here.

> Similarly on page 18:  "If a BFCP entity
>     receives a message with an incorrect payload length field value, the
>     receiving participant MAY send an Error message with parameter value
>     13 to indicate this".
>    
True also here.

> 2) In 5.2, 1st paragraph below table 2, the sentence
> "If an unrecognized attribute with the 'M' bit set is received, the message is rejected"
> could be expanded to
> "If a Floor Control Server receives an unrecognized attribute with the 'M' bit set the server MAY (or SHOULD/MUST?) send an Error message with parameter value 4 to indicate this",
> to be consistent with text on other error cases.
>    
Yes, this seems to be a plausible clarification on how to react in that 
case.

> 3) In 5.2.6, regarding the sentence below Figure 12:
>    "Error Code: This 8-bit field contains an error code from the
>     following table.  If an error code is not recognized by the receiver,
>     then the receiver MUST assume that an error exists, and therefore
>     that the message is processed, but the nature of the error is
>     unclear.",
> I don't understand what "the message is processed" refers to - the processing of the original message by the sender of Error or the processing of the received error message. Maybe a clearer wording can be found.
>    
I read this as meaning the original message (that triggered the Error 
back) was processed and we may add text underlining this - given this is 
the interpretation by other people as well?

> 4) In 6.2, 4th paragraph, the sentence
> "If a BFCP entity receives data that cannot be parsed, the receiving participant MAY send an Error message with parameter value 10 indicating receipt of a malformed message"
> has the same problem as indicated in comment 1) above.
>    
Will fix!

> 5) In 13, last paragraph, "with Error code 2 (Authentication Failed)" is wrong. First, code 2 means "User does not Exist" (there is no error code for "Authentication Failed"), and second, I think code 4 (Unknown Mandatory Attribute) is meant here.
>    
Indeed, I agree with you. Good catch - especially since "Authentication 
Failed" doesn't even exist.


Thanks for good comments based on what must be a thorough review of the 
draft!

-- Tom