idnits 2.17.1 draft-camarillo-mmusic-sdp-bfcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 283. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2004) is 7133 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-08 == Outdated reference: A later version (-06) exists of draft-ietf-xcon-bfcp-01 -- Possible downref: Normative reference to a draft: ref. '6' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: April 15, 2005 October 15, 2004 5 Session Description Protocol (SDP) Format for Binary Floor Control 6 Protocol (BFCP) Streams 7 draft-camarillo-mmusic-sdp-bfcp-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 15, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This document specifies how to describe BFCP streams in a SDP session 43 description. User agents using the offer/answer model to establish 44 BFCP streams use this format in their offers and their answers. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Fields in the m Line . . . . . . . . . . . . . . . . . . . . . 3 51 4. The confid and userid SDP Parameters . . . . . . . . . . . . . 4 52 5. The k line . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 6. TCP Connection Management . . . . . . . . . . . . . . . . . . 4 54 7. Association between Streams and Floors . . . . . . . . . . . . 5 55 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 10.1 SDP Attributes Registration . . . . . . . . . . . . . . . 6 59 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 60 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 62 12.2 Informational References . . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 64 Intellectual Property and Copyright Statements . . . . . . . . 8 66 1. Introduction 68 As discussed in the BFCP specification [5], a given BFCP client needs 69 a set of data in order to establish a BFCP connection to a floor 70 control server. These data include the transport address of the 71 server, the conference identifier, and the user identifier. 73 Clients can obtain this information in different ways, one of them 74 consisting of using an offer/answer [3] exchange. This document 75 specifies how to encode this information in the SDP session 76 descriptions which are part of an offer/answer exchange. 78 User agents typically use the offer/answer model to establish a 79 number of media streams of different types. Following this model, a 80 BFCP connection is described as any other media stream by using an 81 SDP 'm' line, possibly followed by a number of attributes encoded in 82 'a' lines. 84 2. Terminology 86 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 87 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 88 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 89 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 90 compliant implementations. 92 3. Fields in the m Line 94 According to RFC 2327 [2], the 'm'line format is the following: 96 m= 98 The media field MUST have a value of "application". The port field 99 is not used by BFCP, and MAY be set to any value chosen by the 100 endpoint. A port field value of zero has the standard SDP meaning 101 (i.e., rejection of the media stream). 103 The port field is set following the rules in [4]. Depending on the 104 value of the setup attribute (disccused in Section 6), the port field 105 contains the port the remote endpoint will initiate its TCP 106 connection to, or is irrelevant (i.e., the endpoint will initiate the 107 connection towards the remote endpoint) and should be set to a value 108 of 9, which is the discard port. Since BFCP only runs on top of TCP, 109 the port is always a TCP port. 111 We define two new values for the transport field: TCP/BFCP and TCP/ 112 TLS/BFCP. 114 The fmt (format) list is ignored for BFCP. The fmt list of BFCP m 115 lines SHOULD contain a single "*" character. 117 The following is an example of an m line for a BFCP connection: 119 m=application 20000 TCP/BFCP * 121 4. The confid and userid SDP Parameters 123 We define the confid and the userid SDP media-level attributes. 124 Their syntax is: 126 confid-attribute = "a=confid: " conference-id 127 conference-id = token 129 userid-attribute = "a=userid: " user-id 130 user-id = token 132 The confid and the userid attributes carry the integer representation 133 of a conference ID and a user ID respectively. 135 Endpoints which use the offer/answer model to establish BFCP 136 connections MUST support the confid and the userid attributes. A 137 floor control server acting as an offerer or as an answerers SHOULD 138 include these attributes in its session descriptions. 140 5. The k line 142 If the offer/answer exchange is encrypted and integrity protected, 143 the offerer MAY use an SDP 'k' line to provide the answerer with a 144 shared secret to be used to calculate the value of the DIGEST TLVs. 145 The following is an example of a 'k' line: 147 k=base64:c2hhcmVkLXNlY3JldA== 149 6. TCP Connection Management 151 The management of the TCP connection used to transport BFCP is 152 performed using the setup and 'connection' attributes as defined in 153 [4]. 155 The setup attribute indicates which of the endpoints (client or floor 156 control server) initiates the TCP connection. The 'connection' 157 attribute handles TCP connection reestablishment. 159 Editor's note: need to address loss and re-establishment of TCP 160 connections. 162 7. Association between Streams and Floors 164 We define the floorid SDP media-level attribute. Its syntax is: 166 floor-id-attribute = "a=floorid:" token " mstream:" 1*(token) 168 The floorid attribute is used in BFCP m lines and associates a floor 169 ID with a media stream. The token representing the floor ID is the 170 integer representation of the 16-bit floorid to be used in BFCP. The 171 token representing the media stream is a pointer to the media stream, 172 which is identified by an SDP label attribute [6] 174 Endpoints which use the offer/answer model to establish BFCP 175 connections MUST support the floorid and the label attributes. A 176 floor control server acting as an offerer or as an answerers SHOULD 177 include these attributes in its session descriptions. 179 8. Example 181 The following is an example of an offer sent by a conference server 182 to a user. For the purpose of brevity, the main portion of the 183 session description is omitted in the examples, which only show m= 184 lines and their attributes. 186 m=application 20000 TCP/BFCP * 187 k=base64:c2hhcmVkLXNlY3JldA== 188 a=setup:passive 189 a=connection:new 190 a=confid:4321 191 a=userid:1234 192 a=floorid:1 m-stream:10 193 a=floorid:2 m-stream:11 194 m=audio 20000 RTP/AVP 0 195 a=label:10 196 m=video 30000 RTP/AVP 31 197 a=label:11 199 The following is the answer returned by the user. 201 m=application 9 TCP/BFCP * 202 a=setup:active 203 a=connection:new 204 m=audio 25000 RTP/AVP 0 205 m=video 35000 RTP/AVP 31 207 9. Security Considerations 209 TBD. 211 10. IANA Considerations 213 TBD. 215 10.1 SDP Attributes Registration 217 TBD: 219 11. Acknowledgments 221 Joerg Ott, Keith Drage, and Alan Johnston provided useful ideas for 222 this document. 224 12. References 226 12.1 Normative References 228 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 229 Levels", BCP 14, RFC 2119, March 1997. 231 [2] Handley, M. and V. Jacobson, "SDP: Session Description 232 Protocol", RFC 2327, April 1998. 234 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 235 Session Description Protocol (SDP)", RFC 3264, June 2002. 237 [4] Yon, D., "Connection-Oriented Media Transport in the Session 238 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-08 239 (work in progress), July 2004. 241 [5] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 242 draft-ietf-xcon-bfcp-01 (work in progress), August 2004. 244 [6] Levin, O. and G. Camarillo, "The SDP (Session Description 245 Protocol) Label Attribute", 246 draft-levin-mmmusic-sdp-media-label-00 (work in progress), July 247 2004. 249 12.2 Informational References 251 Author's Address 253 Gonzalo Camarillo 254 Ericsson 255 Hirsalantie 11 256 Jorvas 02420 257 Finland 259 EMail: Gonzalo.Camarillo@ericsson.com 261 Intellectual Property Statement 263 The IETF takes no position regarding the validity or scope of any 264 Intellectual Property Rights or other rights that might be claimed to 265 pertain to the implementation or use of the technology described in 266 this document or the extent to which any license under such rights 267 might or might not be available; nor does it represent that it has 268 made any independent effort to identify any such rights. Information 269 on the procedures with respect to rights in RFC documents can be 270 found in BCP 78 and BCP 79. 272 Copies of IPR disclosures made to the IETF Secretariat and any 273 assurances of licenses to be made available, or the result of an 274 attempt made to obtain a general license or permission for the use of 275 such proprietary rights by implementers or users of this 276 specification can be obtained from the IETF on-line IPR repository at 277 http://www.ietf.org/ipr. 279 The IETF invites any interested party to bring to its attention any 280 copyrights, patents or patent applications, or other proprietary 281 rights that may cover technology that may be required to implement 282 this standard. Please address the information to the IETF at 283 ietf-ipr@ietf.org. 285 Disclaimer of Validity 287 This document and the information contained herein are provided on an 288 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 289 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 290 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 291 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 292 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 293 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 295 Copyright Statement 297 Copyright (C) The Internet Society (2004). This document is subject 298 to the rights, licenses and restrictions contained in BCP 78, and 299 except as set forth therein, the authors retain all their rights. 301 Acknowledgment 303 Funding for the RFC Editor function is currently provided by the 304 Internet Society.