Hi Paul, Your proposed changes completely resolve my concerns on -13. Thanks for taking care of this.
Cheers Suresh On 09/22/2015 04:50 PM, Paul E. Jones wrote: > Folks, > Alissa asked me to review the current text, provide input, and help > address some of the current DISCUSS points. > Here are some suggested improvements: > Editorial: > > * In Section 4.1, it says "Subsequent FloorStatus messages consist of > server-initiated transactions, and therefore their Transaction ID is > 0." This is true since the transport in these examples is > reliable. While perhaps minor, I think it might be worth explicitly > stating that be appending "given the example uses a reliable > transport", otherwise the reader may miss that there is a difference > in behavior when communicating over unreliable transports. > * In 5.3.7, it says "the following is the format of the FloorRequest > message". That should be "FloorQuery message" > * In 6.2.3, the equation: > (message size - COMMON-HEADER size / MTU size - COMMON-HEADER size) > for better readability should say: > ((message size - COMMON-HEADER size) / (MTU size - COMMON-HEADER > size)) > * In 10.2.2, it reads "A message from the floor control server is > considered a response to the *FloorRelease *message if the message > from the floor control server has the same Conference ID, > Transaction ID, and User ID as the *FloorRequest* message." I > believe "FloorRequest" should be "FloorRelease". > * A similar copy/paste error as above was noted in 12.1.2. > * I think it would be beneficial in Appendix A to explicitly show what > the "R" value is. It is possible for a floor participant and a > floor control server to each initiate a transaction at the same time > with Transaction ID == 124, for example. The "R" bit is what helps > to differentiate transactions and their responses, and I think that > would be helpful here. > > Technical: > > * Section 10.1.1 says the "User ID will be used by the floor control > server to authenticate and authorize the request." TLS/DTLS is used > for authentication/authorization presently. Further, the draft more > than once that other mechanisms might be developed in the > future. Merely looking at this field in a message, though, is not > sufficient to authenticate or authorize a request. This existed in > the original RFC, but I propose we strike the sentence. > > Paul _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
