idnits 2.17.1 draft-ekim-mmusic-sdp-membership-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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 303. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 319), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: Standard Tracks', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (April 2005) is 6944 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. '1') (Obsoleted by RFC 4566) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group E. Kim 2 Internet Engineering Task Force J. Park 3 Category: Standard Tracks S. Kang 4 October 2004 ETRI 5 Expires April 2005 7 Tight membership support in SDP 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six Months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 17, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document defines a set of Session Description Protocol 41 (SDP)attributes that allow SDP to provides tightly controlled 42 membership information. Some multimedia conferencing applications may 43 require strict membership control policies. A group session creator 44 describes basic membership information in SDP, and it can be 45 negotiated by the Offer / Answer model. 47 Table of Contents 49 1. Introduction...................................................3 50 2. Conventions used in this document..............................3 51 3. Terminology....................................................3 52 4. New attributes for membership description in SDP...............5 53 4.1 Attributes for group policy................................5 54 4.2 Attributes for Membership Information......................5 55 5. Example of membership negotiation..............................6 56 6. Security Considerations........................................7 57 7. References.....................................................7 58 Acknowledgments...................................................8 59 Author's Addresses................................................8 60 Intellectual Property Statement and Copyright Statement...........9 62 1. Introduction 64 Session Description Protocol (SDP) [1] is designed to convey 65 multimedia conference relevant information to recipients. It provides 66 general description for all multimedia sessions. 68 However, it still does not provide specific membership information 69 which is necessary for some multicast sessions. Many scenarios can be 70 examples requiring membership information. In a conference, group 71 organizer may want to designate who should be mandatory participants 72 and how many number of participants are able to be handled when it 73 create a session. In a closed group where only specific member are 74 invited, a prospective group participant may want to know specific 75 group information as well as general information before session 76 joining, and may want to block a specific member. The initial 77 information described by group organizer can be negotiated with the 78 group joiners by Offer/Answer model [2]. 80 This draft is based upon a set of requirements to deliver tight 81 controlled membership information. It defines a set of new SDP 82 attributes that satisfy the requirements of tight membership control. 84 2. Conventions used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [3] and 89 indicate requirement levels for compliant implementations. 91 3. Terminology 93 closed model 95 only pre-determined, pre-announced, or end systems determined 96 during runtime can join a session. 98 static model 100 the group of participants does not change during runtime of the 101 session. 103 dynamic model 104 the group of participants might change during runtime of the 105 session. 107 loose model 109 a loose group is one for which it is not possible to determine 110 the group membership 112 tight model 114 a tight group can provide individual information of member, which 115 can be fully controlled. There may be two sub-categories by 116 participants' knowledge of the membership information: 117 completely-tight or partially tight model. 119 completely-tight model 121 every member may have knowledge of the individual name or email 122 address, or et al. 124 partially-tight model 126 a subset of members may have knowledge of the individual name or 127 address of every member (e.g. in a conference, a chairman and one 128 or more speakers can acquire the individual details). 130 4. New attributes for membership description in SDP 132 For tight controlled membership, SDP MUST have the optional 133 attributes to specify additional features: 135 - Group Characteristics: If the group is created as a static, 136 closed model or not. 138 - Membership Information: If there are mandatory members who 139 should be participated, group organizer may describe the list 140 of members. 142 4.1 Attributes for group policy 144 * a=agipolicy: 145 a=agipolicy:/ 147 A session owner can define this attribute when it creates a session. 148 Active Group Integrity(AGI) means a set of conditions concerning an 149 active group. filed holds "hard" or "soft". In "hard" policy, 150 the transport connection MUST be terminated when the AGI is violated. 151 In "soft" policy, it MUST be suspended when the AGI is violated and 152 it will be restored if the AGI is recovered. 154 defines "unity" or "quorum". "unity" specifies that all 155 of enrolled group members are required to be present in the active 156 group. "quorum" implies that the majority of group members are 157 required to be present. 159 4.2 Attributes for Membership Information 161 * a=max: 163 This attributes specifies maximum number of participants that can be 164 allowed in an active group. The value of is 165 represented as a numeric number like "a=max:100". 167 * a=min: 169 This attributes specifies minimum number of participants that can be 170 allowed in an active group. The value of is 171 represented as a numeric number like "a=min:3". 173 * a=token: 175 This attribute specifies maximum number of participants that can be 176 allowed to concurrently transmit data. The value of is 177 represented as a numeric number like "a=token number:3". 179 * a=mandatory:permission // 181 This attribute specifies the selected group members required to be 182 present or blocked in an active group. The value of permission is 183 "in" or "out", which represents the user is a mandatory participant 184 or a blocked participant. A series of "a=mandatory" can be specified 185 as following examples: 187 a=mandatory:in eunah// / 188 a=mandatory:out bob// / 190 is the same with in origin field of RFC2327. 191 address the users contact information. can be used to 192 specify additional information. 194 In order to identify mandatory users, a key should be exchanged, but 195 the detail methods of the key exchanges are of out the scope of this 196 document. 198 5. Example of membership negotiation 200 Assume that the caller, Alice, has included the following description 201 in her offer. The offered SDP is: 203 v=0 204 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com 205 s=Example of SDP extension for group information 206 c=IN IP4 host.anywhere.com 207 t=0 0 208 a=agipolicy:hard/quorum 209 a=min:3 210 a=token:2 211 a=mandatory:in bob// / 212 a=mandatory:in eunah/Eunsook Kim / / 213 m=audio 49170 RTP/AVP 0 214 a=rtpmap:0 PCMU/8000 215 m=video 51372 RTP/AVP 31 216 a=rtpmap:31 H261/90000 217 The callee, Bob, want to create the group with "unity" condition, so 218 he returns the SDP below as the answer: 220 v=0 221 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com 222 s=Example of SDP extension for group information 223 c=IN IP4 host.anywhere.com 224 t=0 0 225 a=agipolicy:hard/unity 226 a=min:3 227 a=token:2 228 a=mandatory:in bob// / 229 a=mandatory:in eunah/Eunsook Kim / / 230 m=audio 49170 RTP/AVP 0 231 a=rtpmap:0 PCMU/8000 232 m=video 51372 RTP/AVP 31 233 a=rtpmap:31 H261/90000 235 6. Security Considerations 237 Group membership policy and information is very sensitive information, 238 so that it MUST use appropriate authentication to ensure the data 239 originated from trusted parties. Other SDP considerations apply. The 240 further concerned security issues will be identified as the further 241 works go on. 243 7. References 245 [1] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 246 2327, April 1998 248 [2] J. Rosenberg, H. Schulzrinne, " An Offer/Answer Model with the 249 Session Description Protocol (SDP)," RFC 3264, June 2002. 251 [3] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 252 Levels", BCP 14, RFC 2119, March 1997. 254 Acknowledgments 256 Authors are thanks for J. Ott and C. Perkins for their comments. 258 Author's Addresses 260 Eunsook Kim 261 161 Gajeong-Dong Yuseong-Gu 262 Deajon 305-350 263 Korea 265 E-mail: eunah@etri.re.kr 267 Juyoung Park 268 361 Gajeong-Dong Yuseong-Gu 269 Deajon 305-350 270 Korea 272 E-mail: jypark@etri.re.kr 274 Shin-Gak Kang 275 361 Gajeong-Dong Yuseong-Gu 276 Deajon 305-350 277 Korea 279 E-mail: sgkang@etri.re.kr 281 Intellectual Property Statement 283 The IETF takes no position regarding the validity or scope of any 284 Intellectual Property Rights or other rights that might be claimed 285 to pertain to the implementation or use of the technology described 286 in this document or the extent to which any license under such 287 rights might or might not be available; nor does it represent that 288 it has made any independent effort to identify any such rights. 289 Information on the procedures with respect to rights in RFC 290 documents can be found in BCP 78 and BCP 79. 292 Copies of IPR disclosures made to the IETF Secretariat and any 293 assurances of licenses to be made available, or the result of an 294 attempt made to obtain a general license or permission for the use 295 of such proprietary rights by implementers or users of this 296 specification can be obtained from the IETF on-line IPR repository 297 at http://www.ietf.org/ipr. 299 The IETF invites any interested party to bring to its attention any 300 copyrights, patents or patent applications, or other proprietary 301 rights that may cover technology that may be required to implement 302 this standard. Please address the information to the IETF at ietf- 303 ipr@ietf.org. 305 Disclaimer of Validity 307 This document and the information contained herein are provided on 308 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 309 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 310 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 311 IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 312 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 313 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 315 Copyright Statement 317 Copyright (C) The Internet Society (2004). This document is subject 318 to the rights, licenses and restrictions contained in BCP 78, and 319 except as set forth therein, the authors retain all their rights.