One document matched: draft-burger-sipping-kpml-basic-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSpy v2005 sp1 U (http://www.xmlspy.com) by Eric Burger (W3C) -->
<!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by Martin C Dolly (AT&T) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!--
<?xml-stylesheet type="text/xsl" href="C:\Documents and Settings\eburger\My Documents\xml2rfc-1.26\rfc2629xslt\rfc2629.xslt"?>
-->
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc iprnotified="yes" ?>
<?rfc compact="yes" ?>
<?rfc strict="yes" ?>
<rfc category="std" docName="draft-burger-sipping-kpml-basic-00"
ipr="full3978">
<front>
<title abbrev="KPML-basic">A Baisc Profile of the Session Initiation
Protocol (SIP) Event Package for Key Press Stimulus (KPML)</title>
<author fullname="Eric Burger" initials="E." surname="Burger">
<organization>BEA Systems, Inc.</organization>
<address>
<postal>
<street></street>
</postal>
<email>eburger@standardstrack.com</email>
</address>
</author>
<date day="11" month="November" year="2007" />
<area>Transport</area>
<workgroup>SIPPING</workgroup>
<keyword>SIP</keyword>
<keyword>Media Services</keyword>
<keyword>KPML</keyword>
<keyword>DTMF</keyword>
<abstract>
<t>This document describes a profile of the SIP Event Package "kpml"
that enables simple monitoring of DTMF signals and uses XML documents
referred to as Key Press Markup Language (KPML). This profile assumes
devices of lesser capability that may have trouble parsing subscription
requests or producing generic XML documents. This is a profile of RFC
4730, KPML.</t>
</abstract>
<note title="Conventions used in this document">
<t><xref target="RFC2119">RFC2119</xref> provides the interpretations
for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in
this document.</t>
<t>The <xref
target="I-D.ietf-sipping-app-interaction-framework">Application
Interaction Framework document</xref> provides the interpretations for
the terms "User Device", "SIP Application", and "User Input". This
document uses the term "Application" and "Requesting Application"
interchangeably with "SIP Application".</t>
<t>Additionally, the Application Interaction Framework document
discusses User Device Proxies. A common instantiation of a User Device
Proxy is a Public Switched Telephone Network (PSTN) gateway. Because the
normative behavior of a presentation free User Interface is identical
for a presentation free SIP User Agent and a presentation free User
Device Proxy, this document uses "User Device" for both cases.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document describes a profile for the SIP Event Package "kpml"
that enables monitoring of key presses and utilizes XML documents
referred to as <xref target="RFC4730">Key Press Markup Language
(KPML)</xref>, RFC 4730.</t>
<t>A goal of KPML is to fit in an extremely small memory and processing
footprint. However, some believe that even with this lightweight goal,
the burden of parsing generic XML subscription requests and generating
arbitrary XML is too complex. This document provides a basic profile
that eliminates the requirement of a KPML server to parse arbitrary
subscription requests or generate arbitrary XML documents.</t>
<t>Of course, we strongly suggest implementing the full KPML protocol.
However, this profile provides the benefits of KPML, namely not sharing
the SIP dialog with the underlying SIP session. Note that by reporting
on a digit-by-digit basis, quite a lot of bandwidth and packets are
wasted. That said, with the exception of subscription establishment,
this mechanism uses virtually identical bandwidth, and identical packet
use, of INFO-based digit reporting schemes.</t>
<t>We considered having the invite, offering a kpml-basic event, to
automatically generate a subscription for the kpml-basic profile.
However, this is not workable, because the client making the request has
no way of correlating the automatically generated subscription to the
underlying SIP session. This is differnt from the <xref
target="RFC3515">REFER</xref> situation, where the new REFER dialog
establishes the subscription dialog.</t>
</section>
<section title="Protocol Overview">
<t>As a profile of KPML, the protocol operates identically to KPML.
However, by advertising the kpml-basic event package, as opposed to
kpml, the protocol described in this document superceeds the negotiation
of KPML. In particular, the server MUST ignore any subscription body and
substitute it with an expression similar to <xref
target="F.request"></xref>. This matches every key press and reports on
every key press.</t>
<t>The server can optimize reporting by using a template XML document,
substituting only the particular key press entered into the
template.</t>
<t>The client assumes a persistent subscription.</t>
</section>
<section title="Event Package Formal Definition">
<section title="Event Package Name">
<t>This document defines a SIP Event Package as defined in <xref
target="RFC3265">RFC 3265</xref>. The event-package token name for
this package is:</t>
<figure>
<artwork><![CDATA["kpml-basic"
]]></artwork>
</figure>
</section>
<section title="Event Package Parameters">
<t>This package defines three Event Package parameters: call-id,
remote-tag, and local-tag. These parameters MUST be present, to
identify the subscription dialog. The User Interface matches the
local-tag against the to tag, the remote-tag against the from tag, and
the call-id against the Call-ID.</t>
<t>call-id = "call-id" EQUAL ( token / DQUOTE callid DQUOTE
)<vspace /> ;; NOTE: any DQUOTEs inside callid MUST be
escaped!<vspace /> remote-tag = "remote-tag" EQUAL token<vspace />
local-tag = "local-tag" EQUAL token</t>
<t>If any call-ids contain embedded double-quotes, those double-quotes
MUST be escaped using the backslash-quoting mechanism. Note that the
call-id parameter may need to be expressed as a quoted string. This is
because the ABNF for the callid production and the word production,
which is used by callid (both from RFC 3261 [1]), allow some
characters (such as "@", "[", and ":") that are not allowed within a
token.</t>
</section>
<section title="SUBSCRIBE Bodies">
<t>Applications using this event package have an empty body in the
SUBSCRIBE request. The server MUST interpret this request as if it had
a document requesting every possible single key press pattern. A
sample of an application/kpml-request+xml document follows. Note if
there are other defined digits, the server includes them in the
pattern</t>
<figure anchor="F.request" title="Sample Default Request">
<preamble></preamble>
<artwork><![CDATA[<?xml version="1.0">
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-request kpml-request.xsd"
version="1.0">
<pattern>
<regex>[0123456789ABCDR*#]</regex>
</pattern>
</kpml-request>]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="Subscription Duration">
<t>The subscription lifetime should be longer than the expected call
time. Subscriptions to this event package MAY range from minutes to
weeks. Subscriptions in hours or days are more typical and are
RECOMMENDED. The default subscription duration for this event package
is 7200 seconds.</t>
<t>Subscribers MUST be able to handle the User Interface returning an
Expires value smaller than the requested value. Per <xref
target="RFC3265">RFC3265</xref>, the subscription duration is the
value returned by the Notifier in the 200 OK Expires header.</t>
</section>
<section title="NOTIFY Bodies">
<t>NOTIFY requests MUST contain well-formed
application/kpml-response+xml (KPML Response) bodies. The syntax of
this body type is formally described in RFC 4730.</t>
<t>The KPML server MAY use a template such as the following to send
its responses.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[?xml version="1.0" encoding="UTF-8"?>
<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:ietf:params:xml:ns:kpml-response kpml-response.xsd"
version="1.0"
code="200" text="OK"
digits="2"/>]]></artwork>
<postamble></postamble>
</figure>
<t>In the above example, the key pressed was a "2". Presumably, the
KPML server would fill in the exact key pressed instead of the 2.</t>
<t>It is very important to note the KPML client (the subscriber) MUST
be capable of parsing arbitrary XML documents. There is no guarantee
the server will use the above template. Since the server can use any
legal, well-formed, application/kpml-response+xml template. There is
no guarantee the server will use the above example as its
template.</t>
<t>Notifiers MAY send notifications with any format acceptable to the
subscriber (based on the subscriber inclusion of these formats in an
Accept header). A future extension MAY define other NOTIFY bodies. If
no "Accept" header is present in the SUBSCRIBE, the body type defined
in this document MUST be assumed.</t>
</section>
<section title="Subscriber generation of SUBSCRIBE requests">
<t>A kpml-basic request has no attached document.</t>
<t>Because of the potentially sensitive nature of the information
reported by KPML, subscribers SHOULD use sips: and MAY use S/MIME on
the content.</t>
<t>Subscribers MUST be prepared for the notifier to insist on
authentication of the subscription request. Subscribers MUST be
prepared for the notifier to insist on using a secure communication
channel.</t>
</section>
<section title="Notifier processing of SUBSCRIBE requests">
<t>The user information transported by KPML is potentially sensitive.
For example, it could include calling card or credit card numbers.
Thus the User Interface (notifier) MUST authenticate the requesting
party in some way before accepting the subscription.</t>
<t>User Interfaces MUST implement SIP Digest authentication as
required by <xref target="RFC3261">RFC3261</xref> and MUST implement
the sips: scheme and TLS.</t>
<t>Upon authenticating the requesting party, the User Interface
determines if the requesting party has authorization to monitor the
user's key presses. Determining authorization policies and procedures
is beyond the scope of this specification.</t>
<t>The User Interface returns a Contact URI that may have <xref
target="I-D.ietf-sip-gruu">GRUU</xref> properties in the Contact
header of a SIP INVITE, 1xx, or 2xx response.</t>
<t>Following the semantics of SUBSCRIBE, if the User Interface
receives a resubscription, the User Interface MUST terminate the
existing KPML request and replace it with the new request.</t>
<t>It is possible for the INVITE usage of the dialog to terminate
during key press collection. The cases enumerated here are explicit
subscription termination, automatic subscription termination, and
underlying (INVITE-initiated) dialog termination.</t>
<t>If a SUBSCRIBE request has an expires of zero (explicit SUBSCRIBE
termination) and there is buffered User Input, the User Interface MUST
generate the appropriate KPML report with the KPML status code of 200.
The SIP NOTIFY body terminates the subscription by setting the
subscription state to "terminated" and a reason of "timeout".</t>
<t>If the SUBSCRIBE request has an expires of zero or the expires
timer on the SUBSCRIBE-initiated dialog fires at the User Interface
(notifier), then the User Interface MUST issue a KPML report with the
KPML status code 487, Subscription Expired. This could be the null
string.</t>
<t>Per the mechanisms of <xref target="RFC3265">RFC3265</xref>, the
User Interface MUST terminate the SIP SUBSCRIBE dialog. The User
Interface does this via the SIP NOTIFY body transporting the final
report described in the preceding paragraph. In particular, the
subscription state will be "terminated" and a reason of "timeout".</t>
<t>Terminating the subscription when a dialog terminates ensures
reauthorization (if necessary) for attaching to subsequent
subscriptions.</t>
<t>If a SUBSCRIBE request references a dialog that is not present at
the User Interface, the User Interface MUST generate a KPML report
with the KPML status code 481, Dialog Not Found. The User Interface
terminates the subscription by setting the subscription state to
"terminated".</t>
</section>
<section title="Notifier generation of NOTIFY requests">
<t>The User Interface (notifier in SUBSCRIBE/NOTIFY parlance)
generates NOTIFY requests based on the requirements of <xref
target="RFC3265">RFC3265</xref>. Specifically, if a SUBSCRIBE request
is valid and authorized, it will result in an immediate NOTIFY.</t>
<t>The KPML payload distinguishes between an initial NOTIFY and a
NOTIFY informing of key presses. If there is no User Input buffered at
the time of the SUBSCRIBE (see below) or the buffered User Input does
not match the new KPML document, then the immediate NOTIFY MUST NOT
contain a KPML body. If User Interface has User Input buffered that
result in a match using the new KPML document, then the NOTIFY MUST
return the appropriate KPML document.</t>
<t>The NOTIFY in response to a SUBSCRIBE request has no KPML if there
are no matching buffered digits.</t>
<t>All subscriptions MUST be authenticated, particularly those that
match on buffered input.</t>
<t>KPML specifies the key press notification report format. The MIME
type for KPML reports is application/kpml-response+xml. The default
MIME type for the kpml event package is
application/kpml-response+xml.</t>
<t>If the requestor is not using a secure transport protocol such as
TLS for every hop (e.g., by using a sips: URI), the User Interface
SHOULD use S/MIME to protect the user information in responses.</t>
<t>Note that if the monitored (INVITE-initiated) dialog terminates,
the Notifier still MUST explicitly terminate the KPML subscriptions
monitoring that dialog.</t>
</section>
<section title="Subscriber processing of NOTIFY requests">
<t>If there is no KPML body, it means the SUBSCRIBE was successful.
This establishes the dialog if there is no buffered User Input to
report.</t>
<t>If there is a KPML document, and the KPML status code is 200, then
a match occurred.</t>
<t>If there is a KPML document, and the KPML status code is between
400 and 499, then an error occurred with User Input collection. The
most likely cause is a timeout condition.</t>
<t>If there is a KPML document, and the KPML status code is between
500 and 599, then an error occurred with the subscription. See RFC
4730 for more on the meaning of KPML status codes.</t>
<t>The subscriber MUST be mindful of the subscription state. The User
Interface may terminate the subscription at any time.</t>
</section>
<section title="Handling of Forked Requests">
<t>Forked requests are NOT ALLOWED for this event type. This can be
ensured if the Subscriptions to this event package are sent to SIP
URIs which have GRUU properties.</t>
</section>
<section title="Rate of notifications">
<t>The User Interface MUST NOT generate messages faster than 25
messages per second, or one message every 40 milliseconds. This is the
minimum time period for MF digit spills. Even 30-millisecond DTMF, as
one sometimes finds in Japan, has a 20-millisecond off time, resulting
in a 50-millisecond interdigit time.</t>
<t>The sustained rate of notification shall be no more than 100
Notifies per minute.</t>
<t>The User Interface MUST reliably deliver notifications. Because
there is no meaningful metric for throttling requests, the User
Interface SHOULD send NOTIFY messages over a congestion-controlled
transport, such as TCP. <list>
<t>Note that all SIP implementations are already required to
implement SIP over TCP.</t>
</list></t>
</section>
<section title="State Agents and Lists">
<t>KPML requests are sent to a specific SIP URI, which may have GRUU
properties, and attempt to monitor a specific stream that corresponds
with a specific target dialog. Consequently, implementers MUST NOT
define state agents for this event package nor allow subscriptions for
this event package to resource lists using the <xref
target="RFC4662">event list extension</xref>.</t>
</section>
<section title="Behavior of a Proxy Server">
<t>There are no additional requirements on a SIP Proxy, other than to
transparently forward the SUBSCRIBE and NOTIFY methods as required in
SIP.</t>
</section>
</section>
<section title="IANA Considerations">
<t>This document registers a new SIP Event Package.</t>
<section title="SIP Event Package Registration">
<t><list style="hanging">
<!-- hangIndent="30" -->
<t hangText="Package name:">kpml-basic</t>
<t hangText="Type:">package</t>
<t hangText="Contact:">Eric Burger,
<eburger@standardstrack.com></t>
<t hangText="Change Controller:">SIPPING Working Group delegated
from the IESG</t>
<t hangText="Published Specification:">RFCXXXX</t>
</list></t>
</section>
</section>
<section anchor="S.security" title="Security Considerations">
<t>The user information transported by KPML is potentially sensitive.
For example, it could include calling card or credit card numbers. This
potentially private information could be provided accidentally if the
notifier does not properly authenticate or authorize a subscription.
Similarly private information (such as a credit card number or calling
card number) could be revealed to an otherwise legitimate subscriber
(one operating an IVR) if digits buffered earlier in the session are
provided unintentionally to the new subscriber.</t>
<t>Likewise, an eavesdropper could view KPML digit information if it is
not encrypted, or an attacker could inject fraudulent notifications
unless the messages or the SIP path over which they travel are integrity
protected.</t>
<t>Therefore, User Interfaces MUST NOT downgrade their own security
policy. That is, if a User Interface policy is to restrict notifications
to authenticated and authorized subscribers over secure communications,
then the User Interface must not accept an unauthenticated, unauthorized
subscription over an insecure communication channel.</t>
<t>As an XML markup, all of the security considerations of <xref
target="RFC3023">RFC3023</xref> and <xref
target="RFC3406">RFC3406</xref> must be met. Pay particular attention to
the robustness requirements of parsing XML.</t>
<t>Key press information is potentially sensitive. For example, it can
represent credit card, calling card, or other personal information.
Hijacking sessions allow unauthorized entities access to this sensitive
information. Therefore, signaling SHOULD be secure, e.g., use of TLS and
sips: SHOULD be used. Moreover, the information itself is sensitive;
therefore the use of S/MIME or other appropriate mechanism SHOULD be
used.</t>
<t>Subscriptions MUST be authenticated in some manner. As required by
the core <xref target="RFC3261">SIP</xref> specification, all SIP
implementations MUST support digest authentication. In addition, User
Interfaces MUST implement support for the sips: scheme and SIP over TLS.
Subscribers MUST expect the User Interface to demand the use of an
authentication scheme. If the local policy of a User Interface is to use
authentication or secure communication channels, the User Interface MUST
reject subscription requests that do not meet that policy.</t>
<t>User Interfaces MUST begin buffering User Input upon receipt of an
authenticated and accepted subscription. This buffering is done on a per
subscription basis.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement
Levels</title>
<author initials="S." surname="Bradner">
<organization></organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="RFC3023">
<front>
<title>XML Media Types</title>
<author fullname="M. Murata" initials="M." surname="Murata">
<organization></organization>
</author>
<author fullname="S. St. Laurent" initials="S."
surname="St. Laurent">
<organization></organization>
</author>
<author fullname="D. Kohn" initials="D." surname="Kohn">
<organization></organization>
</author>
<date month="January" year="2001" />
</front>
<seriesInfo name="RFC" value="3023" />
<format octets="86011" target="ftp://ftp.isi.edu/in-notes/rfc3023.txt"
type="TXT" />
</reference>
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization></organization>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization></organization>
</author>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization></organization>
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization></organization>
</author>
<date month="June" year="2002" />
</front>
<seriesInfo name="RFC" value="3261" />
<format octets="647976"
target="ftp://ftp.isi.edu/in-notes/rfc3261.txt" type="TXT" />
</reference>
<reference anchor="RFC3265">
<front>
<title>Session Initiation Protocol (SIP)-Specific Event
Notification</title>
<author fullname="A.B. Roach" initials="A.B." surname="Roach">
<organization></organization>
</author>
<date month="June" year="2002" />
</front>
<seriesInfo name="RFC" value="3265" />
<format octets="89005" target="ftp://ftp.isi.edu/in-notes/rfc3265.txt"
type="TXT" />
</reference>
<reference anchor="RFC3406">
<front>
<title>Uniform Resource Names (URN) Namespace Definition
Mechanisms</title>
<author fullname="L. Daigle" initials="L." surname="Daigle">
<organization></organization>
</author>
<author fullname="D. van Gulik" initials="D." surname="van Gulik">
<organization></organization>
</author>
<author fullname="R. Iannella" initials="R." surname="Iannella">
<organization></organization>
</author>
<author fullname="P. Faltstrom" initials="P." surname="Faltstrom">
<organization></organization>
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="BCP" value="66" />
<seriesInfo name="RFC" value="3406" />
<format octets="43707" target="ftp://ftp.isi.edu/in-notes/rfc3406.txt"
type="TXT" />
</reference>
<reference anchor="RFC4730">
<front>
<title>A Session Initiation Protocol (SIP) Event Package for Key
Press Stimulus (KPML)</title>
<author fullname="E. Burger" initials="E." surname="Burger">
<organization></organization>
</author>
<author fullname="M. Dolly" initials="M." surname="Dolly">
<organization></organization>
</author>
<date month="November" year="2006" />
<abstract>
<t>This document describes a SIP Event Package "kpml" that enables
monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses
Extensible Markup Language (XML) documents referred to as Key
Press Markup Language (KPML). The kpml Event Package may be used
to support applications consistent with the principles defined in
the document titled "A Framework for Application Interaction in
the Session Initiation Protocol (SIP)". The event package uses
SUBSCRIBE messages and allows for XML documents that define and
describe filter specifications for capturing key presses (DTMF
Tones) entered at a presentation-free User Interface SIP User
Agent (UA). The event package uses NOTIFY messages and allows for
XML documents to report the captured key presses (DTMF tones),
consistent with the filter specifications, to an Application
Server. The scope of this package is for collecting supplemental
key presses or mid-call key presses (triggers). [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4730" />
<format octets="120186"
target="ftp://ftp.isi.edu/in-notes/rfc4730.txt" type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="I-D.ietf-sip-gruu">
<front>
<title>Obtaining and Using Globally Routable User Agent (UA) URIs
(GRUU) in the Session Initiation Protocol (SIP)</title>
<author fullname="Jonathan Rosenberg" initials="J"
surname="Rosenberg">
<organization></organization>
</author>
<date day="11" month="October" year="2007" />
<abstract>
<t>Several applications of the Session Initiation Protocol (SIP)
require a user agent (UA) to construct and distribute a URI that
can be used by anyone on the Internet to route a call to that
specific UA instance. A URI that routes to a specific UA instance
is called a Globally Routable UA URI (GRUU). This document
describes an extension to SIP for obtaining a GRUU from a
registrar and for communicating a GRUU to a peer within a
dialog.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sip-gruu-15" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-15.txt"
type="TXT" />
</reference>
<reference anchor="RFC3515">
<front>
<title>The Session Initiation Protocol (SIP) Refer Method</title>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization></organization>
</author>
<date month="April" year="2003" />
<abstract>
<t>This document defines the REFER method. This Session Initiation
Protocol (SIP) extension requests that the recipient REFER to a
resource provided in the request. It provides a mechanism allowing
the party sending the REFER to be notified of the outcome of the
referenced request. This can be used to enable many applications,
including call transfer. In addition to the REFER method, this
document defines the refer event package and the Refer-To request
header. [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3515" />
<format octets="47788" target="ftp://ftp.isi.edu/in-notes/rfc3515.txt"
type="TXT" />
</reference>
<reference anchor="I-D.ietf-sipping-app-interaction-framework">
<front>
<title>A Framework for Application Interaction in the Session
Initiation Protocol (SIP)</title>
<author fullname="Jonathan Rosenberg" initials="J"
surname="Rosenberg">
<organization></organization>
</author>
<date day="20" month="July" year="2005" />
<abstract>
<t>This document describes a framework for the interaction between
users and Session Initiation Protocol (SIP) based applications. By
interacting with applications, users can guide the way in which
they operate. The focus of this framework is stimulus signaling,
which allows a user agent to interact with an application without
knowledge of the semantics of that application. Stimulus signaling
can occur to a user interface running locally with the client, or
to a remote user interface, through media streams. Stimulus
signaling encompasses a wide range of mechanisms, ranging from
clicking on hyperlinks, to pressing buttons, to traditional Dual
Tone Multi Frequency (DTMF) input. In all cases, stimulus
signaling is supported through the use of markup languages, which
play a key role in this framework.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-sipping-app-interaction-framework-05" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-sipping-app-interaction-framework-05.txt"
type="TXT" />
</reference>
<reference anchor="RFC4662">
<front>
<title>A Session Initiation Protocol (SIP) Event Notification
Extension for Resource Lists</title>
<author fullname="A.B. Roach" initials="A.B." surname="Roach">
<organization></organization>
</author>
<author fullname="B. Campbell" initials="B." surname="Campbell">
<organization></organization>
</author>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<date month="August" year="2006" />
<abstract>
<t>This document presents an extension to the Session Initiation
Protocol (SIP)-Specific Event Notification mechanism for
subscribing to a homogeneous list of resources. Instead of sending
a SUBSCRIBE for each resource individually, the subscriber can
subscribe to an entire list and then receive notifications when
the state of any of the resources in the list changes. [STANDARDS
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4662" />
<format octets="82778" target="ftp://ftp.isi.edu/in-notes/rfc4662.txt"
type="TXT" />
</reference>
</references>
<section title="Contributors">
<t>This is my own invention, but we cannot forget the many people who
contributed to KPML, RFC 4730.</t>
</section>
<section title="Acknowledgements">
<t>Rohan Mahy asked for this one time too many.</t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 08:20:16 |