idnits 2.17.1 draft-ietf-mmusic-sdp-media-label-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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 279. ** 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (January 2004) is 7397 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 2234 (ref. '2') (Obsoleted by RFC 4234) == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-21 -- Obsolete informational reference (is this intentional?): RFC 3388 (ref. '6') (Obsoleted by RFC 5888) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC O. Levin 3 Internet-Draft Microsoft Corporation 4 Expires: July 1, 2004 G. Camarillo 5 Ericsson 6 January 2004 8 The SDP (Session Description Protocol) Label Attribute 9 draft-ietf-mmusic-sdp-media-label-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 1, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This document defines a new Session Description Protocol (SDP) 45 media-level attribute: "label". The "label" attribute carries a 46 pointer to a media stream in the context of an arbitrary network 47 application that uses SDP. The sender of the SDP document can attach 48 the "label" attribute to a particular media stream or streams. The 49 application can then use the provided pointer to refer to each 50 particular media stream in its context. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Motivation for the New label Attribute . . . . . . . . . . . . 3 57 4. The Label Attribute . . . . . . . . . . . . . . . . . . . . . 4 58 5. The Label Attribute in the Offer/Answer Model . . . . . . . . 4 59 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 65 10.2 Informative References . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 67 Intellectual Property and Copyright Statements . . . . . . . . 7 69 1. Introduction 71 SDP is being used by a variety of distributed over the network 72 applications. These applications deal with multiple sessions being 73 described by SDP [4] and serving multiple users or services in the 74 context of a single application instance. Applications of this kind 75 need a means to identify a particular media stream across multiple 76 SDP descriptions exchanged with different users. 78 The XCON framework is an example of a centralized conference 79 architecture that uses SDP according to the offer/answer mechanism 80 defined in [3] to establish media streams with each of the conference 81 participants. Additionally, XCON identifies the need to uniquely 82 identify a media stream in terms of its role in a conference 83 regardless of its media type, transport protocol, and media format. 84 This can be acomplished by using an external document that points to 85 the appropriate media stream and provides information (e.g., the 86 media stream's role in the conference) about it. 88 This specification defines the SDP [4] "label" media-level attribute, 89 which provides a pointer to a media stream which is described by an 90 'm' line in an SDP session description. 92 2. Terminology 94 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 95 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 96 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 97 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 98 compliant implementations. 100 3. Motivation for the New label Attribute 102 Even though SDP and its extensions already provide a few ways to 103 refer to a media stream, none of them is appropriate to be used in 104 the context of external documents that may be created before the 105 session description itself and need to be handled by automata. 107 The 'i' SDP attribute, defined in RFC 2327 [4], can be used to label 108 media streams. Nevertheless, values of the 'i' attribute are 109 intended for human users and not for automata. 111 The 'mid' SDP attribute, defined in RFC 3388 [6], can be used to 112 identify media streams as well. Nevertheless, the scope of 'mid' is 113 too limited to be used by applications dealing with multiple SDP 114 sessions. This is due to the fact that values of the 'mid' attribute 115 are meaningful in the context of a single SDP session, not in the 116 context of a broader application (e.g., a multiparty application). 118 Another way of referring to a media stream is by using the order of 119 the 'm' line in the SDP session document (e.g., the 5th media stream 120 in the session description). This is the mechanism used in the 121 offer/answer model [3]. 123 The problem with this mechanism is that it can only be used to refer 124 to media streams in session descriptions that exist already. There 125 are scenarios where a static document needs to refer, using a 126 pointer, to a media stream that will be negotiated by SDP means and 127 created in the future. When the media stream is eventually created, 128 the application needs to label the media stream so that the pointer 129 in the static document points to the proper media stream in the 130 session description. 132 4. The Label Attribute 134 This specification defines a new media-level value attribute: 135 'label'. Its formatting in SDP is described by the following BNF 136 [2]: 138 label-attribute = "a=label:" pointer 139 pointer = token 141 The 'label' attribute contains a token which is defined by an 142 application and is used in its context. The new attribute can be 143 attached to 'm' lines in multiple SDP documents allowing the 144 application to logically group the media streams across SDP sessions 145 when necessary. 147 5. The Label Attribute in the Offer/Answer Model 149 This specification does not define a means to discover whether or not 150 the peer endpoint understands the 'label' attribute because 'label' 151 values are informative only at the offer/answer model level. 153 At the offer/answer level, it means that the fact that an offer does 154 not contain label attributes does not imply that the answer should 155 not have them. It also means that the fact that an offer contains 156 label attributes does not imply that the answer should have them too. 158 In addition to the basic offer/answer rule above, applications that 159 use 'label' as a pointer to media streams MUST specify its usage 160 constraints. For example, such applications MAY mandate support for 161 'label'. In this case, the application will define means for 162 negotiation of the 'label' attribute support as a part of its 163 specification. 165 6. Example 167 The following is an example of an SDP session description that uses 168 the 'label' attribute: 170 v=0 171 o=bob 280744730 28977631 IN IP4 host.example.com 172 s= 173 c=IN IP4 192.0.2.2 174 t=0 0 175 m=audio 6886 RTP/AVP 0 176 a=label:1 177 m=audio 22334 RTP/AVP 0 178 a=label:2 180 7. Security Considerations 182 An attacker may attempt to add, modify, or remove 'label' attributes 183 from a session description. This could result in an application 184 behaving in a non-desirable way. So, it is strongly RECOMMENDED that 185 integrity protection be applied to the SDP session descriptions. For 186 session descriptions carried in SIP [5], S/MIME is the natural choice 187 to provide such end-to-end integrity protection, as described in RFC 188 3261 [5]. Other applications MAY use a different form of integrity 189 protection. 191 8. IANA Considerations 193 Contact name: Orit Levin oritl@microsoft.com. 195 Attribute name: "label". 197 Type of attribute Media level. 199 Subject to charset: Not. 201 Purpose of attribute: The 'label' attribute associates a media 202 stream with a label. This label allows the media stream to be 203 referenced by external documents. 205 Allowed attribute values: A token. 207 9. Acknowledgements 209 Robert Sparks, Adam Roach, and Rohan Mahy provided useful comments on 210 this document. 212 10. References 214 10.1 Normative References 216 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 217 Levels", BCP 14, RFC 2119, March 1997. 219 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 220 Specifications: ABNF", RFC 2234, November 1997. 222 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 223 Session Description Protocol (SDP)", RFC 3264, June 2002. 225 [4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session 226 Description Protocol", draft-ietf-mmusic-sdp-new-21 (work in 227 progress), October 2004. 229 10.2 Informative References 231 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 232 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 233 Session Initiation Protocol", RFC 3261, June 2002. 235 [6] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, 236 "Grouping of Media Lines in the Session Description Protocol 237 (SDP)", RFC 3388, December 2002. 239 Authors' Addresses 241 Orit Levin 242 Microsoft Corporation 243 One Microsoft Way 244 Redmond, WA 98052 245 USA 247 EMail: oritl@microsoft.com 249 Gonzalo Camarillo 250 Ericsson 251 Hirsalantie 11 252 Jorvas 02420 253 Finland 255 EMail: Gonzalo.Camarillo@ericsson.com 257 Intellectual Property Statement 259 The IETF takes no position regarding the validity or scope of any 260 Intellectual Property Rights or other rights that might be claimed to 261 pertain to the implementation or use of the technology described in 262 this document or the extent to which any license under such rights 263 might or might not be available; nor does it represent that it has 264 made any independent effort to identify any such rights. Information 265 on the procedures with respect to rights in RFC documents can be 266 found in BCP 78 and BCP 79. 268 Copies of IPR disclosures made to the IETF Secretariat and any 269 assurances of licenses to be made available, or the result of an 270 attempt made to obtain a general license or permission for the use of 271 such proprietary rights by implementers or users of this 272 specification can be obtained from the IETF on-line IPR repository at 273 http://www.ietf.org/ipr. 275 The IETF invites any interested party to bring to its attention any 276 copyrights, patents or patent applications, or other proprietary 277 rights that may cover technology that may be required to implement 278 this standard. Please address the information to the IETF at 279 ietf-ipr@ietf.org. 281 Disclaimer of Validity 283 This document and the information contained herein are provided on an 284 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 285 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 286 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 287 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 288 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 289 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 291 Copyright Statement 293 Copyright (C) The Internet Society (2004). This document is subject 294 to the rights, licenses and restrictions contained in BCP 78, and 295 except as set forth therein, the authors retain all their rights. 297 Acknowledgment 299 Funding for the RFC Editor function is currently provided by the 300 Internet Society.