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
