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 17, 2008.

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.

Table of Contents

1.  Introduction
2.  Presence
    2.1.  Core Protocol Machinery
    2.2.  Presence Documents
    2.3.  Privacy and Policy
    2.4.  Provisioning
    2.5.  Optimizations
3.  Instant Messaging
    3.1.  Page Mode
    3.2.  Session Mode
    3.3.  IM Chat Rooms
    3.4.  IM Features
4.  Security Considerations
5.  IANA Considerations
6.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

The IETF has produced many specifications related to Presence and Instant Messaging with the Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). 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] (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.). 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:

• The core protocol machinery, which provides the actual SIP extensions for subscriptions, notifications and publications
• Presence documents, which are XML documents that provide for rich presence and are carried by the core protocol machinery
• 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
• Provisioning, which describes how users manage their privacy policies, buddy lists and other pieces of information required for SIMPLE presence to work
• 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 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [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] (Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” August 2004.) 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 (Presence Documents)

RFC 4662, A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists (S):

RFC 4662 (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.) [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 (Provisioning).

RFC 3903, SIP Extension for Event State Publication (S):

RFC 3903 [RFC3903] (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) 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.

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 (Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, “Presence Information Data Format (PIDF),” August 2004.) [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 (Rosenberg, J., “A Data Model for Presence,” July 2006.) [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 (Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, “RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF),” July 2006.) [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 (Schulzrinne, H., “Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals,” July 2006.) [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 (Schulzrinne, H., “CIPID: Contact Information for the Presence Information Data Format,” July 2006.) [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 (Lonnfors, M. and K. Kiss, “Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF),” May 2008.) [I‑D.ietf‑simple‑prescaps‑ext] adds even more attributes to the presence document schema, this time to allow indication of 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 (Presence Documents) 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 (Provisioning).

RFC 4745, Common Policy: A Document Format for Expressing Privacy Preferences (S):

RFC 4745 (Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, “Common Policy: A Document Format for Expressing Privacy Preferences,” February 2007.) [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 (Rosenberg, J., “Presence Authorization Rules,” July 2007.) [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] (Rosenberg, J., “A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP),” August 2004.), 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 (Rosenberg, J., “An Extensible Markup Language (XML) Based Format for Watcher Information,” August 2004.) [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.

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] (Rosenberg, J., “Presence Authorization Rules,” July 2007.)).

In SIMPLE, management of this data is handled by the XML Configuration Access Protocol (XCAP) [RFC4825] (Rosenberg, J., “The Extensible Markup Language (XML) Configuration Access Protocol (XCAP),” May 2007.). 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 (Rosenberg, J., “The Extensible Markup Language (XML) Configuration Access Protocol (XCAP),” May 2007.) [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 (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),” October 2006.) [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 (Rosenberg, J. and J. Urpalainen, “An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources,” February 2010.) [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] (Urpalainen, J., “An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors,” November 2007.). It is used in conjunction with [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),” October 2006.) 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 (Rosenberg, J., “Extensible Markup Language (XML) Formats for Representing Resource Lists,” May 2007.) [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 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 (Isomaki, M. and E. Leppanen, “An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents,” May 2007.) [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 (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “Functional Description of Event Notification Filtering,” September 2006.) [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] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.) 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 (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.) [RFC4661] defines an XML format used with the event notification filtering mechanism defined in RFC 4660 [RFC4660] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “Functional Description of Event Notification Filtering,” September 2006.).

RFC XXXX, Presence Information Data format (PIDF) Extension for Partial Presence (S):

[I‑D.ietf‑simple‑partial‑pidf‑format] (Lonnfors, M., Leppanen, E., Khartabil, H., and J. Urpalainen, “Presence Information Data format (PIDF) Extension for Partial Presence,” November 2007.) 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] (Urpalainen, J., “An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors,” November 2007.), 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 (Niemi, A., Lonnfors, M., and E. Leppanen, “Publication of Partial Presence Information,” February 2008.) [I‑D.ietf‑simple‑partial‑publish] defines a mechanism for publishing presence status using a partial PIDF document.

RFC XXXX, An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors (S):

RFC XXXX (Urpalainen, J., “An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors,” November 2007.) [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] (Garcia-Martin, M., “The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp),” August 2007.) defines a dictionary for usage with Signaling Compression (Sigcomp) [RFC3320] (Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, “Signaling Compression (SigComp),” January 2003.) 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 (Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” December 2002.) [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] (Garcia-Martin, M. and G. Camarillo, “Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP),” December 2007.) 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 (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) [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 MSRP URI, within SIP and SDP signaling.

RFC 3862, Common Presence and Instant Messaging (CPIM): Message Format (S):

RFC 3862 (Klyne, G. and D. Atkins, “Common Presence and Instant Messaging (CPIM): Message Format,” August 2004.) [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 (Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” September 2007.) [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] (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.) and conference control [I‑D.ietf‑xcon‑framework] (Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” April 2008.) 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 (Niemi, A., Garcia, M., and G. Sandbakken, “Multi-party Chat Using the Message Session Relay Protocol (MSRP),” April 2010.) [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 (Schulzrinne, H., “Indication of Message Composition for Instant Messaging,” January 2005.) [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 (Burger, E. and H. Khartabil, “Instant Message Disposition Notification,” December 2008.) [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.

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

Author's Address

Full Copyright Statement

Copyright © 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.