idnits 2.17.1 draft-boulton-xcon-conference-control-package-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (July 16, 2012) is 4302 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group C. Boulton 3 Internet-Draft NS-Technologies 4 Intended status: Standards Track M. Barnes 5 Expires: January 17, 2013 Polycom 6 July 16, 2012 8 An XCON Client Conference Control Package for the Media Control Channel 9 Framework 10 draft-boulton-xcon-conference-control-package-07 12 Abstract 14 The Centralized Conferencing framework defines a model whereby client 15 initiated interactions are required for creation, deletion, 16 manipulation and querying the state of a of conference. This 17 document defines a Media Control Channel Package for XCON client 18 initiated Conference Control. The Package is based on the Media 19 Control Channel Framework, which is also used for media server 20 control, thus optimizing the implementation for some entities 21 participating in an XCON system. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 17, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Control Package Detail . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Control Package Name . . . . . . . . . . . . . . . . . . . 6 63 5.2. Framework Message Usage . . . . . . . . . . . . . . . . . . 6 64 5.3. Common XML Support . . . . . . . . . . . . . . . . . . . . 6 65 5.4. Control Message Bodies . . . . . . . . . . . . . . . . . . 6 66 5.5. REPORT Message Bodies . . . . . . . . . . . . . . . . . . . 6 67 5.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Control Package Registration . . . . . . . . . . . . . . . 7 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The Conference Control Manipulation Protocol (CCMP) [RFC6503] 80 provides a standards based mechanism to enable third party conference 81 clients participating to interoperate with conference servers and 82 manipulate conference parameters using HTTP as a transport. A Data 83 Model [RFC6501] provides the data associated with a conference 84 instance that is the target for the CCMP protocol operations. 86 A Control Channel Framework[RFC6230] has been created based on the 87 Session Initiation protocol (SIP). It uses SIP to setup, maintain 88 and terminate a reliable control channel for the purpose of 89 exchanging control based interactions. While the control of media 90 was the original problem domain for which this framework was 91 developed, the Control Framework provides an extension template for 92 creating extensions that specify the semantic detail associated with 93 the control channel operations. The extension documents are known as 94 Control Packages and an example is the 'Basic Mixer Control Package' 95 [RFC6505]. 97 This document will specify a Control Package for Conference Control 98 using the SIP Control Framework. The target for these operations is 99 the same data, associated with conference instances per the data 100 model, as CCMP. It should be noted that this mechanism is a 101 complementary approach to CCMP. In fact this specification simply 102 provides a different transport mechanism. While the use of HTTP as a 103 transport for CCMP is ideal for certain network deployments (for 104 example Service Orientated Architectures), it is important to offer 105 an alternative access method for clients with non SOA based 106 technologies. 108 The Media Control Channel Framework provides the ideal mechanism for 109 reliably exchanging control messages between a conference client and 110 server. It provides inherent properties such as: 112 o Reliable delivery of control messages. 113 o Lightweight Protocol Data Units (PDU). 114 o Linked asynchronous transactional mechanism. 115 o Asynchronous event mechanism. 117 The SIP Control Framework uses SIP as its overlying rendezvous 118 mechanism. This provides all the inherent benefits like: 120 o SIP Service Location - Use SIP Proxies or Back-to-Back User Agents 121 for discovering Control Servers. 122 o SIP Security Mechanisms - Leverage established security mechanisms 123 such as Transport Layer Security (TLS) and Client Authentication. 125 o Connection Maintenance - The ability to re-negotiate a connection, 126 ensure it is active, audit parameters, and so forth. 127 o Agnostic - Allows for ease of extension. 129 Not only is the Media Control Channel Framework an ideal mechanism 130 for controlling conference instances by participating clients, it 131 also provides the property of re-use by conferencing systems of 132 functionality implemented for controlling Media Servers etc. This 133 includes re-using the SIP stack for control channel setup as well as 134 the Control Channel Framework stack for receiving/sending the PDUs 135 for multiple control packages in a conference system. 137 2. Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Terminology 145 This document reuses the terminology defined and used in the 146 framework and data model for centralized conferencing [RFC5239], 147 [RFC6501] and [RFC6503] . 149 4. Overview 151 The use of the Media Control Channel Framework offers an ideal 152 mechanism for creating, deleting and manipulating XCON conference 153 instances by participating clients. As the Control Channel Framework 154 is a generic mechanism, this section provides non-normative detail 155 showing how the Control Channel Framework can be applied to this 156 particular use-case. In [RFC5239], two distinct roles are defined - 157 A 'Control Client' and a 'Control Server'. Such roles are 158 interchangeable between entities within a session depending on 159 package requirements. A simple diagram is illustrated in Figure 1 160 +--------------SIP Traffic--------------+ 161 | | 162 v v 163 +-----+ +--+--+ 164 | SIP | | SIP | 165 |Stack| |Stack| 166 +---+-----+---+ +---+-----+---+ 167 | Control | | Control | 168 | Client |<----Control Channel---->| Server | 169 +-------------+ +-------------+ 171 Figure 1: Basic Architecture 173 The XCON Conference Control package will cast a participating 174 compliant User Agent that wishes to control a conference instance as 175 a 'Control Client' as defined in the SIP Control Framework. It will 176 have permission to generate and issue commands in CONTROL messages as 177 defined in Section 5.2 of this document. It will also have the 178 ability to receive responses to Conference Package CONTROL requests 179 that are contained in either appropriate responses or subsequent 180 REPORT messages, also specified in Section 5.2. The specific format 181 of the conference control messages and responses are defined in 182 Section 5.4 and Section 5.5. They re-use the format specified in 183 CCMP[RFC6503]. This provides a common binding set with alternative 184 access mechanism depending on client requirements. The previous 185 diagram can be updated as illustrated in Figure 2. 187 +--------------SIP Traffic--------------+ 188 | | 189 v v 190 +-----+ +--+--+ 191 | SIP | | SIP | 192 |Stack| |Stack| 193 +---+-----+---+ +---+-----+---+ 194 | XCON | | XCON | 195 | Control | | Conference | 196 | Client |<----Control Channel---->| System | 197 +-------------+ +-------------+ 199 Figure 2: Conference Control Architecture 201 Editor's Note: The Overview section will be expanded in later 202 versions of the document. 204 5. Control Package Detail 206 The Media Control Channel Framework defines rules that Control 207 Package extensions must provide mandatory information as described in 208 section 10 of [RFC6230]. This section fulfils the obligation. 210 5.1. Control Package Name 212 The SIP Control Framework requires a Control Package definition to 213 specify and register a unique package name. The name and version of 214 this Control Package is "xcon-conf-control/1.0". 216 5.2. Framework Message Usage 218 The Conference Control package uses the XML schema defined in CCMP 219 [RFC6503]. To maintain the consistency with the design of the XML 220 schema, the SIP Control Framework messages will be applied in a 221 similar manner. The CONTROL message will be used to contain requests 222 that enable conference manipulation - as specified in Section 5.4 and 223 can only travel from the client to a Conferencing System. Responses, 224 as specified in Section 5.5, can only travel from the Conferencing 225 System to an expectant client. Depending on the time it takes to 226 process the request (as specified in [RFC6230]), responses can either 227 be contained in a Control Framework 200 response or subsequent REPORT 228 method. 230 5.3. Common XML Support 232 The Control Framework requires a Control Package definition to 233 specify if the attributes for media dialog or conference references 234 are required. 236 This package requires that the XML Schema in Section 16.1 of 237 [RFC6230] MUST NOT be supported for media dialogs and conferences. 238 But rather this package SHOULD use the XML schema as defined in 239 [RFC6501], which is the same schema upon which CCMP is based. 241 5.4. Control Message Bodies 243 A valid CONTROL body message MUST conform to the XML schema defined 244 in [RFC6503] for the conference control. To be precise, the CONTROL 245 message body MUST comply only to the 'ccmp-request-type' complexType. 247 5.5. REPORT Message Bodies 249 A valid CONTROL body message MUST conform to the XML schema defined 250 in [RFC6503]. To be precise, the REPORT message body MUST comply 251 only to the 'ccmp-response-type' complexType. 253 5.6. Examples 255 TODO 257 6. IANA Considerations 259 6.1. Control Package Registration 261 This section registers a new Media Control Channel Framework package, 262 per the instructions in Section 12.1 of [RFC6230]. 264 To: ietf-sip-control@iana.org Subject: Registration of new Media 265 Control Channel Framework package Package Name: xcon-conf-control/1.0 266 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for 267 this specification.] Published Specification(s): RFCXXXX Person & 268 email address to contact for further information: IETF, XCON working 269 group, (xcon@ietf.org), Mary Barnes (mary.ietf.barnes@gmail.com). 271 7. Security Considerations 273 Access to conference control functionality needs to be tightly 274 controlled to avoid attackers disrupting conferences, adding 275 themselves to conferences or engaging in theft of services. 277 The Framework for Centralized Conferencing [RFC5239] specifies that 278 the protocols used for manipulation and retrieval of confidential 279 information MUST support a confidentiality and integrity mechanism. 280 To support the confidentiality and integrity requirements, all 281 conference control information included in the package defined in 282 this document SHOULD be carried over TLS. 284 Additional information should be added to this section based on the 285 final material in the Control Framework for SIP [RFC6230]. 287 There are also security issues associated with the authorization to 288 perform actions on the conferencing system to invoke specific 289 capabilities. Implementers MUST deploy appropriate authentication 290 and authorization mechanisms to ensure that only authorized entities 291 are able to manipulate the data. 293 8. Acknowledgments 295 9. References 296 9.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, 302 "Conference Information Data Model for Centralized 303 Conferencing (XCON)", RFC 6501, March 2012. 305 [RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, "Media 306 Control Channel Framework", RFC 6230, May 2011. 308 [RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer 309 Control Package for the Media Control Channel Framework", 310 RFC 6505, March 2012. 312 [RFC6503] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, 313 "Centralized Conferencing Manipulation Protocol", 314 RFC 6503, March 2012. 316 9.2. Informative References 318 [W3C.CR-wsdl20-20051215] 319 Chinnici, R., Moreau, J., Ryman, A., and S. Weerawarana, 320 "Web Services Description Language (WSDL) Version 2.0 Part 321 1: Core Language", W3C CR CR-wsdl20-20051215, 322 December 2005. 324 [W3C.REC-soap12-part1-20030624] 325 Gudgin, M., Mendelsohn, N., Nielsen, H., Moreau, J., and 326 M. Hadley, "SOAP Version 1.2 Part 1: Messaging Framework", 327 World Wide Web Consortium FirstEdition REC-soap12-part1- 328 20030624, June 2003, 329 . 331 [W3C.REC-soap12-part2-20030624] 332 Hadley, M., Mendelsohn, N., Nielsen, H., Gudgin, M., and 333 J. Moreau, "SOAP Version 1.2 Part 2: Adjuncts", World Wide 334 Web Consortium FirstEdition REC-soap12-part2-20030624, 335 June 2003, 336 . 338 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 339 Centralized Conferencing", RFC 5239, June 2008. 341 Authors' Addresses 343 Chris Boulton 344 NS-Technologies 346 Email: chris@ns-technologies.com 348 Mary Barnes 349 Polycom 350 TX 352 Email: mary.ietf.barnes@gmail.com