Subject: [dispatch] Comments on draft-sandbakken-dispatch-bfcp-udp-02

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Jul 2011 16:56:34 +0200

Just a few minor comments. Although this is still to be "dispatched", they will need attending to in due course.

1. The Introduction dives too quickly into what the draft does. It should first introduce BFCP and explain that it is designed for transport over TCP.

2. "Existing implementations, in the spirit
   of the approach detailed in earlier versions of this draft (see
   Appendix A), have demonstrated the approach to be feasible."
This seems to suggest that the approach in this version is in some respects different from the approach in earlier versions, and implies that existing implementations do not follow the approach in this version. I don't think that is intended, so perhaps some better words can be found. In addition, in the final RFC we will presumably no longer be able to refer to Appendix A (that would be removed) and the words "earlier versions of this draft" will be inappropriate.

3. In section 4.9.2:
"Implicit
   subscriptions, such as FloorRequest messages that have multiple
   responses as the floor control server processes intermediate states
   until Granted or Denied terminal states attained, can be
   characterized by a client-initiated request transaction whose
   acknowledgement is implied by the first FloorRequestStatus response
   from the floor control server.  The subsequent changes in state for
   the request are new transactions whose Transaction ID is determined
   by the floor control server and whose receipt by the client
   participant shall be acknowledged with a FloorRequestStatusAck
   message.  [Editorial note: would it be more straightforward to have
   all FloorRequestStatus messages acknowledged with a
   FloorRequestStatusAck message?]"
Would it not be better to avoid implicit responses, i.e., have an explicit response to the client-initiated request, and an explicit response to each FloorRequestStatus?

4. There are several instances where the word "clause" is used to refer to text in the existing RFC. It is not always clear what is meant, e.g., I think "sentence" is sometimes the intention.

John

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 15 Jul 2011 12:24:57 -0700

Hi John,

Thank you for the comments. Please see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Friday, July 15, 2011 7:57 AM
> To: [email-masked]
> Subject: [dispatch] Comments on draft-sandbakken-dispatch-bfcp-udp-02
> 
> Just a few minor comments. Although this is still to be "dispatched",
they will need attending to in
> due course.
> 
> 1. The Introduction dives too quickly into what the draft does. It
should first introduce BFCP and
> explain that it is designed for transport over TCP.

Good idea. I will add that.

> This seems to suggest that the approach in this version is in some
respects different from the
> approach in earlier versions, and implies that existing
implementations do not follow the approach in
> this version. I don't think that is intended, so perhaps some better
words can be found. In addition,
> in the final RFC we will presumably no longer be able to refer to
Appendix A (that would be removed)
> and the words "earlier versions of this draft" will be inappropriate.

Good point. I will clean this up.

> Would it not be better to avoid implicit responses, i.e., have an
explicit response to the client-
> initiated request, and an explicit response to each
FloorRequestStatus?

I was thinking the same thing, and led me to add the editorial note. I
will take your input as a vote of explicit responses. One tradeoff will
be the weight the benefit vs. backward compatibility with
implementations based on previous versions of this draft.
 
> 4. There are several instances where the word "clause" is used to
refer to text in the existing RFC.
> It is not always clear what is meant, e.g., I think "sentence" is
sometimes the intention.

I will work on those.

Cheers,
Charles

> John
> 
> 
> 
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 15 Jul 2011 13:36:28 -0700

One more comment inline.

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Charles Eckel
> (eckelcu)
> Sent: Friday, July 15, 2011 12:25 PM
> To: Elwell, John; [email-masked]
> Subject: Re: [dispatch] Comments on
draft-sandbakken-dispatch-bfcp-udp-02
> implementations based on previous versions of this draft.

Note that the Transaction Initiator flag provides a mechanism to deal
with this. 

      I: The Transaction Initiator (I) flag-bit has relevance only for
      use of BFCP over unreliable transport.  When clear, it indicates
      that this message is a request initiating a new transaction, and
      the Transaction ID that follows has been generated for this
      transaction.  When set, it indicates that this message is a
      response to a previous request, and the Transaction ID that
      follows is the one associated with that request.  When BFCP is
      used over reliable transports, the flag has no significance and
      SHOULD be cleared.

Given the change in semantics introduced in the -02 version of the
draft, I think there is no longer any ambiguity whether a
FloorRequestStatusAck is required or not when receiving a
FloorRequestStatus.

Cheers,
Charles