SIP WG H. Khartabil Internet-Draft A. Niemi Expires: November 16, 2004 Nokia May 18, 2004 Conveying a Conference Policy Uniform Resource Identifier (URI) in the Session Initiation Protocol (SIP) draft-khartabil-sip-policy-uri-call-info-purpose-01 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/ietf/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 November 16, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The Session Initiation Protocol (SIP) defines the Call-Info header field. This header field delivers additional information about the originator or recipient of a SIP request. Information in the Call-Info is generally a Uniform Resource Identifier (URI), and the exact purpose of this URI is described with the "purpose" parameter. This document introduces a new purpose parameter value of "conf-policy" that can be used by a conference server to indicate to a conference participant User Agent (UA) that the URI carried in the Khartabil & Niemi Expires November 16, 2004 [Page 1] Internet-Draft Call-Info Purpose for conf-policy May 2004 Call-Info header field is a URI for accessing the conference policy of a particular conference. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 3. Description of Node Behavior . . . . . . . . . . . . . . . . . 4 4. Augmented BNF Definitions . . . . . . . . . . . . . . . . . . 4 5. Example Call-Info . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 5 9.2 Informative References . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 Khartabil & Niemi Expires November 16, 2004 [Page 2] Internet-Draft Call-Info Purpose for conf-policy May 2004 1. Introduction The Session Initiation Protocol (SIP) [1] defines the Call-Info header field. The purpose of the Call-Info header field is to provide additional information about the caller or callee, depending on whether the header is used in a request or a response. This information consists of a URI, and the purpose of this URI is described by the "purpose" parameter. Some parameter values have already been defined: o icon, for providing an image suitable for an iconic representation of the caller or callee o info, for providing ageneral description of the caller or callee, e.g., in the form of a web page o card, for providing contact information, e.g., in the form of a business card In addition to these purpose values, additional purpose values can be registered with IANA. This document introduces a new purpose parameter value of "conf-policy" that is used by a caller or a callee to convey a URI where conference policy pertaining to the session can be accessed. The main use case for the "conf-policy" involves a conference server indicating the URI of the conference policy [5] of a particular conference to a participant User Agent (UA). This UA can then use the Call-Info URI to manipulate the conference policy. 2. Overview of Operation One of the pieces of information carried in the conference state event notifications [6] is the conference policy URI [5]. Participants that subscribe to the conference state event will become aware of the conference policy URI, and will therefore be able to access it and given appropriate access rights, manipulate it. Even in the absence of a conference state event subscription, conference participants need to be able to be informed of the conference policy URI. This document describes how the Call-Info header field is used to convey the conference policy URI to a SIP UA. Certainly other ways to advertise the conference policy URI are possible, e.g., through the use of web pages. However, these additional mechanisms are out of the scope of this document. There may be several ways in which a conference policy can be accessed. This document defines the Conference Policy Control Protocol (CPCP) [4] as the default mechanism for conference policy access. Other mechanisms are allowed but outside the scope of this Khartabil & Niemi Expires November 16, 2004 [Page 3] Internet-Draft Call-Info Purpose for conf-policy May 2004 document. 3. Description of Node Behavior To convey the conference policy URI to a conference participant SIP UA, the conference focus includes a Call-Info header field with a conference policy URI and the "purpose" parameter with a value fo "conf-policy" in either the INVITE request, or the 2xx response to an INVITE request. This URI is then used by the participant to manipulate the conference policy. Implementations that use the "conf-policy" Call-Info purpose MUST support CPCP [4] for conference policy control. If a User Agent does not support the "conf-policy" purpose, it MUST ignore the Call-Info header field. 4. Augmented BNF Definitions This section describes the syntax extensions required for event publication in SIP. The formal syntax definitions described in this section are expressed in the Augmented BNF [2] format used in SIP [1], and contain references to elements defined therein. token = "conf-policy" / token 5. Example Call-Info tbd 6. IANA Considerations This document defines a new "purpose" parameter value of "conf-policy" that requires a registration at IANA. Per the policies outlined in [3], the following information is to be added under "Header Field Parameters" in http://www.iana.org/assignments/sip-parameters: Header Field: Call-Info Parameter Name: purpose Reference: [RFCYYYY] (Note to RFC Editor: Replace [RFCYYYY] with the RFC number of this document when published. OPEN ISSUE: The exact way in which a new reference is added to an existing entry is not yet specified in [3] Khartabil & Niemi Expires November 16, 2004 [Page 4] Internet-Draft Call-Info Purpose for conf-policy May 2004 7. Security Considerations Conference policy as such may be sensitive information, which means that delivering any URIs that enable access to it needs to be done with security in mind. It is RECOMMENDED that proper authentication is performed when access to the conference policy is requested. If the access to the conference policy is controlled by the URI itself, e.g., provided by a cryptographically random character sequence in the URI, the URI SHOULD be sent using integrity protection as defined in [1]. 8. Acknowledgements The authors would like to thank Jonathan Rosenberg and Gonzalo Camarillo for interest and discussions on this topic. 9. References 9.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Camarillo, G., "The Internet Assigned Number Authority Header Field Parameter Registry for the Session Initiation Protocol", draft-ietf-sip-parameter-registry-01 (work in progress), November 2003. [4] Khartabil, H. and P. Koskelainen, "The Conference Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-xcap-00 (work in progress), May 2004. 9.2 Informative References [5] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-01 (work in progress), October 2003. [6] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-03 (work in progress), February 2004. Khartabil & Niemi Expires November 16, 2004 [Page 5] Internet-Draft Call-Info Purpose for conf-policy May 2004 Authors' Addresses Hisham Khartabil Nokia P.O. Box 321 Helsinki Finland Phone: +358 7180 76161 EMail: hisham.khartabil@nokia.com Aki Niemi Nokia P.O. Box 100 Helsinki Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Khartabil & Niemi Expires November 16, 2004 [Page 6] Internet-Draft Call-Info Purpose for conf-policy May 2004 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Khartabil & Niemi Expires November 16, 2004 [Page 7]