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

From: "Horvath, Ernst" <[email-masked]>
Date: Mon, 25 Jun 2012 13:19:11 +0000

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?

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".

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.

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.

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.

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.

Regards,
Ernst

---

From: Tom Kristensen <[email-masked]>
Date: Tue, 26 Jun 2012 14:07:36 +0200

> 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.

>     receiving participant MAY send an Error message with parameter value
True also here.

> to be consistent with text on other error cases.
Yes, this seems to be a plausible clarification on how to react in that 
case.

> 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…
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?

> 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 c…
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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jun 2012 18:12:34 +0000

( as an individual)
All the proposed changes look good to me. One comment inline regarding Tom's question.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tom Kristensen
> Sent: Tuesday, June 26, 2012 5:08 AM
> To: Horvath, Ernst
> Cc: [email-masked]
> Subject: Re: [bfcpbis] RFC 4582bis: More comments on error handling
> 
> > 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.
> >
> > 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?
> >
> > "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",
> > 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.
> >

Yes, that is my understanding as well, and I agree that clarification text would be helpful.

Cheers,
Charles

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