<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sips:conf233@example.com"
state="partial" version="5">
<!--
CONFERENCE INFO
-->
<conference-description>
<display-text>Weekly Sales Meeting</display-text>
<subject>Agenda: This month’s goals</subject>
<free-text>We will start strict on time</free-text>
<keywords>sales meeting weekly</keywords>
<conf-uris>
<entry>
<uri>tel:+18005671234</uri>
<display-text>TTI Bridge</display-text>
<purpose>participation</purpose>
</entry>
<entry>
<uri>h323:conf545@h323.example.com</uri>
<purpose>participation</purpose>
</entry>
<entry>
<uri>http://real.streaming.com/54634/live.ram</uri>
<purpose>streaming</purpose>
</entry>
</conf-uris>
<service-uris>
<entry>
<uri>http://sharepoint/salesgroup/</uri>
<purpose>web-page</purpose>
</entry>
<entry>
<uri>http://quicktime.com/54634/recording.mov</uri>
<display-text>Quicktime</display-text>
<purpose>recording</purpose>
</entry>
</service-uris>
<maximum-user-count>100</maximum-user-count>
<available-media>
<entry label="34567">
<display-text>main audio</display-text>
<type>audio</type>
<status>sendrecv</status>
</entry>
<entry label="34569">
<display-text>main video</display-text>
<type>video</type>
<status>inactive</status>
</entry>
</available-media>
</conference-description>
<!--
HOST INFO
-->
<host-info>
<display-text>Sales Host</display-text>
<web-page>http://sharepoint/salesgroup/hosts/</web-page>
<uris>
<entry>
<uri>sip:sales@example.com</uri>
</entry>
</uris>
</host-info>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>32</user-count>
<active>true</active>
<locked>false</locked>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:bob@example.com">
<display-text>Bob Hoskins</display-text>
<associated-aors>
<entry>
<uri>mailto:bob@example.com</uri>
<display-text>email</display-text>
</entry>
</associated-aors>
<roles>
<entry>participant</entry>
</roles>
<languages>en</languages>
<!--
ENDPOINTS
-->
<endpoint entity="sip:bob@pc33.example.com">
<display-text>Bob’s Laptop</display-text>
<referred>
<when>2005-03-04T20:00:00Z</when>
<reason>expert required</reason>
<by>sip:mike@example.com</by>
</referred>
<status>disconnecting</status>
<joining-method>dialed-out</joining-method>
<joining-info>
<when>2005-03-04T20:00:00Z</when>
<reason>invitation</reason>
<by>sip:mike@example.com</by>
</joining-info>
<disconnection-method>booted</disconnection-method>
<disconnection-info>
<when>2005-03-04T20:00:00Z</when>
<reason>bad voice quality</reason>
<by>sip:mike@example.com</by>
</disconnection-info>
<!--
MEDIA
-->
<media id="1">
<display-text>main audio</display-text>
<type>audio</type>
<label>34567</label>
<src-id>432424</src-id>
<status>sendrecv</status>
</media>
<!--
CALL INFO
-->
<call-info>
<sip>
<display-text>full info</display-text>
<call-id>hsjh8980vhsb78</call-id>
<from-tag>vav738dvbs</from-tag>
<to-tag>8954jgjg8432</to-tag>
</sip>
</call-info>
</endpoint>
</user>
</users>
<!--
SIDEBARS BY REFERENCE
-->
<sidebars-by-ref state="partial">
<entry>
<uri>sips:conf233@example.com;grid=45</uri>
<display-text>sidebar with Carol</display-text>
</entry>
<entry>
<uri>sips:conf233@example.com;grid=21</uri>
<display-text>private with Peter</display-text>
</entry>
</sidebars-by-ref>
<!--
SIDEBARS BY VALUE
-->
<sidebars-by-val state="partial">
<entry entity="sips:conf233@example.com;grid=77"
state="partial">
<users>
<user entity="sip:bob@example.com"/>
<user entity="sip:mark@example.com"/>
<user entity="sip:dan@example.com"/>
</users>
</entry>
</sidebars-by-val>
</conference-info>
8. Security Considerations
Subscriptions to conference state information can reveal very
sensitive information. For this reason, it is RECOMMENDED that a
focus use a strong means for authentication and conference
information protection and that it apply comprehensive authorization
rules when using the conference notification mechanism defined in
this document. The following sections will discuss each of these
aspects in more detail.
8.1. Connection Security
It is RECOMMENDED that a focus authenticate a conference package
subscriber using the normal SIP authentication mechanisms, such as
Digest as defined in Section 22 of RFC 3261 [8].
The mechanism used for conveying the conference information MUST
ensure integrity and SHOULD ensure confidentially of the information.
In order to achieve these, an end-to-end SIP encryption mechanism,
such as S/MIME described in Section 26.2.4 of RFC 3261 [8], SHOULD be
used.
If a strong end-to-end security means (such as above) is not
available, it is RECOMMENDED that a focus use mutual hop-by-hop
Transport Layer Security (TLS) authentication and encryption
mechanisms described in Section 26.2.2 "SIPS URI Scheme" and Section
26.3.2.2 "Interdomain Requests" of RFC 3261 [8].
8.2. Authorization Considerations
Generally speaking, conference applications are very concerned about
authorization decisions. Mechanisms for establishing and enforcing
such authorization rules are a central concept throughout the SIP
Conferencing Framework [16]. Because most of the information about a
conference can be presented using the conference package, many of the
authorization rules directly apply to this specification. As a
result, a notification server MUST be capable of generating distinct
conference information views to different subscribers, subject to a
subscriber’s role in a conference, personal access rights, etc. - all
subject to local authorization policies and rules.
Since a focus provides participant identity information using this
event package, participant privacy needs to be taken into account. A
focus MUST support requests by participants for privacy. Privacy can
be indicated by the conference policy - for every participant or
select participants. It can also be indicated in the session
signaling. In SIP, this can be done using the Privacy header field
described in RFC 3323 [11]. For a participant requesting privacy, no
identity information SHOULD be revealed by the focus in any included
URI (e.g., the Address of Record, Contact, or GRUU). For these
cases, the anonymous URI generation method outlined in Section 5.6 of
this document MUST be followed.
9. IANA Considerations
This document registers a SIP event package, a new MIME type,
application/conference-info+xml, a new XML namespace, and a new XML
schema, and creates a sub-registry "URI purposes" under the existing
registry: http://www.iana.org/assignments/sip-parameters.
9.1. conference Event Package Registration
This specification registers an event package, based on the
registration procedures defined in RFC 3265 [10]. The following is
the information required for such a registration:
Package Name: conference
Package or Template-Package: This is a package.
Published Document: RFC 4575
Person to Contact: IETF SIPPING Working Group <sipping@ietf.org>, as
designated by the IESG <iesg@ietf.org>
9.2. application/conference-info+xml MIME Registration
MIME media type name: application
MIME subtype name: conference-info+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [7]
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [7]
Security considerations: See Section 10 of RFC 3023 [7] and
Section 8 of this specification
Interoperability considerations: none
Published specification: This document
Applications which use this media type: This document type has been
used to support SIP conferencing applications
Additional Information:
Magic Number: None
File Extension: .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: IETF SIPPING
Working Group <sipping@ietf.org>, as designated by the IESG
<iesg@ietf.org>
Intended usage: COMMON
Author/Change controller: IETF SIPPING Working Group
<sipping@ietf.org>, as designated by the IESG <iesg@ietf.org>
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:conference-info
This section registers a new XML namespace, as per the guidelines in
RFC 3688 [21].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:conference-info
Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>,
as designated by the IESG <iesg@ietf.org>
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Conference Information Namespace</title>
</head
<body>
<h1>Namespace for Conference Information</h1>
<h2>urn:ietf:params:xml:ns:conference-info</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4575.txt">
RFC4575</a>.</p>
</body>
</html>
END
9.4. XML Schema Registration
This specification registers a schema, as per the guidelines in RFC
3688 [21].
URI: please assign
Registrant Contact: IETF SIPPING Working Group <sipping@ietf.org>,
as designated by the IESG <iesg@ietf.org>
XML: The XML can be found as the sole content of Section 6.
9.5. URI Purposes Sub-registry Establishment
The IANA has created a new sub-registry, "URI purposes", under the
already existing registry:
http://www.iana.org/assignments/sip-parameters.
The purpose of a URI is an XML element, encoded in the conference
event package RFC 4575. The value of the <purpose> element indicates
the intended usage of the URI in the context of the conference event
package and is defined in Sections 5.3.1 and 5.3.2 of this
specification.
This sub-registry is defined as a table that contains the following
three columns:
Value: The token under registration
Description: A descriptive text defining the intended usage of the
URI
Document: A reference to the document defining the registration
The IANA has created the table with the initial content as defined
below:
Value Description Document
------- ---------------------------------- ----------
participation The URI can be used to join the [RFC 4575]
conference
streaming The URI can be used to access the [RFC 4575]
streamed conference data
event The URI can be used to subscribe [RFC 4575]
to the conference event package
recording The URI can be used to access the [RFC 4575]
recorded conference data
web-page The URI can be used to access a [RFC 4575]
web page that contains additional
information of the conference
New values of the "URI purposes" are registered by the IANA and are
specification required according to the definition of RFC 2434 [4].
The IANA Considerations section of the specification MUST include the
following information:
Value: The value of the <purpose> element to be registered
Description: A short description of the intended usage of the URI
10. Acknowledgements
The authors would like to thank Dan Petrie, Sean Olson, Alan
Johnston, Rohan Mahy, Cullen Jennings, Brian Rosen, Roni Even, and
Miguel Garcia for their comments and inputs.
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[5] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names",
BCP 32, RFC 2606, June 1999.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[7] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[8] 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.
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[10] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[11] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[12] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002.
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[15] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
Mechanism", RFC 3892, September 2004.
[16] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
[17] Levin, O. and G. Camarillo, "The Session Description Protocol
(SDP) Label Attribute", RFC 4574, August 2006.
11.2. Informative References
[18] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[19] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[20] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme
Registration", RFC 3508, April 2003.
[21] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[22] Saint-Andre, P., "A Uniform Resource Identifier (URI) Scheme
for the Extensible Messaging and Presence Protocol (XMPP)",
Work in Progress, December 2004.
[23] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[24] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", Work in Progress, May 2006.
[25] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
Authors’ Addresses
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027
US
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Orit Levin (editor)
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
EMail: oritl@microsoft.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).