<state>confirmed</state>
</dialog>
</dialog-info>
Onhook: (implementation/policy choice for Alice to transition to this
"state" when terminated, or when no longer "seized")
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="full"
entity="sip:alice@example.com">
</dialog-info>
7. Security Considerations
Subscriptions to dialog state can reveal sensitive information. For
this reason, Section 3.6 discusses authentication and authorization
of subscriptions, and provides guidelines on sensible authorization
policies. All implementations of this package MUST support the
digest authentication mechanism.
Since the data in notifications is sensitive as well, end-to-end SIP
encryption mechanisms using S/MIME MAY be used to protect it. User
agents that implement the dialog package SHOULD also implement SIP
over TLS [15] and the sips: scheme.
8. IANA Considerations
This document registers a new MIME type, application/dialog-info+xml;
a new XML namespace; and two new media feature parameters in the SIP
tree.
8.1. MIME Registration for application/dialog-info+xml Type
MIME media type name: application
MIME subtype name: dialog-info+xml
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8] and Section 7
of this specification.
Interoperability considerations: none.
Published specification: This document.
Applications that use this media type: This document type has been
used to support SIP applications such as call return and
auto-conference.
Additional Information:
Magic Number: None
File Extension: .xml
Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan
Rosenberg, <jdrosen@jdrosen.net>
Intended usage: COMMON
Author/Change controller: The IETF.
8.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info
This section registers a new XML namespace, per the guidelines in
[7].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:dialog-info.
Registrant Contact: 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>Dialog Information Namespace</title>
</head>
<body>
<h1>Namespace for Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:dialog-info</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4235.txt">
RFC4235</a>.</p>
</body>
</html>
END
8.3. Schema Registration
This specification registers a schema, per the guidelines in [7].
URI: urn:ietf:params:xml:schema:dialog-info
Registrant Contact: The IESG, <iesg@ietf.org>
XML: The XML can be found as the sole content of Section 4.4.
8.4. Media Feature Parameter Registration
This section registers two new media feature tags, per the procedures
defined in RFC 2506 [14]. The tags are placed into the sip tree,
which is defined in [10].
8.4.1. Media Feature Tag sip.byeless
Media feature tag name sip.byeless
ASN.1 Identifier 19
Summary of the media feature indicated by this tag: This feature tag
is a boolean flag. When set it indicates that the device is
incapable of terminating a session autonomously.
Values appropriate for use with this feature tag: Boolean.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application for
describing the capabilities of an application, such as an
announcement service, recording service, conference, or call center.
Examples of typical use: Call centers and media services.
Related standards or documents: RFC 4235
Security Considerations: This media feature tag can be used in ways
that affect application behaviors or may reveal private information.
For example, a conferencing or other application may decide to
terminate a call prematurely if this media feature tag is set.
Therefore, if an attacker can modify the values of this tag, they may
be able to affect the behavior of applications. As a result of this,
applications that utilize this media feature tag SHOULD provide a
means for ensuring its integrity. Similarly, this feature tag should
only be trusted as valid when it comes from the user or user agent
described by the tag. As a result, protocols for conveying this
feature tag SHOULD provide a mechanism for guaranteeing authenticity.
8.4.2. Media Feature Tag sip.rendering
Media feature tag name: sip.rendering
ASN.1 Identifier: 20
Summary of the media feature indicated by this tag: This feature tag
contains one of three string values indicating if the device is
rendering any media from the current session ("yes"), none of the
media from the current session ("no"), or if this status is not
known to the device ("unknown").
Values appropriate for use with this feature tag: String.
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application, for
describing the state of a device (such as a phone or PDA) during a
multimedia session.
Examples of typical use: Conferencing, telephone shared-line
emulation, and presence applications.
Related standards or documents: RFC 4235
Security Considerations: This media feature tag can be used in ways
that affect application behaviors or may reveal private
information. For example, a conferencing or other application may
decide to terminate a call prematurely if this media feature tag
is set to "no". Therefore, if an attacker can modify the values
of this tag, they may be able to affect the behavior of
applications. As a result of this, applications that utilize this
media feature tag SHOULD provide a means for ensuring its
integrity. Similarly, this feature tag should only be trusted as
valid when it comes from the user or user agent described by the
tag. As a result, protocols for conveying this feature tag SHOULD
provide a mechanism for guaranteeing authenticity.
9. Acknowledgements
The authors would like to thank Sean Olson for his comments.
10. References
10.1. Normative References
[1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[2] 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.
[3] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[4] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
FirstEdition REC-xml-20001006, October 2000.
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[8] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[11] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
Mechanism", RFC 3892, September 2004.
[12] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[13] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[14] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999.
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
10.2. Informative References
[16] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[17] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857, August
2004.
[18] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)", RFC
3842, August 2004.
[19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
2004.
[20] Sparks, R., "Session Initiation Protocol Call Control -
Transfer", Work in Progress, July 2005.
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
Rohan Mahy (editor)
SIP Edge LLC
EMail: rohan@ekabal.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 currently provided by the
Internet Society.