One document matched: draft-khartabil-sip-policy-uri-call-info-purpose-01.txt
Differences from draft-khartabil-sip-policy-uri-call-info-purpose-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 23:38:53 |