draft-ietf-sipping-dialog-package-03.txt   draft-ietf-sipping-dialog-package-04.txt 
SIPPING J. Rosenberg SIPPING J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: April 24, 2004 H. Schulzrinne Expires: August 13, 2004 H. Schulzrinne
Columbia University Columbia University
R. Mahy, Ed. R. Mahy, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
October 25, 2003 February 13, 2004
An INVITE Inititiated Dialog Event Package for the Session An INVITE Inititiated Dialog Event Package for the Session
Initiation Protocol (SIP) Initiation Protocol (SIP)
draft-ietf-sipping-dialog-package-03.txt draft-ietf-sipping-dialog-package-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2004. This Internet-Draft will expire on August 13, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document defines a dialog event package for the SIP Events This document defines a dialog event package for the SIP Events
architecture, along with a data format used in notifications for this architecture, along with a data format used in notifications for this
package. The dialog package allows users to subscribe to another package. The dialog package allows users to subscribe to another
user, an receive notifications about the changes in state of INVITE user, an receive notifications about the changes in state of INVITE
initiated dialogs that the user is involved in. initiated dialogs that the user is involved in.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Dialog Event Package . . . . . . . . . . . . . . . . . . 4 3. Dialog Event Package . . . . . . . . . . . . . . . . . . . 4
3.1 Event Package Name . . . . . . . . . . . . . . . . . . . 4 3.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 4
3.2 Event Package Parameters . . . . . . . . . . . . . . . . 4 3.2 Event Package Parameters . . . . . . . . . . . . . . . . . 4
3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 5 3.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5
3.4 Subscription Duration . . . . . . . . . . . . . . . . . 6 3.4 Subscription Duration . . . . . . . . . . . . . . . . . . 6
3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . 6 3.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6
3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . 6 3.6 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 6
3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . 7 3.7 Notifier Generation of NOTIFY Requests . . . . . . . . . . 7
3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . . 8 3.7.1 The Dialog State Machine . . . . . . . . . . . . . . . . . 8
3.7.2 Applying the state machine . . . . . . . . . . . . . . . 10 3.7.2 Applying the state machine . . . . . . . . . . . . . . . . 10
3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . 12 3.8 Subscriber Processing of NOTIFY Requests . . . . . . . . . 11
3.9 Handling of Forked Requests . . . . . . . . . . . . . . 12 3.9 Handling of Forked Requests . . . . . . . . . . . . . . . 12
3.10 Rate of Notifications . . . . . . . . . . . . . . . . . 12 3.10 Rate of Notifications . . . . . . . . . . . . . . . . . . 12
3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . 13 3.11 State Agents . . . . . . . . . . . . . . . . . . . . . . . 12
4. Dialog Information Format . . . . . . . . . . . . . . . 13 4. Dialog Information Format . . . . . . . . . . . . . . . . 12
4.1 Structure of Dialog Information . . . . . . . . . . . . 13 4.1 Structure of Dialog Information . . . . . . . . . . . . . 13
4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . . 14 4.1.1 Dialog Element . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2 State . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2 State . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.3 Duration . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.3 Duration . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.4 Replaces . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.4 Replaces . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.5 Referred-By . . . . . . . . . . . . . . . . . . . . . . 16 4.1.5 Referred-By . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.6 Route-Set . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.6 Local and Remote elements . . . . . . . . . . . . . . . . 15
4.1.6.1 Local and Remote elements . . . . . . . . . . . . . . . 16 4.1.6.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.6.1.1 Identity . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.6.2 Target . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.6.1.2 Target . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.6.3 Session Description . . . . . . . . . . . . . . . . . . . 16
4.1.6.1.3 Session Description . . . . . . . . . . . . . . . . . . 17 4.2 Sample Notification Body . . . . . . . . . . . . . . . . . 16
4.1.6.1.4 CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3 Constructing Coherent State . . . . . . . . . . . . . . . 17
4.2 Constructing Coherent State . . . . . . . . . . . . . . 17 5. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Schema . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4 Example . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1 Basic Example . . . . . . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . 25 6.2 Emulating a Shared-Line phone system . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . 25 6.3 Minimal Dialog Information with Privacy . . . . . . . . . 28
6.1 application/dialog-info+xml MIME Registration . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . 28
6.2 URN Sub-Namespace Registration for 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 29
urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . 26 8.1 application/dialog-info+xml MIME Registration . . . . . . 29
6.3 Schema Registration . . . . . . . . . . . . . . . . . . 26 8.2 URN Sub-Namespace Registration for
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 27 urn:ietf:params:xml:ns:dialog-info . . . . . . . . . . . . 30
Normative References . . . . . . . . . . . . . . . . . . 27 8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 30
Informative References . . . . . . . . . . . . . . . . . 28 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . 28 Normative References . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . 30 Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . 34
1. Introduction 1. Introduction
The SIP Events framework [1] defines general mechanisms for The SIP Events framework [1] defines general mechanisms for
subscription to, and notification of, events within SIP networks. It subscription to, and notification of, events within SIP networks. It
introduces the notion of a package, which is a specific introduces the notion of a package, which is a specific
"instantiation" of the events mechanism for a well-defined set of "instantiation" of the events mechanism for a well-defined set of
events. Packages have been defined for user presence [14], watcher events. Packages have been defined for user presence [14], watcher
information [15], and message waiting indicators [16], amongst information [15], and message waiting indicators [16], amongst
others. Here, we define an event package for INVITE initiated others. Here, we define an event package for INVITE initiated
skipping to change at page 4, line 46 skipping to change at page 4, line 46
parameter indicates if the subscriber would like to receive the parameter indicates if the subscriber would like to receive the
session descriptions associated with the subscribed dialog or session descriptions associated with the subscribed dialog or
dialogs. dialogs.
It is also possible to subscribe to the set of dialogs created as a It is also possible to subscribe to the set of dialogs created as a
result of a single INVITE sent by a UAC. In that case, the call-id result of a single INVITE sent by a UAC. In that case, the call-id
and to-tag MUST be present. The to-tag is matched against the local and to-tag MUST be present. The to-tag is matched against the local
tag, and the call-id is matched against the Call-ID. tag, and the call-id is matched against the Call-ID.
The ABNF for these parameters is shown below. It refers to many The ABNF for these parameters is shown below. It refers to many
constructions from the ABNF of RFC3261, such as word, callid, EQUAL, constructions from the ABNF of RFC3261, such as EQUAL, DQUOTE, and
DQUOTE, and token. token.
call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE ) call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE )
;; NOTE: any DQUOTEs inside callid MUST be escaped! ;; NOTE: any DQUOTEs inside callid MUST be escaped!
from-tag = "from-tag" EQUAL token from-tag = "from-tag" EQUAL token
to-tag = "to-tag" EQUAL token to-tag = "to-tag" EQUAL token
with-sessd = "include-session-description" with-sessd = "include-session-description"
Any callids which contain embedded double-quotes MUST escape those Any callids which contain embedded double-quotes MUST escape those
double-quotes using the backslash-quoting mechanism. Note that the double-quotes using the backslash-quoting mechanism. Note that the
call-id parameter may need to be expressed as a quoted string. This call-id parameter may need to be expressed as a quoted string. This
skipping to change at page 5, line 45 skipping to change at page 5, line 45
is suppressed for that subscriber. (The subscriber is already a is suppressed for that subscriber. (The subscriber is already a
party in the dialog directly, so these notifications are party in the dialog directly, so these notifications are
superfluous.) If no dialogs remain after supressing dialogs, the superfluous.) If no dialogs remain after supressing dialogs, the
entire notification to that subscriber is supressed and the entire notification to that subscriber is supressed and the
version number in the dialog-info element is not incremented for version number in the dialog-info element is not incremented for
that subscriber. Implicit filtering for one subscriber does not that subscriber. Implicit filtering for one subscriber does not
affect notifications to other subscribers. affect notifications to other subscribers.
o Notifications do not normally contain full state; rather, they o Notifications do not normally contain full state; rather, they
only indicate the state of the dialog whose state has changed. The only indicate the state of the dialog whose state has changed. The
exception is a NOTIFY sent in response to a SUBSCRIBE. These exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a
NOTIFYs contain the complete view of dialog state. NOTIFY that contains no dialog elements. These NOTIFYs contain the
complete view of dialog state.
o The notifications contain the identities of the participants in o The notifications contain the identities of the participants in
the dialog, and the dialog identifiers. Additional information, the dialog, the target URIs, and the dialog identifiers. Session
such as the route set, CSeq numbers, SDP information, and so on, descriptions are not included normally unless explicitly requested
are not included normally unless explicitly requested and/or and/or explicitly authorized.
explicitly authorized.
3.4 Subscription Duration 3.4 Subscription Duration
Dialog state changes fairly quickly; once established, a typical Dialog state changes fairly quickly; once established, a typical
phone call lasts a few minutes (this is different for other session phone call lasts a few minutes (this is different for other session
types, of course). However, the interval between new calls is types, of course). However, the interval between new calls is
typically infrequent. As such, we arbitrarily choose a default typically infrequent. As such, we arbitrarily choose a default
duration of one hour. Clients SHOULD specify an explicit duration. duration of one hour. Clients SHOULD specify an explicit duration.
There are two distinct use cases for dialog state. The first is when There are two distinct use cases for dialog state. The first is when
skipping to change at page 8, line 43 skipping to change at page 8, line 43
| | | | | | | | | | | | | |
+----------+ | | +----------+ | +----------+ | | +----------+ |
| | | | | | | | | | | |
| | | | | | | | | | | |
+<--C-----C--+ |1xx-tag | +<--C-----C--+ |1xx-tag |
| | | | | | | | | |
cancelled| | | V | cancelled| | | V |
rejected| | |1xx-tag +----------+ | rejected| | |1xx-tag +----------+ |
| | +------->| | |2xx | | +------->| | |2xx
| | | | | | | | | |
+<--C--------------| Early |-----C----+1xx-tag +<--C--------------| Early |-----C---+ 1xx-tag
| | replaced | | | | w. new tag | | replaced | | | | w/new tag
| | | |<----C----+ (new | | | |<----C---+ (new FSM
| | +----------+ | FSM | | +----------+ | instance
| | 2xx | | instance | | 2xx | | created)
| +----------------+ | | created) | +----------------+ | |
| | |2xx | | | |2xx |
| | | | | | | |
V V V | V V V |
+----------+ +----------+ | +----------+ +----------+ |
| | | | | | | | | |
| | | | | | | | | |
|Terminated|<-----------| Confirmed|<----+ |Terminated|<-----------| Confirmed|<----+
| | error | | | | error | |
| | timeout | | | | timeout | |
+----------+ replaced +----------+ +----------+ replaced +----------+
skipping to change at page 10, line 37 skipping to change at page 10, line 37
other transitions to the "terminated" state occur for the same other transitions to the "terminated" state occur for the same
reasons they do in the case of UAC. reasons they do in the case of UAC.
There should never be a transition from the "trying" state to the There should never be a transition from the "trying" state to the
"terminated" state with the event "cancelled", since the SIP "terminated" state with the event "cancelled", since the SIP
specification prohibits transmission of CANCEL until a provisional specification prohibits transmission of CANCEL until a provisional
response is received. However, this transition is defined in the response is received. However, this transition is defined in the
FSM just to unify the transitions from trying, proceeding, and FSM just to unify the transitions from trying, proceeding, and
early to the terminated state. early to the terminated state.
OPEN ISSUE: Since there is only one possible event to cause
transitions to the Proceeding (1xx-notag), Early (1xx-tag), and
Confirmed (2xx) states, the only events which provide any
additional information are the events for transitions to
Terminated (error, timeout, cancelled, local-bye, remote-bye and
replaced). Of these, timeout may not be relevant, since it is
often indistinguishable from "rejected" (for example, a 408) or
"error". Likewise it is unclear if there is any value in
distinguishing "local-bye" from "cancelled"; perhaps we should use
a single event, such as "local-hangup" instead.
3.7.2 Applying the state machine 3.7.2 Applying the state machine
The notifier MAY generate a NOTIFY request on any event transition of The notifier MAY generate a NOTIFY request on any event transition of
the FSM. Whether it does or not is policy dependent. However, some the FSM. Whether it does or not is policy dependent. However, some
general guidelines are provided. general guidelines are provided.
When the subscriber is unauthenticated, or is authenticated, but When the subscriber is unauthenticated, or is authenticated, but
represents a third party with no specific authorization policies, it represents a third party with no specific authorization policies, it
is RECOMMENDED that subscriptions to an individual dialog, or to a is RECOMMENDED that subscriptions to an individual dialog, or to a
specific set of dialogs, is forbidden. Only subscriptions to all specific set of dialogs, is forbidden. Only subscriptions to all
skipping to change at page 11, line 27 skipping to change at page 11, line 16
virtual FSM is in the "confirmed" state. If there are no dialogs at virtual FSM is in the "confirmed" state. If there are no dialogs at
the UA in the confirmed state, but there is at least one in the the UA in the confirmed state, but there is at least one in the
"early" state, the virtual FSM is in the "early" or "confirmed" "early" state, the virtual FSM is in the "early" or "confirmed"
state. If there are no dialogs in the confirmed or early states, but state. If there are no dialogs in the confirmed or early states, but
there is at least one in the "proceeding" state, the virtual FSM is there is at least one in the "proceeding" state, the virtual FSM is
in the "proceeding", "early" or "confirmed" state. If there are no in the "proceeding", "early" or "confirmed" state. If there are no
dialogs in the confirmed, early, or proceeding states, but there is dialogs in the confirmed, early, or proceeding states, but there is
at least one in the "trying" state, the virtual FSM is in the at least one in the "trying" state, the virtual FSM is in the
"trying", "proceeding", "early" or "confirmed" state. The choice "trying", "proceeding", "early" or "confirmed" state. The choice
about which state to use depends on whether the UA wishes to let about which state to use depends on whether the UA wishes to let
unknown users that their phone is ringing, as opposed to in an active unknown users know that their phone is ringing, as opposed to in an
call. active call.
It is RECOMMENDED that, in the absence of any preference, "confirmed" It is RECOMMENDED that, in the absence of any preference, "confirmed"
is used in all cases (as shown in the example in Section 3.6. is used in all cases (as shown in the example in Section 3.6.
Furthermore, it is RECOMMENDED that the notifications of changes in Furthermore, it is RECOMMENDED that the notifications of changes in
the virtual FSM machine not convey any information except the state the virtual FSM machine not convey any information except the state
of the FSM and its event transitions - no dialog identifiers (which of the FSM and its event transitions - no dialog identifiers (which
are ill-defined in this model in any case). The use of this virtual are ill-defined in this model in any case). The use of this virtual
FSM allows for minimal information to be conveyed. A subscriber FSM allows for minimal information to be conveyed. A subscriber
cannot know how many calls are in progress, or with whom, just that cannot know how many calls are in progress, or with whom, just that
there exists a call. This is the same information they would receive there exists a call. This is the same information they would receive
skipping to change at page 11, line 51 skipping to change at page 11, line 40
When the subscriber is authenticated, and has authenticated itself When the subscriber is authenticated, and has authenticated itself
with the same address-of-record that the UA itself uses, if no with the same address-of-record that the UA itself uses, if no
explicit authorization policy is defined, it is RECOMMENDED that all explicit authorization policy is defined, it is RECOMMENDED that all
state transitions on dialogs that have been subscribed to (which is state transitions on dialogs that have been subscribed to (which is
either all of them, if no dialog identifiers were present in the either all of them, if no dialog identifiers were present in the
Event header field, or a specific set of them identified by the Event Event header field, or a specific set of them identified by the Event
header field parameters) be reported, along with complete dialog IDs. header field parameters) be reported, along with complete dialog IDs.
The notifier MAY generate a NOTIFY request on any change in the The notifier MAY generate a NOTIFY request on any change in the
characteristics associated with the dialog. Since these include CSeq characteristics associated with the dialog. Since these include
numbers and SDP, receipt of re-INVITEs and UPDATE requests [3] which Contact URIs, Contact parameters and session descriptions, receipt of
modify this information MAY trigger notifications. re-INVITEs and UPDATE requests [3] which modify this information MAY
trigger notifications.
OPEN ISSUE: Is there a good reason to include CSeqs at all? Can
anyone come up with a use case? This seems to contradict the
"Rate of Notifications" section, and I can come up with some good
examples where this would be VERY BAD. For example, say Alice
sends an invitation to Bob, and then, on the same dialog,
subscribes to his dialog package, requesting CSeq information.
Every notification updates the CSeq which in turn generates
another notification, causing an infinite flood of messages.
3.8 Subscriber Processing of NOTIFY Requests 3.8 Subscriber Processing of NOTIFY Requests
The SIP Events framework expects packages to specify how a subscriber The SIP Events framework expects packages to specify how a subscriber
processes NOTIFY requests in any package specific ways, and in processes NOTIFY requests in any package specific ways, and in
particular, how it uses the NOTIFY requests to contruct a coherent particular, how it uses the NOTIFY requests to contruct a coherent
view of the state of the subscribed resource. view of the state of the subscribed resource.
Typically, the NOTIFY for the dialog package will only contain Typically, the NOTIFY for the dialog package will only contain
information about those dialogs whose state has changed. To construct information about those dialogs whose state has changed. To construct
a coherent view of the total state of all dialogs, a subscriber to a coherent view of the total state of all dialogs, a subscriber to
the dialog package will need to combine NOTIFYs received over time. the dialog package will need to combine NOTIFYs received over time.
Notifications within this package can convey partial information; Notifications within this package can convey partial information;
that is, they can indicate information about a subset of the state that is, they can indicate information about a subset of the state
associated with the subscription. This means that an explicit associated with the subscription. This means that an explicit
algorithm needs to be defined in order to construct coherent and algorithm needs to be defined in order to construct coherent and
consistent state. The details of this mechanism are specific to the consistent state. The details of this mechanism are specific to the
particular document type. See Section 4.2 for information on particular document type. See Section 4.3 for information on
constructing coherent information from an application/dialog-info+xml constructing coherent information from an application/dialog-info+xml
document. document.
3.9 Handling of Forked Requests 3.9 Handling of Forked Requests
Since dialog state is distributed across the UA for a particular Since dialog state is distributed across the UA for a particular
user, it is reasonable and useful for a SUBSCRIBE request for dialog user, it is reasonable and useful for a SUBSCRIBE request for dialog
state to fork, and reach multiple UA. state to fork, and reach multiple UA.
As a result, a forked SUBSCRIBE request for dialog state can install As a result, a forked SUBSCRIBE request for dialog state can install
multiple subscriptions. Subscribers to this package MUST be prepared multiple subscriptions. Subscribers to this package MUST be prepared
to install subscription state for each NOTIFY generated as a result to install subscription state for each NOTIFY generated as a result
of a single SUBSCRIBE. of a single SUBSCRIBE.
3.10 Rate of Notifications 3.10 Rate of Notifications
For reasons of congestion control, it is important that the rate of For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED notifications not become excessive. As a result, it is RECOMMENDED
that the server not generate notifications for a single subscriber at that the server not generate notifications for a single subscriber at
a rate faster than once every 5 seconds. a rate faster than once every 1 second.
Editors Note: This seems too slow to me. I think 1 second is
probably reasonable.
3.11 State Agents 3.11 State Agents
Dialog state is ideally maintained in the user agents in which the Dialog state is ideally maintained in the user agents in which the
dialog resides. Therefore, the elements that maintain the dialog are dialog resides. Therefore, the elements that maintain the dialog are
the ones best suited to handle subscriptions to it. However, in some the ones best suited to handle subscriptions to it. However, in some
cases, a network agent may also know the state of the dialogs held by cases, a network agent may also know the state of the dialogs held by
a user. As such, state agents MAY be used with this package. a user. As such, state agents MAY be used with this package.
4. Dialog Information Format 4. Dialog Information Format
skipping to change at page 14, line 13 skipping to change at page 13, line 34
(partial). (partial).
entity: This attribute contains a URI that identifies the user whose entity: This attribute contains a URI that identifies the user whose
dialog information is reported in the remainder of the document. dialog information is reported in the remainder of the document.
This user is referred to as the "observed user". This user is referred to as the "observed user".
The dialog-info element has a series of zero or more dialog The dialog-info element has a series of zero or more dialog
sub-elements. Each of those represents a specific dialog. sub-elements. Each of those represents a specific dialog.
<?xml version="1.0"?> <?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full" version="0" notify-state="full"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
</dialog-info> </dialog-info>
4.1.1 Dialog Element 4.1.1 Dialog Element
The dialog element reports information on a specific dialog or The dialog element reports information on a specific dialog or
"half-dialog". It has a single mandatory attribute, id. The id "half-dialog". It has single mandatory attribute: id. The id
attribute provides a single string that can be used as an identifier attribute provides a single string that can be used as an identifier
for this dialog or "half-dialog". This is a different identifier than for this dialog or "half-dialog". This is a different identifier than
the dialog ID defined in RFC 3261 [2], but related to it. the dialog ID defined in RFC 3261 [2], but related to it.
For a caller, the id is created when an INVITE request is sent. When For a caller, the id is created when an INVITE request is sent. When
a 1xx with a tag, or a 2xx is received, the dialog is formally a 1xx with a tag, or a 2xx is received, the dialog is formally
created. The id remains unchanged. However, if an additional 1xx or created. The id remains unchanged. However, if an additional 1xx or
2xx is received, resulting in the creation of another dialog (and 2xx is received, resulting in the creation of another dialog (and
resulting FSM), that dialog is allocated a new id. resulting FSM), that dialog is allocated a new id.
skipping to change at page 14, line 45 skipping to change at page 14, line 17
The id MUST be unique amongst all dialogs at a UA. The id MUST be unique amongst all dialogs at a UA.
There are a number of optional attributes which provide There are a number of optional attributes which provide
identification information about the dialog: identification information about the dialog:
call-id: This attribute is a string which represents the call-id call-id: This attribute is a string which represents the call-id
component of the dialog identifier. (Note that single and double component of the dialog identifier. (Note that single and double
quotes inside a call-id must be escaped using &quote; for " and quotes inside a call-id must be escaped using &quote; for " and
&apos; for ' .) &apos; for ' .)
OPEN ISSUE: Is it legal to include escaped quotes in XML
attributes?
local-tag: This attribute is a string which represents the local-tag local-tag: This attribute is a string which represents the local-tag
component of the dialog identifier. component of the dialog identifier.
remote-tag: This attribute is a string which represents the remote-tag: This attribute is a string which represents the
remote-tag component of the dialog identifier. The remote tag remote-tag component of the dialog identifier. The remote tag
attribute won't be present if there is only a "half-dialog", attribute won't be present if there is only a "half-dialog",
resulting from the generation of an INVITE for which no final resulting from the generation of an INVITE for which no final
responses or provisional responses with tags has been received. responses or provisional responses with tags has been received.
direction: This attribute is either initiator or recipient, and direction: This attribute is either initiator or recipient, and
skipping to change at page 16, line 17 skipping to change at page 15, line 32
4.1.5 Referred-By 4.1.5 Referred-By
The referred-by element is used to correlate a new dialog with a The referred-by element is used to correlate a new dialog with a
REFER [12] request which triggered it. The element is present in a REFER [12] request which triggered it. The element is present in a
dialog which was triggered by a REFER request which contained a dialog which was triggered by a REFER request which contained a
Referred-By [11] header and contains the (optional) display name Referred-By [11] header and contains the (optional) display name
attribute and the Referred-By URI as its value. attribute and the Referred-By URI as its value.
<referred-by display="Bob">sip:bob@example.com</referred-by> <referred-by display="Bob">sip:bob@example.com</referred-by>
4.1.6 Route-Set 4.1.6 Local and Remote elements
The route-set element conveys an ordered list of hop elements which
represents the complete route set of the dialog (not including the
local and remote target URIs) from the perspective of the notifier.
OPEN ISSUE: Does any one want/need this?
<route-set>
<hop>sip:proxy1.example.net;lr</hop>
<hop>sip:proxy2.example.com;lr</hop>
</route-set>
4.1.6.1 Local and Remote elements
The local and remote elements are sub-elements of the dialog element The local and remote elements are sub-elements of the dialog element
which contain information about the local and remote participants which contain information about the local and remote participants
respectively. They both have a number of optional sub-elements which respectively. They both have a number of optional sub-elements which
indicate the identity conveyed by the participant, the target URI, indicate the identity conveyed by the participant, the target URI,
the feature-tags of the target, and the session-description of the the feature-tags of the target, and the session-description of the
participant. participant.
4.1.6.1.1 Identity 4.1.6.1 Identity
The identity element indicates a local or remote URI, as defined in The identity element indicates a local or remote URI, as defined in
[2] as appropriate. It has an optional attribute, display-name, that [2] as appropriate. It has an optional attribute, display, that
contains the display name from the appropriate URI. contains the display name from the appropriate URI.
Note that multiple identities (for example a sip: URI and a tel: Note that multiple identities (for example a sip: URI and a tel:
URI) could be included if they all correspond to the participant. URI) could be included if they all correspond to the participant.
To avoid repeating identity information in each request, the
subscriber can assume that the identity URIs are the same as in
previous notifications if no identity elements are present in the
corresponding local or remote element. If any identity elements
are present in the local or remote part of a notification, the new
list of identity tags completely supersedes the old list in the
corresponding part.
<identity display="Anonymous">sip:anonymous@anonymous.invalid</identity> <identity display="Anonymous">sip:anonymous@anonymous.invalid</identity>
4.1.6.1.2 Target 4.1.6.2 Target
The target contains the local or remote target URI as constructed by The target contains the local or remote target URI as constructed by
the user agent for this dialog, as defined in RFC 3261 [2] in a "uri" the user agent for this dialog, as defined in RFC 3261 [2] in a "uri"
attribute. attribute.
It can contain a list of Contact header parameters in param It can contain a list of Contact header parameters in param
sub-elements (such as those defined in [10]. The param element sub-elements (such as those defined in [10]. The param element
contains a required pname attribute and an optional pval attribute contains a required pname attribute and an optional pval attribute
(some parameters merely exist and have no explicit value). The param (some parameters merely exist and have no explicit value). The param
element itself has no contents. element itself has no contents. To avoid repeating Contact
information in each request, the subscriber can assume that the
target URI and parameters are the same as in previous notifications
if no target element is present in the corresponding local or remote
element. If a target element is present in the local or remote part
of a notification, the new target tag and list of an parameter tags
completely supersedes the old target and parameter list in the
corresponding part.
<target uri="sip:alice@pc33.example.com"> <target uri="sip:alice@pc33.example.com">
<param pname="isfocus"/> <param pname="isfocus"/>
<param pname="class" pval="personal"/> <param pname="class" pval="personal"/>
</target> </target>
4.1.6.1.3 Session Description 4.1.6.3 Session Description
The session-description element contains the session description used The session-description element contains the session description used
by the observed user for its end of the dialog. This element should by the observed user for its end of the dialog. This element should
generally NOT be included in the notifications, unless explicitly generally NOT be included in the notifications, unless explicitly
requested by the subscriber. It has a single attribute, type, which requested by the subscriber. It has a single attribute, type, which
indicates the MIME media type of the session description. indicates the MIME media type of the session description. To avoid
repeating session description information in each request, the
4.1.6.1.4 CSeq subscriber can assume that the session description is the same as in
previous notifications if no session description element is present
in the corresponding local or remote element.
The cseq element contains the most recent value of the CSeq header 4.2 Sample Notification Body
used by the UA in an outgoing request on the dialog. This element
should generally NOT be included in the notifications, unless
explicitly requested by the subscriber. If no CSeq has yet been
defined, the value of the element is -1.
OPEN ISSUE: Is this really useful? <?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full">
<dialog id="123456">
<state>confirmed</state>
<duration>274</duration>
<local>
<identity display="Alice">sip:alice@example.com</identity>
<target uri="sip:alice@pc33.example.com">
<param pname="isfocus"/>
<param pname="class" pval="personal"/>
</target>
</local>
<remote>
<identity display="Bob">sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>
4.2 Constructing Coherent State 4.3 Constructing Coherent State
The dialog information subscriber maintains a table for the list of The dialog information subscriber maintains a table for the list of
dialogs. The table contains a row for each dialog. Each row is dialogs. The table contains a row for each dialog. Each row is
indexed by an ID, present in the "id" attribute of the "dialog" indexed by an ID, present in the "id" attribute of the "dialog"
element. The contents of each row contain the state of that dialog as element. The contents of each row contain the state of that dialog as
conveyed in the document. The table is also associated with a version conveyed in the document. The table is also associated with a version
number. The version number MUST be initialized with the value of the number. The version number MUST be initialized with the value of the
"version" attribute from the "dialog-info" element in the first "version" attribute from the "dialog-info" element in the first
document received. Each time a new document is received, the value of document received. Each time a new document is received, the value of
the local version number, and the "version" attribute in the new the local version number, and the "version" attribute in the new
skipping to change at page 18, line 30 skipping to change at page 18, line 15
element in the document, the subscriber checks to see whether a row element in the document, the subscriber checks to see whether a row
exists for that dialog. This check is done by comparing the ID in the exists for that dialog. This check is done by comparing the ID in the
"id" attribute of the "dialog" element with the ID associated with "id" attribute of the "dialog" element with the ID associated with
the row. If the dialog doesn't exist in the table, a row is added, the row. If the dialog doesn't exist in the table, a row is added,
and its state is set to the information from that "dialog" element. and its state is set to the information from that "dialog" element.
If the dialog does exist, its state is updated to be the information If the dialog does exist, its state is updated to be the information
from that "dialog" element. If a row is updated or created, such that from that "dialog" element. If a row is updated or created, such that
its state is now terminated, that entry MAY be removed from the table its state is now terminated, that entry MAY be removed from the table
at any time. at any time.
4.3 Schema 5. Schema
The following is the schema for the application/dialog-info+xml type: The following is the schema for the application/dialog-info+xml type:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:dialog-info" targetNamespace="urn:ietf:params:xml:ns:dialog-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:dialog-info" xmlns:tns="urn:ietf:params:xml:ns:dialog-info"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
skipping to change at page 21, line 46 skipping to change at page 21, line 31
<xs:maxInclusive value="699"/> <xs:maxInclusive value="699"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
4.4 Example 6. Examples
6.1 Basic Example
For example, if a UAC sends an INVITE that looks like, in part: For example, if a UAC sends an INVITE that looks like, in part:
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bKnashds8
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 314159 INVITE CSeq: 314159 INVITE
skipping to change at page 24, line 23 skipping to change at page 24, line 11
version="4" version="4"
state="partial" state="partial"
entity="sip:alice@example.com"> entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710" <dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" remote-tag="hh76a" local-tag="1928301774" remote-tag="hh76a"
direction="initiator"> direction="initiator">
<state event="cancelled">terminated</state> <state event="cancelled">terminated</state>
</dialog> </dialog>
</dialog-info> </dialog-info>
EDITORS NOTE: should provide another example with a richer 6.2 Emulating a Shared-Line phone system
notification
<?xml version="1.0" encoding="UTF-8"?> The following example shows how a SIP telephone user agent can
provide detailed state information and also emulate a shared-line
telephone system (the phone "lies" about having a dialog while it is
merely offhook).
Idle:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="0" state="full"
xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info" entity="sip:alice@example.com">
version="1" state="full"> </dialog-info>
<dialog id="123456">
<state>confirmed</state> Seized:
<duration>274</duration>
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8">
<state>trying</state>
</dialog>
</dialog-info>
Dialing:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="2" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774" direction="initiator">
<state>trying</state>
<local> <local>
<identity display="Alice">sip:alice@example.com</identity> <identity display="Alice Smith">
<target uri="sip:alice@pc33.example.com"> sip:alice@example.com
<param pname="isfocus"/> </identity>
<param pname="class" pval="personal"/> <target uri="sip:alice.gruu@srv3.example.com;grid0987"/>
</local>
<remote>
<identity>sip:bob@example.net</identity>
</remote>
</dialog>
</dialog-info>
Ringing:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="3" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state code="180">early</state>
<remote>
<target uri="sip:bobster@host2.example.net"/>
</remote>
</dialog>
</dialog-info>
Answered (by voicemail):
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="4" state="partial"
entity="sip:alice@example.com">
<dialog id="as7d900as8" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="07346y131" direction="initiator">
<state reason="cancelled">terminated</state>
</dialog>
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state code="200">confirmed</state>
<remote>
<target uri="sip:bob-is-not-here@vm.example.net">
<param pname="actor" pval="msg-taker"/>
<param pname="automaton"/>
</target> </target>
</remote>
</dialog>
</dialog-info>
Alice requests voicemail for Bob's attendant.
(Alice presses "0" in North America / "9" in Europe)
Voicemail completes a transfer with Cathy
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="5" state="partial"
entity="sip:alice@example.com">
<dialog id="zxcvbnm3" call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347" direction="initiator">
<state reason="replaced">terminated</state>
</dialog>
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="replaced">confirmed</state>
<replaces call-id="a84b4c76e66710"
local-tag="1928301774"
remote-tag="8736347"/>
<referred-by>
sip:bob-is-not-here@vm.example.net
</referred-by>
<local>
<target uri="sip:alice.gruu@srv3.example.com;grid1645"/>
</local> </local>
<remote> <remote>
<identity display="Bob">sip:bob@example.org</identity> <identity display="Cathy Jones">
<target uri="sip:bobster@phone21.example.org"/> sip:cjones@example.net
</identity>
<target uri="sip:line3@host3.example.net">
<param pname="actor" pval="attendant"/>
<param pname="automaton" pval="false"/>
</target>
</remote> </remote>
</dialog> </dialog>
</dialog-info> </dialog-info>
5. Security Considerations Alice and Cathy talk, Cathy adds Alice to a local conference.
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="6" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<remote>
<target uri="sip:confid-34579@host3.example.net">
<param pname="isfocus"/>
</target>
</remote>
</dialog>
</dialog-info>
Alice puts Cathy on hold
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="7" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state>confirmed</state>
<local>
<target uri="sip:alice.gruu@srv3.example.com;grid=1645">
<param pname="+activity" pval="noninteractive"/>
</target>
</local>
</dialog>
</dialog-info>
Cathy hangs up
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="8" state="partial"
entity="sip:alice@example.com">
<dialog id="sfhjsjk12" call-id="o34oii1"
local-tag="8903j4"
remote-tag="78cjkus" direction="receiver">
<state reason="remote-bye">terminated</state>
</dialog>
<dialog id="08hjh1345">
<state>trying</state>
</dialog>
</dialog-info>
Alice hangs up:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="9" state="full"
entity="sip:alice@example.com">
</dialog-info>
6.3 Minimal Dialog Information with Privacy
The following example shows the same user agent providing minimal
information to maintain privacy for services like automatic callback.
Onhook:
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="0" state="full"
entity="sip:alice@example.com">
</dialog-info>
Offhook: (implementation/policy choice for Alice to transition
to this "state" when "seized", when Trying, when Proceeding,
or when Confirmed.)
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
version="1" state="full"
entity="sip:alice@example.com">
<dialog id="1">
<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 Subscriptions to dialog state can reveal sensitive information. For
this reason, Section 3.6 discusses authentication and authorization this reason, Section 3.6 discusses authentication and authorization
of subscriptions, and provides guidelines on sensible authorization of subscriptions, and provides guidelines on sensible authorization
policies. All implementations of this package MUST support the digest policies. All implementations of this package MUST support the digest
authentication mechanism. authentication mechanism.
Since the data in notifications is sensitive as well, end-to-end SIP Since the data in notifications is sensitive as well, end-to-end SIP
encryption mechanisms using S/MIME MAY be used to protect it. encryption mechanisms using S/MIME MAY be used to protect it.
6. IANA Considerations 8. IANA Considerations
This document registers a new MIME type, application/dialog-info+xml This document registers a new MIME type, application/dialog-info+xml
and registers a new XML namespace. and registers a new XML namespace.
6.1 application/dialog-info+xml MIME Registration 8.1 application/dialog-info+xml MIME Registration
MIME media type name: application MIME media type name: application
MIME subtype name: dialog-info+xml MIME subtype name: dialog-info+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [8]. specified in RFC 3023 [8].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [8]. application/xml as specified in RFC 3023 [8].
Security considerations: See Section 10 of RFC 3023 [8] and Section 5 Security considerations: See Section 10 of RFC 3023 [8] and Section 7
of this specification. of this specification.
Interoperability considerations: none. Interoperability considerations: none.
Published specification: This document. Published specification: This document.
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to support SIP applications such as call return and used to support SIP applications such as call return and
auto-conference. auto-conference.
skipping to change at page 26, line 4 skipping to change at page 29, line 40
Applications which use this media type: This document type has been Applications which use this media type: This document type has been
used to support SIP applications such as call return and used to support SIP applications such as call return and
auto-conference. auto-conference.
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .dif or .xml File Extension: .dif or .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan Personal and email address for further information: Jonathan
Rosenberg, <jdrosen@jdrosen.net> Rosenberg, <jdrosen@jdrosen.net>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF. Author/Change controller: The IETF.
6.2 URN Sub-Namespace Registration for 8.2 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:dialog-info urn:ietf:params:xml:ns:dialog-info
This section registers a new XML namespace, as per the guidelines in This section registers a new XML namespace, as per the guidelines in
[7]. [7].
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:dialog-info. urn:ietf:params:xml:ns:dialog-info.
Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>, Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>,
Jonathan Rosenberg <jdrosen@jdrosen.net>. Jonathan Rosenberg <jdrosen@jdrosen.net>.
skipping to change at page 26, line 45 skipping to change at page 30, line 37
<title>Dialog Information Namespace</title> <title>Dialog Information Namespace</title>
</head </head
<body> <body>
<h1>Namespace for Dialog Information</h1> <h1>Namespace for Dialog Information</h1>
<h2>urn:ietf:params:xml:ns:dialog-info</h2> <h2>urn:ietf:params:xml:ns:dialog-info</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
6.3 Schema Registration 8.3 Schema Registration
This specification registers a schema, as per the guidelines in in This specification registers a schema, as per the guidelines in in
[7]. [7].
URI: please assign. URI: please assign.
Registrant Contact: IETF, SIPPING Working Group Registrant Contact: IETF, SIPPING Working Group
(sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). (sipping@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
XML: The XML can be found as the sole content of Section 4.3. XML: The XML can be found as the sole content of Section 5.
7. Acknowledgements 9. Acknowledgements
The authors would like to thank Sean Olson for his comments. The authors would like to thank Sean Olson for his comments.
Normative References Normative References
[1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
skipping to change at page 27, line 37 skipping to change at page 31, line 30
[4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, [4] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC REC-xml-20001006, October 2000. REC REC-xml-20001006, October 2000.
[5] Moats, R., "URN Syntax", RFC 2141, May 1997. [5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[7] Mealling, M., "The IETF XML Registry", [7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
draft-mealling-iana-xmlns-registry-04 (work in progress), July January 2004.
2002.
[8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC [8] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001. 3023, January 2001.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[10] Rosenberg, J., "Indicating User Agent Capabilities in the [10] Rosenberg, J., "Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-ietf-sip-callee-caps-00 (work in progress), June 2003. draft-ietf-sip-callee-caps-00 (work in progress), June 2003.
skipping to change at page 28, line 28 skipping to change at page 32, line 20
[15] Rosenberg, J., "A Watcher Information Event Template-Package [15] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", for the Session Initiation Protocol (SIP)",
draft-ietf-simple-winfo-package-05 (work in progress), January draft-ietf-simple-winfo-package-05 (work in progress), January
2003. 2003.
[16] Mahy, R., "A Message Summary and Message Waiting Indication [16] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)", Event Package for the Session Initiation Protocol (SIP)",
draft-ietf-sipping-mwi-02 (work in progress), March 2003. draft-ietf-sipping-mwi-02 (work in progress), March 2003.
[17] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-00 (work in progress), January
2004.
[18] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in
progress), February 2003.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@dynamicsoft.com
skipping to change at page 30, line 29 skipping to change at page 34, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/