The Session Description Protocol (SDP) WebSocket Connection URI Attribute
draft-ietf-bfcpbis-sdp-ws-uri-09
Yes
(Alissa Cooper)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 08 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(for -08)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(2017-01-18 for -08)
Unknown
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 IESG member
(was Discuss)
No Objection
No Objection
(2017-02-06)
Unknown
Thank you for addressing my DISCUSS. I cleared. Is S/MIME protection with SIP actually deployed?
Alia Atlas Former IESG member
No Objection
No Objection
(for -08)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -08)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -08)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -08)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -08)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2017-01-18 for -08)
Unknown
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 IESG member
No Objection
No Objection
(2017-01-15 for -08)
Unknown
- 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 IESG member
No Objection
No Objection
(2017-01-16 for -08)
Unknown
This document was very clear for me. Thank you for that.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -08)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -08)
Unknown