idnits 2.17.1 draft-roach-mmusic-groupid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5888, updated by this document, for RFC5378 checks: 2008-06-14) -- 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 (December 02, 2013) is 3791 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 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. B. Roach 3 Internet-Draft M. Thomson 4 Updates: 5888 (if approved) Mozilla 5 Intended status: Standards Track December 02, 2013 6 Expires: June 05, 2014 8 An Extension for Identification of Groups in the Session Description 9 Protocol (SDP). 10 draft-roach-mmusic-groupid-00 12 Abstract 14 RFC 5888 defines a mechanism for semantically grouping media sections 15 in the Session Description Protocol (SDP). One difficulty that has 16 arisen in several applications of SDP is the need to uniquely 17 identify these groups either in other protocols or elsewhere in the 18 SDP itself. 20 This document proposes a simple, backwards-compatible mechanism that 21 provides unambiguous identifiers for RFC 5888 groups. 23 This document updates RFC 5888. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 05, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Mechanism Description . . . . . . . . . . . . . . . . . . . . 2 62 4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 68 1. Introduction 70 [RFC5888] defines a mechanism for semantically grouping media 71 sections in the Session Description Protocol (SDP) [RFC4566] for 72 purposes such as lip sync and flow identification. That mechanism, 73 however, defines anonymous groupings, which makes it impossible to 74 reliably and unambiguously refer to such groups at a later time (e.g. 75 elsewhere in the SDP, or in an application-layer protocol). This 76 document defines a new attribute, "group-id", that can be used to 77 attach identifiers to SDP groups. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 3. Mechanism Description 87 The mechanism used to assign identifiers to group is very simple and 88 straightforward: implementations that wish to assign an identifier to 89 groups include a single "group-id" attribute immediately before each 90 "group" attribute in the session. Importantly, it retains backwards- 91 compatible with existing [RFC5888] implementations. This "group-id" 92 attribute contains a single token, unique within the session, that 93 unambiguously identifies the group defined on the following line. 94 Each media section included in that group additionally MUST contain 95 an "in-group" attribute that includes the [RFC5888] semantic 96 identifier and group-id. This "in-group" identifier is intended to 97 allow media sections to be self-describing when they appear outside 98 the context of a full session. 100 For clarity: if an implementation includes a group-id for any groups 101 in a session, that implementation MUST include a group-id for every 102 group in that session. Implementations MUST NOT include any 103 attributes between a "group-id" attribute and the "group" attribute 104 it identifies. Recipients of such SDP in which a "group-id" appears 105 followed by anything other than the "group" attribute MUST ignore the 106 errant "group-id" line. 108 A simple example of the new group-id syntax follows. This example 109 defines a single lip-sync group, and identifies it with the group 110 identifier "abc." 112 v=0 113 o=Laura 289083124 289083124 IN IP4 eight.example.com 114 c=IN IP4 192.0.2.1 115 t=0 0 116 a=group-id:abc 117 a=group:LS 1 2 118 m=audio 30000 RTP/AVP 0 119 a=mid:1 120 a=in-group:LS abc 121 m=audio 30000 RTP/AVP 8 122 a=mid:2 123 a=in-group:LS abc 125 4. Syntax 127 The new attributes introduced by this mechanism are defined by the 128 following ABNF [RFC5234]: 130 groupid-attribute = "a=group-id:" group-id 132 group-id = token ; token is defined in RFC 4566 134 in-group-attr = "a=in-group:" semantics SP group-id 135 ; semantics is defined in RFC 5888 137 5. Security Considerations 139 This mechanism does not introduce any security issues beyond those 140 discussed in [RFC5888]. 142 6. IANA Considerations 144 This document defines two SDP attributes: "group-id" and "in-group". 145 They are to be registered by IANA in the "SDP Parameters" registry as 146 follows: 148 SDP Attribute ("att-field"): 150 Attribute name: group-id 151 Long form: Group ID 152 Type of name: att-field 153 Type of attribute: session level 154 Subject to charset: no 155 Purpose: Identification of SDP groups 156 Reference: this document 157 Values: any token 159 SDP Attribute ("att-field"): 161 Attribute name: in-group 162 Long form: Add media section to group 163 Type of name: att-field 164 Type of attribute: media level 165 Subject to charset: no 166 Purpose: Associating media sections with groups 167 Reference: this document 168 Values: semantic type followed by group identifier 170 7. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 176 Description Protocol", RFC 4566, July 2006. 178 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 179 Specifications: ABNF", STD 68, RFC 5234, January 2008. 181 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 182 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 184 Authors' Addresses 185 Adam Roach 186 Mozilla 187 Dallas, TX 188 US 190 Phone: +1 650 903 0800 x863 191 Email: adam@nostrum.com 193 Martin Thomson 194 Mozilla 195 650 Castro St. Suite 300 196 Mountain View, CA 94041-2021 197 US 199 Phone: +1 650 903 0800 200 Email: mt@moilla.com