Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
RFC 4583
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(Allison Mankin; former steering group member) Yes
(Alex Zinin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
This document has a normative reference:
[9] Levin, O. and G. Camarillo, "The SDP (Session Description
Protocol) Label Attribute",
draft-levin-mmmusic-sdp-media-label-00 (work in progress),
July 2004.
and that document is an individual Internet-Draft, that also has expired.
So what impact does this have?
(Bill Fenner; former steering group member) (was Discuss) No Objection
(Brian Carpenter; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sam Hartman; former steering group member) (was Discuss) No Objection
I'm not sure I see a way that a server can offer both a TLS and non-TLS stream using this media type. If clients end up being required to support TLS tihs probably doesn't matter. However it may be an issue if clients are not required to support TLS. Perhaps I'm missing some information about how offer/answer works. It definitely seems that two m lines would be wrong because then a client could accept both of them.
(Scott Hollenbeck; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection