Internet Draft E. Kim Internet Engineering Task Force S. Kang draft-ekim-sipping-conf-floor-package-00.txt ETRI October 2004 G. Camarillo Expires April 2004 Ericsson A Session Initiation Protocol (SIP) Event Package for Conference Floor State draft-ekim-sipping-conf-floor-package-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a conference floor event package for Session Initiation Protocol (SIP) conferences that require floor control. The conference floor event package allows users to subscribe to a conference floor server URIs. Notifications are sent about changes in the floor state of the conference and optionally about changes in the state of additional floor components of the conference. Subscriptions and notifications of conference floor are supported by an event package within the general SIP event notification framework. EKim, et al Expires April 2005 [Page 1] INTERNET DRAFT conference floor state package October 2004 Table of Contents 1. Introduction..................................................3 2. Conventions Used in This Document.............................3 3. Terminology...................................................4 4. Conference Floor Event Package................................4 4.1 Event Package Name........................................4 4.2 SUBSCRIBE Bodies..........................................5 4.3 Duration of the subscription..............................5 4.4 Notify bodies.............................................5 4.5 Notifier Processing of SUBSCRIBE Requests.................5 4.6 Notifier Generation of NOTIFY Requests....................6 4.7 Subscriber Processing of NOTIFY Requests..................6 4.8 Handling of Forked Requests...............................6 4.9 Rate of Notification......................................6 5. Data format...................................................7 5.1 Floor Information.........................................7 5.1.1 Resource element.......................................7 5.1.2 Chairs element.........................................8 5.1.3 State element..........................................8 5.2 Schema....................................................9 5.3 Example..................................................10 6. Security Considerations......................................11 7. IANA considerations..........................................11 8. References...................................................11 Acknowledgment..................................................12 Authors' Addresses..............................................12 Intellectual Property Statement.................................13 Disclaimer of Validity and Copyright Statement..................14 ekim, et al Expires April 2005 [Page 2] INTERNET DRAFT conference floor state package October 2004 1. Introduction The Session Initiation Protocol (SIP) [1] conference package [3] defines an event package for SIP conferences providing the conference notification service as outlined in the SIP conferencing framework [4]. Here, we define conference floor event package for SIP conferences, which support conference floor event followed the rule defined in RFC3265, the general event notification framework of SIP [2]. This document aims at providing state information of floor control of a conference to its participants, no matter which participant supports specific floor control protocol or not. As long as a participant supports SIP conference floor event, even though it does not include a specific floor control protocol such as BFCP [5], it can get the changes of floor state of the conference it joins by subscribing the event. The conference floor server URI acts as the notifier, and provides clients with updates on conference floor state. Another possible scenario to get floor event information is that conference participants subscribe to the conference server, called focus [4], and the conference server requests the floor information to the floor control server and acts as the notifier. Focus and floor control server are logical entities, and communication between the focus and floor control server is out of the scope of the document. This document is intended to continue a discussion to explore standard operations for conference floor event package. Please send comments to the mailing list 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. ekim, et al Expires April 2005 [Page 3] INTERNET DRAFT conference floor state package October 2004 3. Terminology Floor: A permission to temporarily access or manipulate a specific shared resource or set of resources. Floor control: A mechanism that enables applications or users to gain safe and mutually exclusive or non-exclusive input access to the shared object or resource. Floor control server: A logical entity that maintains the state of the floor(s) including which floors exists, who the floor chairs are, who holds a floor, etc. Requests to manipulate a floor are directed at the floor control server. 4. Conference Floor Event Package RFC3265 defining the general event notification framework of SIP [2] provides an extension to SIP [1] for events. This document is for specifying conference floor event. The general information required for SIP event package is following RFC3265. SIP clients who participate in a conference providing floor control subscribe to the floor control server represented by URIs. The floor control server has all state information for floors in the conference [5], and it notifies the floor state to the subscribed participants. It is possible a participant in the conference may use a specific floor control protocol like BFCP [5], and get the information of the floor state by the protocol. However, some parts of participants may not support such protocol and still want to have the knowledge of the floors of the conference. This event package can be used for such participants. 4.1 Event Package Name The name of the conference floor control event package is "floor". This value appears in the Event and Allow-Events header, as described in RFC3265. Example of usage: Event: floor ekim, et al Expires April 2005 [Page 4] INTERNET DRAFT conference floor state package October 2004 4.2 SUBSCRIBE Bodies A SUBSCRIBE for a conference floor package MAY contain a body. The body can contain specific type of floor. A SUBSCRIBE for a conference floor package MAY be sent without a body. This implies the default subscription filtering policy. By the default policy, notifications are generated whenever if there is any change in the state of the floors in the conference. Notifications normally contain partial state that has changed. The exception is a NOTIFY sent in response to a SUBSCRIBE. These NOTIFYs contain the full state of the information requested by the subscriber. 4.3 Duration of the subscription The duration of this subscription is following the rule of the conference event package [3]. 4.4 Notify bodies As described in RFC 3265 [2], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE, or a package-specific default if the Accept header field was omitted from the SUBSCRIBE. In this event package, the body of the notification contains floors document. This document describes the state of floors of a conference. All subscribers and notifiers MUST support the "application/floor-info+xml" data format described in Section 4. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/floor-info+xml". If the header field is present, it MUST include "application/floor-info+xml", and MAY include any other types capable of representing dialog state. 4.5 Notifier Processing of SUBSCRIBE Requests ekim, et al Expires April 2005 [Page 5] INTERNET DRAFT conference floor state package October 2004 The conference floors information contains sensitive information as the conference information [4]. When a conference URI acts as a notifier, it treats the floors information as the same policy with the conference information. When a floor control server acts as a notifter of this event, the authorization policy should be made. In a basic recommendation policy, all subscriptions SHOULD be authenticated and then authorized before approval. 4.6 Notifier Generation of NOTIFY Requests Notifications SHOULD be generated for the conference every time when a change is made in the state in any of the information delivered to the subscriber. The changes generally occur when a floor is accepted, granted, released, or withdraw to a participant, and when a floor holder is changed. 4.7 Subscriber Processing of NOTIFY Requests The NOTIFY for the conference floor event package will only contain information about those floors of which state has changed. To construct a coherent view of the total state of all floors, a subscriber to the event package will need to combine NOTIFYs received over time. TBD 4.8 Handling of Forked Requests The conference floors are handled in centralized way. Thus, SUBSCRIBE requests for this event should normally not be forked. 4.9 Rate of Notification RFC 3265 [2] requires each package to specify the maximum rate at which notifications can be sent. With consideration of the congestion control, it is RECOMMENDED that the server not ekim, et al Expires April 2005 [Page 6] INTERNET DRAFT conference floor state package October 2004 generate notifications for a single subscriber at a rate faster than once every 5 seconds, applying the same rule with the conference event package [4]. 5. Data format XML document is used for the conference floor information. It MUST be well-formed and SHOULD be valid. The document SHOULD be based on XML 1.0 and MUST be encoded using UTF-8. The namespace URI for elements defined by this specification is a URN [6], using the namespace identifier 'ietf' defined by [7] and extended by [8]. This URN is: urn:ietf:params:xml:ns:floor-info A conference floor information document begins with the root element tag "floor-info". 5.1 Floor Information Floor information has the root element "floors-info". This element has an attribute, "conf-uri". The attribute is the identifier of the conference in which the floors are exchanged. The root element also has zero or more "floor-info" sub-element. The "floor-info" has one mandatory attribute, "floor-id". It is the identifier of a floor. If SDP or BFCP assigns a floor-id for a resource, this value is matched with the value. The "floor-info" has one "resource" sub-element, which identifies the type (audio, video) or codec of the floor resource. It has zero or more "chairs" sub-element that gives the information of chairs who take charge of the floor. "user" sub-element is for describing who requests, holds, or release the floor. "state" sub-element explains current status of the floor, such as the floor is granted, released, etc. 5.1.1 Resource element The resource element specifies the resource name matched with the floor. Generally it will be the same with the media name appeared in the m lines of SDP. ekim, et al Expires April 2005 [Page 7] INTERNET DRAFT conference floor state package October 2004 5.1.2 Chairs element The chairs element has zero or more chair element which is describing the URIs of the chair. More than one chair can take charge of a floor. If this element is used, it SHOULD show the all members of the chair for the floor. 5.1.3 State element The state element shows the current state of the floor, and the time information about the floor. It has "transaction" attribute, which identifies the floor request. The state element also has one or more "users" sub-element, one or more "floor-state" sub- element, zero or more "action-time" sub-element and "expiration" sub-element. The users element has one or more user element which is identified by URIs. The user element is used for reporting the participants who currently make an action about the floor. The "floor-state" element is for the state of the floor related any action taken for the floor. It has the value of "requested," "accepted," "granted," "released," or "withdrawn". The following explains the usage of the values. requested: The floor is requested. accepted: The requested floor is accepted by floor server. granted: The requested floor is granted by floor server. In an internal operation, floor server sends the request to the floor chair(s), and the request is admitted by the floor chair(s). The specific functional behavior is out of the scope of this document and it will be performed by a floor control protocol. released: The floor holder releases the floor. withdrawn: The floor which has been holding by someone is enforced to be taken back by some reason. The reason will be dependant on the policy of a floor control protocol. The "action-time" element notifies the time when the floor operation is made. The "expiration" is for the time information for the floor, especially notifies the expiration time. ekim, et al Expires April 2005 [Page 8] INTERNET DRAFT conference floor state package October 2004 5.2 Schema ekim, et al Expires April 2005 [Page 9] INTERNET DRAFT conference floor state package October 2004 5.3 Example The following is an example document of floor information. ekim, et al Expires April 2005 [Page 10] INTERNET DRAFT conference floor state package October 2004 audio granted 2004-10-17T09:30:47 2004-10-17T09:45:47 requsted 2004-10-17T09:32:00 6. Security Considerations Conference floor information is very sensitive information, so that the server MUST use appropriate authentication to ensure the commands to manipulate or interact the data originated from trusted parties. Other SIP considerations apply. The further concerned security issues will be identified as the further works go on. 7. IANA considerations The following URN sub-namespace should be registered. URI: urn:ietf:params:xml:ns:floor-info 8. References [1] J. Rosenberg, H. Schulzrinne, et al, "SIP: Session Initiation Protocol, " RFC3261, Internet Engineering Task Force, Jun. 2002. [2] A. Roach, "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. ekim, et al Expires April 2005 [Page 11] INTERNET DRAFT conference floor state package October 2004 [2] J. Rosenberg, "A framework for conferencing with the session initiation protocol, " Internet Draft, Internet Engineering Task Force, Feb. 2003. Work in progress. [3] J. Rosenberg, H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State, " Internet Draft, Internet Engineering Task Force, Jul. 2004. Work in progress. [4] P. Koskelainen, "Requirements for conference policy data, " Internet Draft, Internet Engineering Task Force, Feb. 2003. Work in progress. [4] W3C, "Simple Object Access Protocol (SOAP) 1.1. " [5] G. Camarillo, J. Ott, K. Drage, "The Binary Floor Control Protocol (BFCP), " Internet Draft, Internet Engineering Task Force, April. 2004. Work in progress. [6] R. Moats, "URN syntax, " RFC2141, Internet Engineering Task Force, May 1997. [7] R. Moats, "A URN namespace for IETF documents, " RFC2648, Internet Engineering Task Force, Aug. 1999. [8] M. Mealling, "The IETF XML registry, " Internet Draft, Internet Engineering Task Force, Jul. 2002. Work in progress. Acknowledgment Authors' Addresses Eunsook Kim 361 Gajeong-Dong Yuseong-Gu Deajon 305-350 Korea E-mail: eunah@etri.re.kr ekim, et al Expires April 2005 [Page 12] INTERNET DRAFT conference floor state package October 2004 Shin-Gak Kang 361 Gajeong-Dong Yuseong-Gu Deajon 305-350 Korea E-mail: sgkang@etri.re.kr Gonzalo Camarillo Hirsalantie 11 Jorvas 02420 Finland E-mail: Gonzalo.Camarillo@ericsson.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. ekim, et al Expires April 2005 [Page 13] INTERNET DRAFT conference floor state package October 2004 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. ekim, et al Expires April 2005 [Page 14]