One document matched: draft-ietf-simple-simple-01.txt
Differences from draft-ietf-simple-simple-00.txt
SIMPLE J. Rosenberg
Internet-Draft Cisco
Intended status: Informational November 13, 2007
Expires: May 16, 2008
SIMPLE made Simple: An Overview of the IETF Specifications for Instant
Messaging and Presence using the Session Initiation Protocol (SIP)
draft-ietf-simple-simple-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 16, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The IETF has produced many specifications related to Presence and
Instant Messaging with the Session Initiation Protocol (SIP).
Collectively, these specifications are known as SIMPLE - SIP for
Instant Messaging and Presence Leveraging Extensions. This document
serves as a guide to the SIMPLE suite of specifications. It breaks
them up into categories and explains what each is for and how they
relate to each other.
Rosenberg Expires May 16, 2008 [Page 1]
Internet-Draft Simple Made Simple November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Core Protocol Machinery . . . . . . . . . . . . . . . . . 4
2.2. Presence Documents . . . . . . . . . . . . . . . . . . . . 5
2.3. Privacy and Policy . . . . . . . . . . . . . . . . . . . . 6
2.4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Optimizations . . . . . . . . . . . . . . . . . . . . . . 8
3. Instant Messaging . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Page Mode . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Session Mode . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. IM Chat Rooms . . . . . . . . . . . . . . . . . . . . . . 10
3.4. IM Features . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Informative References . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Rosenberg Expires May 16, 2008 [Page 2]
Internet-Draft Simple Made Simple November 2007
1. Introduction
The IETF has produced many specifications related to Presence and
Instant Messaging with the Session Initiation Protocol (SIP)
[RFC3261]. Collectively, these specifications are known as SIMPLE -
SIP for Instant Messaging and Presence Leveraging Extensions. These
specifications cover topics ranging from protocols for subscription
and publication, to presence document formats, to protocols for
managing privacy preferences. The large number of specifications can
make it hard to figure out exactly what exactly SIMPLE is, what
specifications cover it, what functionality it provides, and how
these specifications relate to each other.
This document serves to address this problem. It provides an
enumeration of the protocols which make up the SIMPLE suite of
specifications from IETF. It categorizes them into related areas of
functionality, and briefly explains the purpose of each and how the
specifications relate to each other. Each specification also
includes a letter that designates its category in the standards track
[RFC2026]. These values are:
S: Standards Track (Proposed Standard, Draft Standard, or Standard)
E: Experimental
B: Best Current Practice
I: Informational
2. Presence
SIMPLE provides for both presence and IM capabilities. Though both
of these fit underneath the broad SIMPLE umbrella, they are well
separated from each other and are supported by different sets of
specifications. That is a key part of the SIMPLE story; presence is
much broader than just IM, and it enables communications using voice
and video along with IM.
The SIMPLE presence specifications can be broken up into:
o The core protocol machinery, which provides the actual SIP
extensions for subscriptions, notifications and publications
o Presence documents, which are XML documents that provide for rich
presence and are carried by the core protocol machinery
Rosenberg Expires May 16, 2008 [Page 3]
Internet-Draft Simple Made Simple November 2007
o Privacy and policy, which are documents for expressing privacy
preferences about how those presence documents are to be shown (or
not shown) to other users
o Provisioning, which describes how users manage their privacy
policies, buddy lists and other pieces of information required for
SIMPLE presence to work
o Optimizations, which are improvements in the core protocol
machinery that were defined to improve the performance of SIMPLE,
particularly on wireless links
2.1. Core Protocol Machinery
RFC 3265, SIP-Specific Event Notification (S): RFC 3265 [RFC3265]
defines the SUBSCRIBE and NOTIFY methods for SIP, forming the core
of the SIP event notification framework. To actually use the
framework, extensions need to be defined for specific event
packages. Presence is defined as an event package within this
framework. Packages exist for other, non-presence related
functions, such as message waiting indicators and dialog state
changes.
RFC 3856, A Presence Event Package for SIP (S): RFC 3856 [RFC3856]
defines an event package for indicating user presence through SIP.
Through this package, a SIP user agent can ask to be notified of
the presence state of a presentity (presence entity). The content
of the NOTIFY messages in this package are presence documents,
discussed in Section 2.2
RFC 4662, A Session Initiation Protocol (SIP) Event Notification
Extension for Resource Lists (S): RFC 4662 [RFC4662] defines an
extension to RFC 3265 that allows a client to subscribe to a list
of resources using a single subscription. The server, called a
Resource List Server (RLS) will "expand" the subscription and
subscribe to each individual member of the list. Its primary
usage with presence is to allow subscriptions to "buddy lists".
Without RFC 4662, a UA would need to subscribe to each presentity
individually. With RFC 4662, they can have a single subscription
to all buddies. A user can manage the entries in their buddy list
using the provisioning mechanisms in Section 2.4.
RFC 3903, SIP Extension for Event State Publication (S): RFC 3903
[RFC3903] defines the PUBLISH method. With this method, a user
agent can publish its current state for any event package,
including the presence event package. Once an agent publishes its
presence state, the presence server would send notifications of
this state change using RFC 3856.
Rosenberg Expires May 16, 2008 [Page 4]
Internet-Draft Simple Made Simple November 2007
2.2. Presence Documents
Once a user has generated a subscription to presence using the core
protocol machinery, they will receive notifications (SIP NOTIFY
requests) which contain presence information. That presence
information is in the form of an XML presence document. Several
specifications have been defined to describe this document format,
focusing on rich, multimedia presence.
RFC 3863, Presence Information Data Format (S): RFC 3863 [RFC3863]
defines the baseline XML format for a presence document. It
defines the concept of a tuple as representing a basic
communication modality, and defines a simple status for it (open
or closed).
RFC 4479, A Data Model for Presence (S): RFC 4479 [RFC4479] extends
the basic model in RFC 3863. It introduces the concepts of
devices and person status, and explains how these relate to each
other. It describes how presence documents are used to represent
states in communications systems in a consistent fashion. More
than RFC 3863, it defines what a presence document is and what it
means.
RFC 4480, RPID: Rich Presence Extensions to PIDF (S): RFC 4480
[RFC4480] adds many more attributes to the presence document
schema, building upon the model in RFC 4479. It allows for
indications of activities, moods, places and place types, icons,
and indications of whether a user is idle or not.
RFC 4481, Timed Presence Extensions to the Presence Information Data
Format (PIDF) to Indicate Status Information for Past and Future Time
Intervals (S): RFC 4481 [RFC4481] adds additional attributes to the
presence document schema, again building upon the model in RFC
4479. It allows documents to indicate status for the future or
the past. For example, a user can indicate that they will be
unavailable for voice communications from 2pm to 3pm, due to a
meeting.
RFC 4482, CIPID: Contact Information for the Presence Information
Data Format (S): RFC 4482 [RFC4482] adds attributes to the presence
document schema for contact information, such as a vCard, display
name, homepage, icon, or sound (such as the pronunciation of their
name).
RFC XXXX, Session Initiation Protocol (SIP) User Agent Capability
Extension to Presence Information Data Format (PIDF) (S): RFC XXXX
[I-D.ietf-simple-prescaps-ext] adds even more attributes to the
presence document schema, this time to allow indication of
Rosenberg Expires May 16, 2008 [Page 5]
Internet-Draft Simple Made Simple November 2007
capabilities for the user agent. For example, the extensions can
indicate whether a UA supports audio and video, what SIP methods
it supports, and so on.
2.3. Privacy and Policy
The rich presence capabilities defined by the specifications in
Section 2.2 introduces a strong need for privacy preferences. Users
must be able to approve or deny subscriptions to their presence, and
indicate what information such watchers can see. In SIMPLE, this is
accomplished through policy documents, uploaded to the presence
server using the provisioning mechanisms in Section 2.4.
RFC 4745, Common Policy: A Document Format for Expressing Privacy
Preferences (S): RFC 4745 [RFC4745] defines a general XML framework
for expressing privacy preferences for both geolocation
information and presence information. It introduces the concepts
of conditions, actions and transformations that are applied to
privacy-sensitive data. The common policy framework provides
privacy-safety, a property by which network error or version
incompatibilities can never cause more information to be revealed
to a watcher than the user would otherwise desire.
RFC XXXX, Presence Authorization Rules (S): RFC XXXX
[I-D.ietf-simple-presence-rules] uses the framework of RFC 4745 to
define a policy document format for describing presence privacy
policies. Besides basic yes/no approvals, this format allows a
user to control what kind of information a watcher is allowed to
see.
RFC 3857, A Watcher Information Event Template Package for SIP (S):
RFC 3857 [RFC3857], also known as watcherinfo, provides a
mechanism for a user agent to find out what subscriptions are in
place for a particular event package. Though it was defined to be
used for any event package, it has particular applicability for
presence. It is used to provide reactive authorization. With
reactive authorization, a user gets alerted if someone tries to
subscribe to their presence, so that they may provide an
authorization decision. Watcherinfo is used to provide the alert
that someone has subscribed to a user's presence.
RFC 3858, An Extensible Markup Language (XML) Based Format for
Watcher Information (S): RFC 3858 [RFC3858] is the companion to RFC
3857. It specifies the XML format of watcherinfo that is carried
in notifications for the event template package in RFC 3857.
Rosenberg Expires May 16, 2008 [Page 6]
Internet-Draft Simple Made Simple November 2007
2.4. Provisioning
Proper operation of a SIMPLE presence system requires that several
pieces of data are correctly managed by the users and provisioned
into the system. These include buddy lists (used by the resource
list subscription mechanism in RFC 4662) and privacy policies (such
as those described by the XML format in
[I-D.ietf-simple-presence-rules]).
In SIMPLE, management of this data is handled by the XML
Configuration Access Protocol (XCAP) [RFC4825]. XCAP is used by the
user agent to manipulate buddy lists, privacy policy, and other data
that is represented by XML documents stored on a server.
RFC 4825, The Extensible Markup Language (XML) Configuration Access
Protocol (XCAP) (S): RFC4825 [RFC4825] specifies XCAP. XCAP is a
usage of HTTP that allows a user agent to manipulate the contents
of XML documents stored on a server. It can be used to manipulate
any kind of XML, and the protocol itself is independent of the
particular schema of the data it is modifying. XML schemas have
been defined for buddy lists, privacy policies and offline
presence status, allowing all of those to be managed by a user
with XCAP.
RFC XXXX, Extensions to the Session Initiation Protocol (SIP) User
Agent Profile Delivery Change Notification Event Package for the
Extensible Markup Language Language Configuration Access Protocol
(XCAP) (S): RFC XXXX [I-D.ietf-sip-xcap-config] defines an extension
to the SIP user agent configuration profile, allowing a user agent
to learn about changes in its documents on an XCAP server. With
this mechanism, there can be a change made by someone else to a
buddy list or privacy policy document, and a UA will find out that
a new version is available.
RFC XXXX, An Extensible Markup Language (XML) Document Format for
Indicating A Change in XML Configuration Access Protocol (XCAP)
Resources (S): RFC XXXX [I-D.ietf-simple-xcap-diff] defines an XML
format for indicating changes in XCAP documents. It makes use of
an XML diff format defined in [I-D.ietf-simple-xml-patch-ops]. It
is used in conjunction with [I-D.ietf-sip-xcap-config] to alert a
user agent of changes made by someone else to their provisioned
data.
RFC 4826, XML Formats for Representing Resource Lists (S): RFC 4826
[RFC4826] defines two XML document formats used to represent buddy
lists. One is simply a list of users (or more generally,
resources), and the other defines a buddy list whose membership is
composed of a list of users or resources. These lists can be
Rosenberg Expires May 16, 2008 [Page 7]
Internet-Draft Simple Made Simple November 2007
manipulated by XCAP, allowing a user to add or remove members from
their buddy lists. The buddy list is also accessed by the
resource list server specified in RFC 4662 for processing resource
list subscriptions.
RFC 4827, An Extensible Markup Language (XML) Configuration Access
Protocol (XCAP) Usage for Manipulating Presence Document Contents
(S): RFC 4827 [RFC4827] defines an XCAP usage that allows a user to
store an "offline" presence document. This is a presence status
that is used by a presence server when there are no presence
documents published for that user by any user agents currently
running.
2.5. Optimizations
When running over wireless links, presence can be a very expensive
service. Notifications often get sent when the change is not really
relevant to the watcher. Furthermore, when a notification is sent,
it contains the full presence state of the watcher, rather than just
an indication of what changed. Optimizations have been defined to
address both of these cases.
RFC 4660, Functional Description of Event Notification Filtering
(S): RFC 4660 [RFC4660] defines a mechanism that allows a watcher to
include filters in its subscription. These filters limit the
cases in which notifications are sent. It is used in conjunction
with RFC 4661 [RFC4661] which specifies the XML format of the
filters themselves. The mechanism, though targeted for presence,
can be applied to any SIP event package.
RFC 4661, An Extensible Markup Language (XML)-Based Format for Event
Notification Filtering (S): RFC 4661 [RFC4661] defines an XML format
used with the event notification filtering mechanism defined in
RFC 4660 [RFC4660].
RFC XXXX, Presence Information Data format (PIDF) Extension for
Partial Presence (S): [I-D.ietf-simple-partial-pidf-format] defines
a new XML format for representing changes in presence documents,
called a partial PIDF document. This format contains an XML patch
operation [I-D.ietf-simple-xml-patch-ops], that, when applied to
the previous presence document, yields the new presence document.
The partial PIDF document is included in presence notifications
when a watcher indicates that they support the format.
RFC XXXX, Publication of Partial Presence Information (S): RFC XXXX
[I-D.ietf-simple-partial-publish] defines a mechanism for
publishing presence status using a partial PIDF document.
Rosenberg Expires May 16, 2008 [Page 8]
Internet-Draft Simple Made Simple November 2007
RFC XXXX, An Extensible Markup Language (XML) Patch Operations
Framework Utilizing XML Path Language (XPath) Selectors (S): RFC
XXXX [I-D.ietf-simple-xml-patch-ops] defines an XML structure for
representing changes in XML documents. It is a form of "diff",
but specifically for XML documents. It is used by several of the
optimization mechanisms defined for SIMPLE.
RFC XXXX, The Presence-Specific Static Dictionary for Signaling
Compression (Sigcomp) (S): [I-D.garcia-simple-presence-dictionary]
defines a dictionary for usage with Signaling Compression
(Sigcomp) [RFC3320] to improve the compressability of presence
documents.
3. Instant Messaging
SIMPLE defines two modes of instant messaging. These are page mode
and session mode. In page mode, instant messages are sent by sending
a SIP request that contains the contents of the instant message. In
session mode, IM is viewed as another media type - along with audio
and video - and an INVITE request is used to set up a session that
includes IM as a media type. While page mode is more efficient for
one or two message conversations, session mode is more efficient for
longer conversations since the messages are not sent through the SIP
servers. Furthermore, by viewing IM as a media type, all of the
features available in SIP signaling - third party call control,
forking, and so on, are available for IM.
3.1. Page Mode
RFC 3428, Session Initiation Protocol (SIP) Extension for Instant
Messaging (S): RFC 3428 [RFC3428] introduces the MESSAGE method,
which can be used to send an instant message through SIP
signaling.
RFC XXXX, Multiple-Recipient MESSAGE Requests in the Session
Initiation Protocol (SIP) (S): [I-D.ietf-sip-uri-list-message]
defines a mechanism whereby a client can send a single SIP MESSAGE
to multiple recipients. This is accomplished by including the
list of recipients as an object in the body, and having a network
server send a copy to each recipient.
3.2. Session Mode
RFC 4975, The Message Session Relay Protocol (MSRP) (S): RFC 4975
[RFC4975] defines a small text-based protocol for exchanging
arbitrarily sized content of any time between users. An MSRP
session is set up by exchanging certain information, such as an
Rosenberg Expires May 16, 2008 [Page 9]
Internet-Draft Simple Made Simple November 2007
MSRP URI, within SIP and SDP signaling.
RFC 3862, Common Presence and Instant Messaging (CPIM): Message
Format (S): RFC 3862 [RFC3862] defines a wrapper around instant
message content, providing meta-data such as the sender and
recipient identity. The CPIM format is carried in MSRP.
RFC 4976, Relay Extensions for the Message Sessions Relay Protocol
(MSRP) (S): RFC 4976 [RFC4976] adds support for relays to MSRP.
These relay servers receive MSRP messages and send them towards
the destination. They provide support for firewall and NAT
traversal, and allow for features such as recording and inspection
to be implemented.
3.3. IM Chat Rooms
In SIMPLE, IM multi-user chat, also known as chat-rooms, are provided
using regular SIP conferencing mechanisms. The framework for SIP
conferencing [RFC4353] and conference control
[I-D.ietf-xcon-framework] describe how all SIP-based conferencing
works, including joining and leaving, persistent and temporary
conferences, floor control and moderation, and learning of conference
membership, amongst other functions. All that is necessary are
extensions to provide features that are specific to IM.
RFC XXXX, Multi-party Instant Message (IM) Sessions the Message
Session Relay Protocol (MSRP) (S): RFC XXXX [I-D.ietf-simple-chat]
defines how MSRP is used to provide support for nicknames and
private chat within an IM conference.
3.4. IM Features
Several specifications have been written to provide IM-specific
features for SIMPLE. These include "is-typing" indications, allowing
a user to know when their messaging peer is composing a response, and
delivery notifications, allowing a user to know when their IM has
been received.
RFC 3994, Indication of Message Composition for Instant Messaging
(S): RFC 3994 [RFC3994] defines an XML format that can be sent in
instant messages that indicates the status of message composition.
This provides the familiar "is-typing" indication in IM systems,
but also supports voice, video and other message types.
RFC XXXX, Instant Message Disposition Notification (S): RFC XXXX
[I-D.ietf-simple-imdn] provides delivery notifications of IM
receipt. This allows a user to know with certainty that a message
has been received.
Rosenberg Expires May 16, 2008 [Page 10]
Internet-Draft Simple Made Simple November 2007
4. Security Considerations
This specification is an overview of existing specifications, and
does not introduce any security considerations on its own.
5. IANA Considerations
None.
6. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the Presence
Information Data Format (PIDF)", RFC 4480, July 2006.
[RFC4481] Schulzrinne, H., "Timed Presence Extensions to the
Presence Information Data Format (PIDF) to Indicate Status
Information for Past and Future Time Intervals", RFC 4481,
July 2006.
[RFC4482] Schulzrinne, H., "CIPID: Contact Information for the
Rosenberg Expires May 16, 2008 [Page 11]
Internet-Draft Simple Made Simple November 2007
Presence Information Data Format", RFC 4482, July 2006.
[I-D.ietf-simple-prescaps-ext]
Lonnfors, M. and K. Kiss, "Session Initiation Protocol
(SIP) User Agent Capability Extension to Presence
Information Data Format (PIDF)",
draft-ietf-simple-prescaps-ext-07 (work in progress),
July 2006.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745,
February 2007.
[I-D.ietf-simple-presence-rules]
Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-10 (work in progress),
July 2007.
[RFC3857] Rosenberg, J., "A Watcher Information Event Template-
Package for the Session Initiation Protocol (SIP)",
RFC 3857, August 2004.
[RFC3858] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, August 2004.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007.
[RFC4827] Isomaki, M. and E. Leppanen, "An Extensible Markup
Language (XML) Configuration Access Protocol (XCAP) Usage
for Manipulating Presence Document Contents", RFC 4827,
May 2007.
[I-D.ietf-sip-xcap-config]
Petrie, D., "Extensions to the Session Initiation Protocol
(SIP) User Agent Profile Delivery Change Notification
Event Package for the Extensible Markup Language Language
Configuration Access Protocol (XCAP)",
draft-ietf-sip-xcap-config-00 (work in progress),
October 2006.
[I-D.ietf-simple-xcap-diff]
Rosenberg, J., "An Extensible Markup Language (XML)
Document Format for Indicating A Change in XML
Rosenberg Expires May 16, 2008 [Page 12]
Internet-Draft Simple Made Simple November 2007
Configuration Access Protocol (XCAP) Resources",
draft-ietf-simple-xcap-diff-05 (work in progress),
March 2007.
[I-D.ietf-simple-xml-patch-ops]
Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath)
Selectors", draft-ietf-simple-xml-patch-ops-03 (work in
progress), August 2007.
[RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "Functional Description of Event Notification
Filtering", RFC 4660, September 2006.
[RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML)-Based Format
for Event Notification Filtering", RFC 4661,
September 2006.
[I-D.ietf-simple-partial-publish]
Lonnfors, M., "Publication of Partial Presence
Information", draft-ietf-simple-partial-publish-06 (work
in progress), February 2007.
[I-D.ietf-simple-partial-pidf-format]
Lonnfors, M., "Presence Information Data format (PIDF)
Extension for Partial Presence",
draft-ietf-simple-partial-pidf-format-08 (work in
progress), November 2006.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[I-D.ietf-xcon-framework]
Barnes, M., "A Framework for Centralized Conferencing",
draft-ietf-xcon-framework-09 (work in progress),
Rosenberg Expires May 16, 2008 [Page 13]
Internet-Draft Simple Made Simple November 2007
August 2007.
[I-D.ietf-simple-chat]
Niemi, A. and M. Garcia-Martin, "Multi-party Instant
Message (IM) Sessions Using the Message Session Relay
Protocol (MSRP)", draft-ietf-simple-chat-00 (work in
progress), June 2007.
[RFC3994] Schulzrinne, H., "Indication of Message Composition for
Instant Messaging", RFC 3994, January 2005.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging (CPIM): Message Format", RFC 3862, August 2004.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[I-D.ietf-simple-imdn]
Burger, E. and H. Khartabil, "Instant Message Disposition
Notification", draft-ietf-simple-imdn-04 (work in
progress), May 2007.
[I-D.garcia-simple-presence-dictionary]
Garcia-Martin, M., "The Presence-Specific Static
Dictionary for Signaling Compression (Sigcomp)",
draft-garcia-simple-presence-dictionary-06 (work in
progress), August 2007.
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
Liu, Z., and J. Rosenberg, "Signaling Compression
(SigComp)", RFC 3320, January 2003.
[I-D.ietf-sip-uri-list-message]
Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
MESSAGE Requests in the Session Initiation Protocol
(SIP)", draft-ietf-sip-uri-list-message-01 (work in
progress), January 2007.
Rosenberg Expires May 16, 2008 [Page 14]
Internet-Draft Simple Made Simple November 2007
Author's Address
Jonathan Rosenberg
Cisco
Edison, NJ
US
Phone: +1 973 952-5000
Email: jdrosen@cisco.com
URI: http://www.jdrosen.net
Rosenberg Expires May 16, 2008 [Page 15]
Internet-Draft Simple Made Simple November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rosenberg Expires May 16, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 16:37:16 |