Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis

["Charles Eckel (eckelcu)" <[e-mail]>]

That all works for me.

Thanks,
Charles

> -----Original Message-----
> From: Tom Kristensen (tomkrist)
> Sent: Wednesday, October 10, 2012 2:04 AM
> To: Charles Eckel (eckelcu)
> Cc: [e-mail]
> Subject: Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis
> 
> On 09/25/2012 12:18 AM, Charles Eckel (eckelcu) wrote:
> 
> Reply comments inline.
> 
> > (as an individual)
> >
> > I have reviewed the draft and I think that overall it is in very good shape.
> The only comment I would consider major is one dealing with section 4's
> description of server-initiated transactions:
> >
> > Section 4 reads as follows:
> >
> >     There are two types of transaction in BFCP: client-initiated
> >     transactions and server-initiated transactions.  Client-initiated
> >     transactions consist of a message from a client to the floor control
> >     server and a response from the floor control server to the client.
> >     Correspondingly, server-initiated transactions consist of a message
> >     from the floor control server to a client and the associated
> >     acknowledgement message from the client to the floor control server.
> >     Both messages can be related because they carry the same Transaction
> >     ID value in their common headers.
> >
> > This is accurate when using UDP as the transport, but does not account for
> the case of using TCP as the transport. A more detailed and accurate
> description is provided in Section 8, which reads as follows:
> >
> >     In BFCP, there are two types of transactions: client-initiated
> >     transactions and server-initiated transactions (notifications).
> >     Client-initiated transactions consist of a request from a client to a
> >     floor control server and a response from the floor control server to
> >     the client.  The request carries a Transaction ID in its common
> >     header, which the floor control server copies into the response.
> >     Clients use Transaction ID values to match responses with previously
> >     issued requests.
> >
> >     Server-initiated transactions consist of a single message from a
> >     floor control server to a client.  Since they do not trigger any
> >     response, their Transaction ID is set to 0 when used over reliable
> >     transports, but must be non-zero and unique in the context of
> >     outstanding transactions over unreliable transports.
> >
> > I suggest replacing the section 4 text with the following introductory level
> text, that currently exists in section 8 .
> >
> >     In BFCP, there are two types of transactions: client-initiated
> >     transactions and server-initiated transactions (notifications).
> >
> > The rest of the details currently in section 4 can  replaced with a reference
> to section 8.
> >
> I agree. Good catch as well, since the section 4 text is unchanged from
> RFC 4582 - and amusingly enough fits with the semantics of UDP/BFCP!
> > I also have the following minor  comments.
> >
> > 1) Section 5.2.6, note after table 5
> > r/is intended being used/is intended to be used
> >
> OK.
> > 2) Section 5.3.14 current reads as follows:
> >
> >     Floor participants and chairs acknowledge the receipt of a subsequent
> >     FloorRequestStatus message from the floor control server when
> >     communicating over unreliable transport.
> >
> > I suggest the following rewording:
> >
> >     When communicating over unreliable transport, floor participants and
> chairs
> >     acknowledge the receipt of a subsequent FloorRequestStatus message
> from
> >     the floor control server by sending an FloorRequestStatusAck.
> >
> > 3) Similar change for section 5.3.15.
> >
> OK for 2) and 3). Easier to read and understand.
> > 4) Section 6.2, currently contains the following fragment:
> >
> >     Only allowing exactly one BFCP message or message segment per UDP
> >     datagram.
> >
> > This is covered previously in the paragraph, so this fragment can be
> removed.
> >
> Fine, but I'll add "... or message segment" to the previous sentence, so
> that it reads:
>   "Each BFCP UDP datagram MUST contain exactly
>     one BFCP message or message segment"
> > 5) Section 6.2,
> > r/Entities MUST only have at most one/Entities MUST have at most one
> >
> Agree, better language!
> > 6) Section 6.2.1
> > r/attempt, this is identical/attempt. This is identical
> OK.
> 
> 
> I'll change the upcoming rfc4582bis version accordingly if no objections
> or further comments on these issues are received.
> 
> -- Tom