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

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

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

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

Cheers,
Charles

> > 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
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis