The Session Description Protocol (SDP) WebSocket Connection URI Attribute
draft-ietf-bfcpbis-sdp-ws-uri-09

Note: This ballot was opened for revision 08 and is now closed.

Alvaro Retana No Objection

(Alissa Cooper; former steering group member) Yes

Yes ( for -08)
No email
send info

(Ben Campbell; former steering group member) Yes

Yes (2017-01-18 for -08)
No email
send info
How does this interact with websocket sub-protocol specifications? Is there an expectation one might take some existing media protocol and use it with this draft _without_ a sub-protocol spec? I note the examples use bfcp, which in fact has a sub-protocol spec on this same telechat. (Most of my detailed comments are related to this)

- 4.2, first paragraph: Am I correct that the "proto" field would also include the sub-protocol? (e.g. TCP/WSS/BFCP)? Would you ever have a "proto" filed value of just "TCP/WS(S)?

- 4.2, 2nd paragraph
I wonder if the guidance here (the recommendation that the offerer is the active party) doesn't vary by sub-protocol? Or if it doesn't, if it's more a matter of topology (e.g. servers with global IP addresses vs clients behind NATs) than a matter of who sends the offer?
Also, please consider citing 4145 in this paragraph. (You do in 4.3).

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

No Objection (2017-02-06)
No email
send info
Thank you for addressing my DISCUSS. I cleared.

Is S/MIME protection with SIP actually deployed?

(Alia Atlas; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2017-01-18 for -08)
No email
send info
I may have missed it, but don't see a clear reason (would expect to see it in the security considerations section) as to why TLS isn't a MUST.  RECOMMENDED is good, but having a reason to justify this would be helpful.  It seems like it is for legacy support of HTTP applications, but spelling that out might be helpful.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2017-01-15 for -08)
No email
send info
- sec 4.2. The MUST here is inappropriate (given the split of docs):
„For example, to negotiate BFCP-over-WebSocket the "proto" value in the
   "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST
   be TCP/WS/BFCP.“
Should be instead:
„For example, to negotiate BFCP-over-WebSocket the "proto" value in the
   "m=" line is TCP/WSS/BFCP if WebSocket is over TLS, else it is
   TCP/WS/BFCP., as specified in [I-D.ietf-bfcpbis-bfcp-websocket]“
- Also remove the following sentence in section 4.3:

„For BFCP application, the "proto" value in the "m=" line
   MUST be TCP/WSS/BFCP if WebSocket is run on TLS, else it MUST be
   TCP/WS/BFCP.“
- In section 6: „a=ws/a=wss-uri“. Maybe use „a=ws-uri/a=wss-uri“ instead?

(Spencer Dawkins; former steering group member) No Objection

No Objection (2017-01-16 for -08)
No email
send info
This document was very clear for me. Thank you for that.

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -08)
No email
send info

(Terry Manderson; former steering group member) No Objection

No Objection ( for -08)
No email
send info