|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
## SIMPLEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 9, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
## SIMPLEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
## SIMPLEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the SIMPLE working group -- updated on March 21, 2007 --
is reported below.
|
|
|
|
The SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)
working group focuses on the application of the Session Initiation
Protocol (SIP, RFC 3261)
to the suite of services collectively known as
instant messaging and presence (IMP). The IETF has committed to
producing an interoperable standard for these services compliant to
the requirements for IM outlined in RFC 2779
(including the security
and privacy requirements there) and in the Common Profile for Instant
Messaging (CPIM) specification, developed within the IMPP working
group. As the most common services for which SIP is used share quite a
bit in common with IMP, the adaptation of SIP to IMP seems a natural
choice given the widespread support for (and relative maturity of) the
SIP standard.
This group has completed the majority of its primary goals and will
focus on the remaining tasks documented here and concluding. Any
proposed new work will require a recharter.
The primary remaining work of this group will be to complete:
|
|
| 1. |
The MSRP proposed standard mechanism for transporting sessions of
messages initiated using the SIP, compliant to the requirments of
RFC 2779, CPIM and BCP 41.
|
| 2. |
The XCAP framework for representing and carrying configuration and
policy information in SIMPLE systems.
|
| 3. |
A mechanism for representing partial changes (patches) to XML
documents and extensions to the SIMPLE publication and notification
mechanisms to convey these partial changes.
|
| 4. |
A mechanism for initiating and managing Instant Message group chat.
|
| 5. |
An annotated overview of the SIMPLE protocol definition documents.
|
|
Any SIP extensions proposed in the course of this development will,
after a last call process, be transferred to the SIP WG for
consideration as formal SIP extensions.
Any mechanisms created for managing Instant Message group chat are
intended to provide a bridge to the conferencing protocols that will
be defined in XCON. They will be limited in scope to address only
simple Instant Message chat with nicknames and will not attempt
to address complex conferencing concepts such as sidebars. Their
design must anticipate operating in conjunction with the conferencing
protocols XCON is working towards.
The working group will work within the framework for presence and IM
described in RFC 2778.
The extensions it defines must also be
compliant with the SIP processes for extensions. The group cannot
modify baseline SIP behavior or define a new version of SIP for IM and
presence. If the group determines that any capabilities requiring an
extension to SIP are needed, the group will seek to define such
extensions within the SIP working group, and then use them here.
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
## SIMPLEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
## SIMPLEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
simple-imdn-07
IESG Evaluation::
Revised ID Needed
Apr 2, 2008
(37 p.)
[pdf(2)]
[html]
|
E. Burger
H. Khartabil |
| Instant Message Disposition Notification |
Instant Messaging (IM) refers to the transfer of messages between
users in real-time. This document provides a mechanism whereby
endpoints can request Instant Message Disposition Notifications
(IMDN), including delivery, processing, and read notifications, for
page-mode instant messages.
The Common Profile for Instant Messaging (CPIM) data format specified
in RFC 3862 is extended with new header fields that enable endpoints
to request IMDNs. A new message format is also defined to convey
IMDNs.
This document also describes how SIP entities behave using this
extension.
This specification requests the registration of a new MIME type:
application/imdn+xml.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
simple-partial-
notify-10
IESG Evaluation::
AD Follow up
Jan 21, 2008
(16 p.)
[pdf(2)]
[html]
|
M. Lonnfors
J. Costa-Requena
E. Leppanen
H. Khartabil |
|
SIP extension for Partial Notification of Presence Information |
|
By default, presence delivered using the Presence Event Package for
the Session Initiation Protocol (SIP) is represented in the Presence
Information Data Format (PIDF). A PIDF document contains a set of
elements, each representing a different aspect of the presence being
reported. When any subset of the elements change, even just a single
element, a new document containing the full set of elements is
delivered. This memo defines an extension allowing delivery of only
the presence data that has actually changed.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
simple-partial-
pidf-format-10
IESG Evaluation::
AD Follow up
Nov 19, 2007
(17 p.)
[pdf(2)]
[html]
|
M. Lonnfors
E. Leppanen
H. Khartabil
J. Urpalainen |
|
PIDF Extension for Partial Presence |
The Presence Information Document Format (PIDF) specifies the
baseline XML based format for describing presence information. One
of the characteristic of the PIDF is that the document always needs
to carry all presence information available for the presentity. In
some environments where low bandwidth and high latency links can
exist it is often beneficial to limit the amount of transported
information over the network. This document introduces a new MIME
type which enables transporting of either only the changed parts or
the full PIDF based presence information.
This specification requests the registration of a new MIME type:
application/pidf-diff+xml.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
simple-partial-
publish-07
IESG Evaluation::
AD Follow up
Feb 19, 2008
(16 p.)
[pdf(2)]
[html]
|
A. Niemi
M. Lonnfors
E. Leppanen |
| Publication of Partial Presence Information |
|
The Session Initiation Protocol (SIP) Extension for Event State
Publication describes a mechanism with which a presence user agent is
able to publish presence information to a presence agent. Using the
Presence Information Data Format (PIDF), each presence publication
contains full state, regardless of how much of that information has
actually changed since the previous update. As a consequence,
updating a sizeable presence document with small changes bears a
considerable overhead and is therefore inefficient. Especially with
low bandwidth and high latency links, this can constitue a
considerable burden to the system. This memo defines a solution that
aids in reducing the impact of those constraints and increases
transport efficiency by introducing a mechanism that allows for
publication of partial presence information.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
simple-prescaps-
ext-09
IESG Evaluation::
AD Followup
Mar 18, 2008
(30 p.)
[pdf(2)]
[html]
|
M. Lonnfors
K. Kiss |
|
SIP User Agent Capability Extension to PIDF |
Presence Information Data Format (PIDF) defines a common presence
data format for Common Profile for Presence (CPP) compliant Presence
protocols. This memo defines an extension to represent SIP User
Agent capabilities in the Presence Information Document Format (PIDF)
compliant presence documents.
This specification requests the following registration at the IANA:
urn:ietf:params:xml:ns:pidf:caps XML namespace.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
simple-xcap-diff-09
AD is watching
May 5, 2008
(16 p.)
[pdf(2)]
[html]
|
J. Rosenberg
J. Urpalainen |
|
An XML Document Format for Indicating a Change in XCAP Resources |
This specification defines a document format that can be used to
indicate that a change has occurred in a document managed by the
Extensible Markup Language (XML) Configuration Access Protocol
(XCAP). This format indicates the document that has changed and its
former and new entity tags. It also can indicate the specific change
that was made in the document, using an XML patch format. This
format allows also indications of element and attribute content of an
XML document. XCAP diff documents can be delivered to clients using
a number of means, including a Session Initiation Protocol (SIP)
event package.
This specification requests the registration of a new MIME type:
application/xcap-diff+xml.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
simple-xml-
patch-ops-04
IESG Evaluation::
AD Follow up
Nov 16, 2007
(42 p.)
[pdf(2)]
[html]
|
J. Urpalainen |
|
An XML Patch
Operations Framework Utilizing XML Path Language (XPath) Selectors |
|
Extensible Markup Language (XML) documents are widely used as
containers for the exchange and storage of arbitrary data in today's
systems. In order to send changes to an XML document, an entire copy
of the new version must be sent, unless there is a means of
indicating only the portions that have changed. This document
describes an XML patch framework utilizing XML Path language (XPath)
selectors. These selector values and updated new data content
constitute the basis of patch operations described in this document.
In addition to them, with basic <add>, <replace> and <remove>
directives a set of patches can then be applied to update an existing
XML document.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
## SIMPLEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
simple-interdomain-
scaling-analysis-04
ID Exists
Feb 25, 2008
(60 p.)
[pdf(2)]
[html]
|
A. Houri
E. Aoki
S. Parameswar
T. Rang
V. Singh
H. Schulzrinne |
|
Presence Interdomain Scaling Analysis for SIP/SIMPLE |
|
The document analyzes the traffic that is generated due to presence
subscriptions between domains. It is shown that the amount of
traffic can be extremely big. In addition to the very large traffic
the document also analyzes the affects of a large presence system on
the memory footprint and the CPU load. Current approved and in work
optimizations to the SIP protocol are analyzed with the possible
impact on the load. Separate documents contain the requirements for
optimizations and suggestions for new optimizations.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
simple-intradomain-
federation-00
ID Exists
Feb 21, 2008
(38 p.)
[pdf(2)]
[html]
|
J. Rosenberg
A. Houri |
|
Models for Intra-Domain Presence Federation |
|
Presence federation involves the sharing of presence information
across multiple presence systems. Most often, presence federation is
assumed to be between different organizations, such as between two
enterprises or between and enterprise and a service provider.
However, federation can occur within a single organization or domain.
This can be the result of a multi-vendor network, or a consequence of
a large organization that requires partitioning. This document
examines different use cases and models for intra-domain federation.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
simple-view-
sharing-00
ID Exists
Feb 21, 2008
(30 p.)
[pdf(2)]
[html]
|
J. Rosenberg
S. Donovan
K. McMurry |
|
Optimizing Federated Presence with View Sharing |
|
Presence federation refers to the exchange of presence information
between systems. One of the primary challenges in presence
federation is scale. With a large number of watchers in one domain
obtaining presence for many presentities in another, the amount of
notification traffic is large. This document describes an extension
to the Session Initiation Protocol (SIP) event framework, called view
sharing. View sharing can substantially reduce the amount of
traffic, but requires a certain level of trust between domains. View
sharing allows the amount of presence traffic between domains to
achieve the theoretical lower bound on information exchange in any
presence system.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
## SIMPLEwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
| | |
garcia-simple-
indirect-presence-
publish-00
ID Exists
Feb 18, 2008
(12 p.)
[pdf(2)]
[html]
|
M. Garcia-Martin
H. Tschofenig
H. Schulzrinne |
|
Indirect Presence Publication with SIP |
SIP is extended by the SIP-events framework to provide subscriptions
and notifications of SIP events. One example of such event
notification mechanism is 'presence' and this presence information is
carried in Presence Information Data Format (PIDF) documents.
The SIP PUBLISH method specified in RFC 3903 carrying a PIDF document
is typically used when presentities publish their own presence since
these presentities are typically the source of the information.
However, there are cases when the presentity is not the direct source
of the presence information. One such example is location
information where the end host may obtain a reference to location
information as opposed to as a value. The endpoint is typically not
interested in knowing its own location information, but other users
or entities might be. So, if the endpoint gets its own location
information with a reference and wants to publish it embedded in its
presence information, it first needs to de-reference it for getting a
value, and then it can embed that value in its presence information.
While this is certainly a correct sequence, it adds a round-trip to
the presence publication, in addition to a demand processing power
and network bandwidth consumption.
There is a need for a mechanism that the presentity can use to
publish indirect references, such as indirect location references.
This document discusses a few variants that may be used to provide
this functionality.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
hellstrom-simple-
text-transmission-00
ID Exists
Sep 25, 2007
(10 p.)
[pdf(2)]
[html]
|
G. Hellstrom
P. Jones
G. Vanderheiden |
|
Coding and transmission of text in real-time and en-bloc mode based on MSRP |
|
This memo describes conventions for exchange and presentation of text
in SIP sessions through the Message Session Relay Protocol MSRP. It
covers two different methods for taking the initiative to transmit.
These methods are timer initiated real-time text and user requested
en-bloc transmission in Messaging. The document gives specific
guidance on handling of text presentation and presentation control of
conversational sessions. It specifies how the capability to conduct
MSRP sessions with real-time text is declared so that session
negotiation can make decisions on what transport protocol to use and
how to route the calls to get the desired support for text
communication.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
rosen-simple-
watcher-count-00
ID Exists
Feb 18, 2008
(19 p.)
[pdf(2)]
[html]
|
B. Rosen
S. Loreto
K. Kiss |
|
Optimizing Notifications for Presence Network Agents |
In large presence systems deployed in multiservice networks, presence
information is often known by the network in addition to, or instead
of the presentity's devices (endpoints). Examples of such
information include location and availability for various kinds of
session establishment. Even if devices know the information, the
network often has more bandwidth and better scale to keep the
presence server up to date. A Presence Network Agent (PNA) can
publish presence information to a Presence Server(PS). When done
large scale, the basic publish operation can be inefficient. When
the network has millions of subscribers, only some of which have
watchers, blind Publish operations are unecessary. WINFO can be used
to determine watchers, but the efficiency of maintaining WINFO per
subscriber, and the size of the messages involved, make that solution
unattractive. The PNA would prefer to have the Presence Server
simply tell it when there was at least one watcher.
This document describes an XML document stored on the PS by which the
PNA maintains a list of subscribers it can provide presence for as a
SIP event package that tells the PNA when the number of watchers for
a presentity on the list (or a specific presence element for a
presentity) goes from 0 to at least 1 or from 1 to 0.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
schulzrinne-simple-
composition-02
ID Exists (expired)
Jun 25, 2006
(21 p.)
[pdf(2)]
[html]
|
H. Schulzrinne
R. Shacham
W. Kellerer
S. Thakolsri |
|
Composing Presence Information |
|
Composition creates a presence document from multiple components
published by one or more sources. This document identifies sources
of information that a compositor might draw on presence composition
and describes steps for composition. The composing function can be
complex, so we intentionally restrict the discussion to cases that
are likely to be common across many users of presence systems. We
present an XML format for specifying a composition policy, based on
our discussion.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
