idnits 2.17.1 draft-ietf-mmusic-sdp-bfcp-01.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 635. ** 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. 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 (May 4, 2005) is 6931 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 1750 (ref. '1') (Obsoleted by RFC 4086) ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3548 (ref. '6') (Obsoleted by RFC 4648) == Outdated reference: A later version (-06) exists of draft-ietf-xcon-bfcp-03 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-comedia-tls-02 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-24 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-sdescriptions-09 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: November 5, 2005 May 4, 2005 6 Session Description Protocol (SDP) Format for Binary Floor Control 7 Protocol (BFCP) Streams 8 draft-ietf-mmusic-sdp-bfcp-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 5, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document specifies how to describe BFCP streams in SDP session 42 descriptions. User agents using the offer/answer model to establish 43 BFCP streams use this format in their offers and their answers. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Fields in the m Line . . . . . . . . . . . . . . . . . . . . . 3 50 4. Floor Control Server Determination . . . . . . . . . . . . . . 4 51 5. The 'confid' and 'userid' SDP Attributes . . . . . . . . . . . 4 52 6. Association between Streams and Floors . . . . . . . . . . . . 5 53 7. TCP Connection Management . . . . . . . . . . . . . . . . . . 5 54 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 6 55 8.1 Mutual Authentication Using Certificates and TLS . . . . . 6 56 8.2 Client Authentication at the BFCP Level . . . . . . . . . 7 57 8.2.1 Generating a Shared Secret . . . . . . . . . . . . . . 7 58 8.2.2 The 'nonce' Attribute . . . . . . . . . . . . . . . . 8 59 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 9.1 Example Using TLS . . . . . . . . . . . . . . . . . . . . 8 61 9.2 Example Using the 'crypto' Attribute . . . . . . . . . . . 9 62 10. Security Considerations . . . . . . . . . . . . . . . . . . 10 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 64 11.1 Registration of the 'TCP/BFCP' and 'TCP/TLS/BFCP' SDP 65 'proto' values . . . . . . . . . . . . . . . . . . . . . . 11 66 11.2 Registration of the SDP 'confid' Attribute . . . . . . . . 11 67 11.3 Registration of the SDP 'userid' Attribute . . . . . . . . 11 68 11.4 Registration of the SDP 'floorid' Attribute . . . . . . . 12 69 11.5 Registration of the SDP 'nonce' Attribute . . . . . . . . 12 70 11.6 Registration of the crypto-suites for 'TCP/BFCP' . . . . . 13 71 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 72 13. Normative References . . . . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 74 Intellectual Property and Copyright Statements . . . . . . . . 15 76 1. Introduction 78 As discussed in the BFCP (Binary Floor Control Protocol) 79 specification [8], a given BFCP client needs a set of data in order 80 to establish a BFCP connection to a floor control server. These data 81 include the transport address of the server, the conference 82 identifier, and the user identifier. 84 One way for clients to obtain this information consists of using an 85 offer/answer [5] exchange. This document specifies how to encode 86 this information in the SDP session descriptions which are part of an 87 offer/answer exchange. 89 User agents typically use the offer/answer model to establish a 90 number of media streams of different types. Following this model, a 91 BFCP connection is described as any other media stream by using an 92 SDP 'm' line, possibly followed by a number of attributes encoded in 93 'a' lines. 95 2. Terminology 97 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 98 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 99 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 100 described in BCP 14, RFC 2119 [2] and indicate requirement levels for 101 compliant implementations. 103 3. Fields in the m Line 105 According to the SDP specification [11], the 'm'line format is the 106 following: 108 m= ... 110 The media field MUST have a value of "application". 112 The port field is set following the rules in [7]. Depending on the 113 value of the 'setup' attribute (disccused in Section 7), the port 114 field contains the port the remote endpoint will initiate its TCP 115 connection to, or is irrelevant (i.e., the endpoint will initiate the 116 connection towards the remote endpoint) and should be set to a value 117 of 9, which is the discard port. Since BFCP only runs on top of TCP, 118 the port is always a TCP port. A port field value of zero has the 119 standard SDP meaning (i.e., rejection of the media stream). 121 We define two new values for the transport field: TCP/BFCP and TCP/ 122 TLS/BFCP. The former is used when BFCP runs directly on top of TCP 123 and the latter is used when BFCP runs on top of TLS, which in turn 124 runs on top of TCP. 126 The fmt (format) list is ignored for BFCP. The fmt list of BFCP m 127 lines SHOULD contain a single "*" character. 129 The following is an example of an m line for a BFCP connection: 131 m=application 20000 TCP/TLS/BFCP * 133 4. Floor Control Server Determination 135 The 'confid' and the 'userid' attributes are used by a floor control 136 server to provide a client with a conference ID and a user ID. In 137 the context of an offer/answer exchange, the entity including these 138 attributes is the floor control server. 140 The most common scenario consists of a client establishing a BFCP 141 stream with a floor control server. In this case, there is only one 142 floor control server (the offerer or the answerer). However, there 143 are scenarios where both the offerer and the answerer are both 144 clients and floor control servers. For example, in a two-party 145 session that involves an audio stream and a shared whiteboard, one 146 party acts as the floor control server for the audio stream and the 147 other acts as the floor control server for the shared whiteboard. In 148 such a case, both the offerer and the answerer would include the 149 'confid' and the 'userid' attributes in their respective session 150 descriptions. 152 5. The 'confid' and 'userid' SDP Attributes 154 We define the 'confid' and the 'userid' SDP media-level attributes. 155 These attributes attributes are used by a floor control server to 156 provide a client with a conference ID and a user ID respectively. 157 Their Augmented BNF syntax [3] is: 159 confid-attribute = "a=confid: " conference-id 160 conference-id = token 162 userid-attribute = "a=userid: " user-id 163 user-id = token 165 The confid and the userid attributes carry the integer representation 166 of a conference ID and a user ID respectively. 168 Endpoints which use the offer/answer model to establish BFCP 169 connections MUST support the confid and the userid attributes. A 170 floor control server acting as an offerer or as an answerers SHOULD 171 include these attributes in its session descriptions. 173 6. Association between Streams and Floors 175 We define the floorid SDP media-level attribute. Its Augmented BNF 176 syntax [3] is: 178 floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)] 180 The floorid attribute is used in BFCP 'm' lines. It defines a floor 181 identifier and, possibly, associates it with one or more media 182 streams. The token representing the floor ID is the integer 183 representation of the Floor ID to be used in BFCP. The token 184 representing the media stream is a pointer to the media stream, which 185 is identified by an SDP label attribute [9] 187 Endpoints which use the offer/answer model to establish BFCP 188 connections MUST support the 'floorid' and the 'label' attributes. A 189 floor control server acting as an offerer or as an answerer SHOULD 190 include these attributes in its session descriptions. 192 7. TCP Connection Management 194 The management of the TCP connection used to transport BFCP is 195 performed using the 'setup' and 'connection' attributes as defined in 196 [7]. 198 The setup attribute indicates which of the endpoints (client or floor 199 control server) initiates the TCP connection. The 'connection' 200 attribute handles TCP connection reestablishment. 202 The BFCP specification [8] describes a number of situations when the 203 TCP connection between a client and the floor control server needs to 204 be reestablished. However, that specification does not describe the 205 reestablishment process because this process depends on how the 206 connection was established in the first place. BFCP entities using 207 the offer/answer model follow the following rules. 209 When the existing TCP connection is reseted following the rules in 210 [8], the client SHOULD generate an offer towards the floor control 211 server in order to reestablish the connection. If a TCP connection 212 cannot deliver a BFCP message and times out, the entity that 213 attempted to send the message (i.e., the one that detected the TCP 214 timeout) SHOULD generate an offer in order to reestablish the TCP 215 connection. 217 Endpoints which use the offer/answer model to establish BFCP 218 connections MUST support the 'setup' and the 'connection' attributes. 220 8. Authentication 222 When a BFCP connection is established using the offer/answer model, 223 it is assumed that the offerer and the answerer authenticate each 224 other using some mechanism. Once this mutual authentication takes 225 place, all the offerer and the answerer need to make sure is that the 226 entity they are receiving BFCP messages from is the same as the one 227 that generated the previous offer or answer. 229 When SIP is used to perform an offer/answer exchange, the initial 230 mutual authentication takes place at the SIP level. Additionally, 231 SIP uses S/MIME to provide an integrity protected channel with 232 optional confidentiality for the offer/answer exchange. BFCP takes 233 advantage of this integrity protected offer/answer exchange to 234 perform authentication. Within the offer/answer exchange, the 235 offerer and the answerer exchange the fingerprints of their self- 236 signed certificates. These self-signed certificates are then used to 237 establish the TLS connection that will carry BFCP traffic between the 238 offerer and the answerer. Of course, certificates signed by a 239 certificate authority known to both parties can also be used. 240 Section 8.1 describes mutual authentication using certificates and 241 TLS, which is the RECOMMENDED mechanism to perform mutual 242 authentication. 244 BFCP also provides a digest mechanism based on a shared secret to 245 provide client authentication in situations where TLS is not used for 246 some reason. Section 8.2 describes how to set up this mechanism 247 using an offer/answer model. Note that when mutual authentication is 248 performed using TLS, it is not necessary to use this digest 249 mechanism. 251 8.1 Mutual Authentication Using Certificates and TLS 253 BFCP clients and floor control servers follow the rules in [10] 254 regarding certificate choice and presentation. This implies that 255 unless a 'fingerprint' attribute is included in the session 256 description, the certificate provided at the TLS-level must be signed 257 by a certificate authority known to other party. Endpoints which use 258 the offer/answer model to establish BFCP connections MUST support the 259 'fingerprint' attribute and SHOULD include it in their session 260 descriptions. 262 When TLS is used, once the underlaying TCP connection is established, 263 the answerer acts as the TLS server regardless of its role (passive 264 or active) in the TCP establishment procedure. 266 8.2 Client Authentication at the BFCP Level 268 Digest authentication in BFCP is based on a shared secret between the 269 client and the floor control server. Section 8.2.1 describes how to 270 set up such a secret using an encrypted offer/answer exchange. 271 Section 8.2.2 describes how a floor control server can provide a 272 client with an initial nonce. 274 8.2.1 Generating a Shared Secret 276 This section describes how to generate a shared secret between a 277 client and a floor control server using SDP security descriptions and 278 the SDP 'crypto' attribute [12]. 280 The following is the format of the 'crypto' attribute as defined in 281 [12]: 283 a=crypto: [] 285 The use of the tag field is specified in [12]. 287 The possible values for the crypto-suite field are defined within the 288 context of a transport; TCP/BFCP in our case. Within the context of 289 TCP/BFCP, we define the following value for the crypto-suite field: 291 +-----------+-----------------+ 292 | Value | BFCP Identifier | 293 +-----------+-----------------+ 294 | HMAC-SHA1 | 0 | 295 +-----------+-----------------+ 297 Table 1: Values for the crypto-suite field in TCP/BFCP 299 The IANA registry for Digest Algorithms in BFCP contains references 300 to the specifications that describe the usage of each digest 301 algorithm (identified by its BFCP identifier) in BFCP. 303 The key-params field SHOULD use the 'inline' key method followed by a 304 base64-encoded [6] unguessable secret [1]. 306 The use of the optional session-params field is for further study. 308 The following is an example of a 'crypto' attribute: 310 a=crypto:1 HMAC-SHA1 inline:c2hhcmVkLXNlY3JldA== 312 The use of the 'crypto' attribute in an offer/answer exchange is 313 described in [12]. Additionally, when this attribute is used with 314 BFCP streams, the answerer MUST use the same value in the key-params 315 field as the one received in the offer. 317 Endpoints MAY use other mechanisms (including out-of-band mechanisms) 318 to generate a shared secret. However, if the mechanism described in 319 this section is used, the session descriptions MUST be encrypted. 321 8.2.2 The 'nonce' Attribute 323 We define the SDP media-level 'nonce' attribute. Its Augmented BNF 324 syntax [3] is: 326 nonce-attribute = "a=nonce: " nonce-value 327 nonce-value = token 329 The 'nonce' attribute carries the integer representation of the nonce 330 to be used by the client in its next BFCP message (typically the 331 first message from the client) towards the floor control server. 332 This is an optimization so that the client does not need to generate 333 an initial BFCP message only to have it rejected by the floor control 334 server with an Error response containing a nonce. 336 Endpoints which use the offer/answer model to establish BFCP 337 connections SHOULD support the 'nonce' attribute. A floor control 338 server acting as an offerer or as an answerers MAY include this 339 attribute in its session descriptions. 341 9. Examples 343 For the purpose of brevity, the main portion of the session 344 description is omitted in the examples, which only show 'm' lines and 345 their attributes. 347 9.1 Example Using TLS 349 The following is an example of an offer sent by a conference server 350 to a client. 352 m=application 20000 TCP/TLS/BFCP * 353 a=setup:passive 354 a=connection:new 355 a=fingerprint:SHA-1 \ 356 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 357 a=confid:4321 358 a=userid:1234 359 a=floorid:1 m-stream:10 360 a=floorid:2 m-stream:11 361 m=audio 20000 RTP/AVP 0 362 a=label:10 363 m=video 30000 RTP/AVP 31 364 a=label:11 366 Note that due to RFC formatting conventions, this document splits SDP 367 across lines whose content would exceed 72 characters. A backslash 368 character marks where this line folding has taken place. This 369 backslash and its trailing CRLF and whitespace would not appear in 370 actual SDP content. 372 The following is the answer returned by the user. 374 m=application 9 TCP/TLS/BFCP * 375 a=setup:active 376 a=connection:new 377 m=audio 25000 RTP/AVP 0 378 m=video 35000 RTP/AVP 31 380 9.2 Example Using the 'crypto' Attribute 382 The following is an example of an offer sent by a conference server 383 to a client. In this case, TLS is not used to perform mutual 384 authentication. The 'crypto' attribute is used to generate a shared 385 secret between the client and the floor control server. 387 m=application 20000 TCP/BFCP * 388 a=setup:passive 389 a=connection:new 390 a=crypto:1 HMAC-SHA1 inline:c2hhcmVkLXNlY3JldA== 391 a=nonce:5736 392 a=confid:4321 393 a=userid:1234 394 a=floorid:1 m-stream:10 395 a=floorid:2 m-stream:11 396 m=audio 20000 RTP/AVP 0 397 a=label:10 398 m=video 30000 RTP/AVP 31 399 a=label:11 401 The following is the answer returned by the participant. 403 m=application 9 TCP/BFCP * 404 a=setup:active 405 a=connection:new 406 a=crypto:1 HMAC-SHA1 inline:c2hhcmVkLXNlY3JldA== 407 m=audio 25000 RTP/AVP 0 408 m=video 35000 RTP/AVP 31 410 10. Security Considerations 412 The BFCP [8], SDP [11], and the offer/answer [5] specifications 413 discuss security issues related to BFCP, SDP, and the offer/answer 414 respectively. In addition, [7] and [10] discuss security issues 415 related to the establishment of TCP and TLS connections using an 416 offer/answer model. 418 An issue which is discussed in the previous specifications and is of 419 particular importance for this specification relates to the usage of 420 the SDP 'crypto' attribute to generate shared secrets. When the 421 'crypto' attribute is used, the session description carrying it must 422 be encrypted, as specified in Section 8.2.1. Otherwise, an attacker 423 could get access to the shared secret and impersonate the client. 424 For session descriptions carried in SIP [4], S/MIME is the natural 425 choice to provide such end-to-end encryption. Other applications MAY 426 use different encryption mechanisms. 428 11. IANA Considerations 430 The following sections instruct the IANA to perform a set of actions. 432 11.1 Registration of the 'TCP/BFCP' and 'TCP/TLS/BFCP' SDP 'proto' 433 values 435 This section instructs the IANA to register the following two new 436 values for the SDP 'proto' field under the Session Description 437 Protocol (SDP) Parameters registry: 439 +--------------+-----------+ 440 | Value | Reference | 441 +--------------+-----------+ 442 | TCP/BFCP | RFCxxxx | 443 | TCP/TLS/BFCP | RFCxxxx | 444 +--------------+-----------+ 446 Table 2: Values for the SDP 'proto' field 448 [Note to the RFC editor: please, replace RFCxxxx with the RFC number 449 that this document will be assigned.] 451 11.2 Registration of the SDP 'confid' Attribute 453 This section instructs the IANA to register the following SDP att- 454 field under the Session Description Protocol (SDP) Parameters 455 registry: 457 Contact name: Gonzalo.Camarillo@ericsson.com 459 Attribute name: confid 461 Type of attribute Media level 463 Subject to charset: No 465 Purpose of attribute: The 'confid' attribute carries the integer 466 representation of a Conference ID. 468 Allowed attribute values: A token 470 11.3 Registration of the SDP 'userid' Attribute 472 This section instructs the IANA to register the following SDP att- 473 field under the Session Description Protocol (SDP) Parameters 474 registry: 476 Contact name: Gonzalo.Camarillo@ericsson.com 478 Attribute name: userid 480 Type of attribute Media level 482 Subject to charset: No 484 Purpose of attribute: The 'userid' attribute carries the integer 485 representation of a User ID. 487 Allowed attribute values: A token 489 11.4 Registration of the SDP 'floorid' Attribute 491 This section instructs the IANA to register the following SDP att- 492 field under the Session Description Protocol (SDP) Parameters 493 registry: 495 Contact name: Gonzalo.Camarillo@ericsson.com 497 Attribute name: floorid 499 Type of attribute Media level 501 Subject to charset: No 503 Purpose of attribute: The 'floorid' attribute associates a floor 504 with one or more media streams. 506 Allowed attribute values: Tokens 508 11.5 Registration of the SDP 'nonce' Attribute 510 This section instructs the IANA to register the following SDP att- 511 field under the Session Description Protocol (SDP) Parameters 512 registry: 514 Contact name: Gonzalo.Camarillo@ericsson.com 516 Attribute name: nonce 518 Type of attribute Media level 519 Subject to charset: No 521 Purpose of attribute: The 'nonce' attribute carried a nonce to be 522 used in the media stream (e.g., in the BFCP connection). 524 Allowed attribute values: A token 526 11.6 Registration of the crypto-suites for 'TCP/BFCP' 528 This section instructs the IANA to register the 'TCP/BFCP' media 529 transport under the SDP Security Description registry. The key 530 methods supported is "inline". The reference for the SDP security 531 description for 'TCP/BFCP' is this document. 533 The following crypto-suite needs to be registered under the 'TCP/ 534 BFCP' transport: 536 +-----------+-----------------+ 537 | Value | BFCP Identifier | 538 +-----------+-----------------+ 539 | HMAC-SHA1 | 0 | 540 +-----------+-----------------+ 542 Table 3: Values for the crypto-suite field in TCP/BFCP 544 The IANA registry for Digest Algorithms in BFCP contains references 545 to the specifications that describe the usage of each digest 546 algorithm (identified by its BFCP identifier) in BFCP. 548 At this point, there are no session parameters defined for the 'TCP/ 549 BFCP' media transport. Consequently, the IANA does not need to 550 create a session parameter subregistry under 'TCP/BFCP'. 552 12. Acknowledgments 554 Joerg Ott, Keith Drage, Alan Johnston, and Eric Rescorla provided 555 useful ideas for this document. 557 13. Normative References 559 [1] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 560 Recommendations for Security", RFC 1750, December 1994. 562 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 563 Levels", BCP 14, RFC 2119, March 1997. 565 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 566 Specifications: ABNF", RFC 2234, November 1997. 568 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 569 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 570 Session Initiation Protocol", RFC 3261, June 2002. 572 [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 573 Session Description Protocol (SDP)", RFC 3264, June 2002. 575 [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 576 RFC 3548, July 2003. 578 [7] Yon, D., "Connection-Oriented Media Transport in the Session 579 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10 580 (work in progress), November 2004. 582 [8] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 583 draft-ietf-xcon-bfcp-03 (work in progress), January 2005. 585 [9] Levin, O. and G. Camarillo, "The SDP (Session Description 586 Protocol) Label Attribute", 587 draft-levin-mmmusic-sdp-media-label-00 (work in progress), 588 July 2004. 590 [10] Lennox, J., "Connection-Oriented Media Transport over the 591 Transport Layer Security (TLS) Protocol in the Session 592 Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-02 593 (work in progress), October 2004. 595 [11] Handley, M., "SDP: Session Description Protocol", 596 draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005. 598 [12] Andreasen, F., Baugher, M., and D. Wing, "Session Description 599 Protocol Security Descriptions for Media Streams", 600 draft-ietf-mmusic-sdescriptions-09 (work in progress), 601 February 2005. 603 Author's Address 605 Gonzalo Camarillo 606 Ericsson 607 Hirsalantie 11 608 Jorvas 02420 609 Finland 611 Email: Gonzalo.Camarillo@ericsson.com 613 Intellectual Property Statement 615 The IETF takes no position regarding the validity or scope of any 616 Intellectual Property Rights or other rights that might be claimed to 617 pertain to the implementation or use of the technology described in 618 this document or the extent to which any license under such rights 619 might or might not be available; nor does it represent that it has 620 made any independent effort to identify any such rights. Information 621 on the procedures with respect to rights in RFC documents can be 622 found in BCP 78 and BCP 79. 624 Copies of IPR disclosures made to the IETF Secretariat and any 625 assurances of licenses to be made available, or the result of an 626 attempt made to obtain a general license or permission for the use of 627 such proprietary rights by implementers or users of this 628 specification can be obtained from the IETF on-line IPR repository at 629 http://www.ietf.org/ipr. 631 The IETF invites any interested party to bring to its attention any 632 copyrights, patents or patent applications, or other proprietary 633 rights that may cover technology that may be required to implement 634 this standard. Please address the information to the IETF at 635 ietf-ipr@ietf.org. 637 Disclaimer of Validity 639 This document and the information contained herein are provided on an 640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 642 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 643 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 644 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Copyright Statement 649 Copyright (C) The Internet Society (2005). This document is subject 650 to the rights, licenses and restrictions contained in BCP 78, and 651 except as set forth therein, the authors retain all their rights. 653 Acknowledgment 655 Funding for the RFC Editor function is currently provided by the 656 Internet Society.