A Session Initiation Protocol (SIP) Event Package and Data Format for Describing Files
draft-garcia-sipping-file-event-package-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 19, 2008.

Abstract

This document specifies the format and semantics associated to a 'file' event package that allows SIP endpoints to publish the availability of files. A file can be, for example, images, video files, audio files, etc. The event package reuses the eXtended Mark-up Language (XML) 'file-metadata' document to provide file descriptions. This event package also allows SIP endpoints to subscribe to changes in the availability of files, or perform searches for the availability and location of a given file. Support for partial notifications and publications is also accomplished by using XML patch operations.

Table of Contents

1.  Introduction
2.  Terminology
3.  The 'file' Event Package
    3.1.  Package Name
    3.2.  Event Package Parameters
    3.3.  SUBSCRIBE Bodies
    3.4.  Subscription duration
    3.5.  NOTIFY Bodies
    3.6.  Notifier processing of SUBSCRIBE requests
        3.6.1.  Authentication
        3.6.2.  Authorization
    3.7.  Notifier Generation of NOTIFY Requests
    3.8.  Subscriber Processing of NOTIFY Requests
    3.9.  Handling of Forked Requests
    3.10.  Rate of Notifications
    3.11.  State Agents
    3.12.  Examples
    3.13.  Use of URIs to Retrieve State
    3.14.  PUBLISH bodies
    3.15.  PUBLISH Response Bodies
    3.16.  Multiple Sources for Event State
    3.17.  Event State Segmentation
    3.18.  Rate of Publication
4.  Security Considerations
5.  Acknowledgements
6.  IANA Considerations
    6.1.  Registration of the 'file' Event Package
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

There are scenarios where a SIP endpoint has a number of available files that can be offered for public disposal or for a limited number of authorized users. One of these cases is, for example, when Alice takes some pictures with her camera phone and she wants to share them within a community. This requires a mechanism that allows Alice to describe the files she wants to share.

In another scenario, Alice might be interested in finding out the availability of a given file, defined by a set of parameters. Think, for example, of Alice trying to find pictures of the bowling tournament that took place recently in her home town. This implies a mechanism whereby Alice can perform searches of available files. The user who performs the search identifies one or more aspects of the file she is searching, but probably she is not able to provide a full description of the file.

SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] provides an extensible event mechanism (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] that is suitable for our needs. We enable the above scenarios by defining a SIP event package for file metadata publication and search. We reuse the 'file-metadata' document format specified in the XML Data Format for describing files (Garcia-Martin, M. and M. Matuszewski, “An Extensible Data Format (XML) for Describing Files,” November 2007.) [I‑D.garcia‑app‑area‑file‑data‑format]. All together, they allow an Event Publication Agent (EPA) to provide a description of locally available files in a PUBLISH request (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903]. In a community, there can be an Event State Compositor that aggregates shared files available at different endpoints. The Event State Compositor (ESC) that receives the PUBLISH request processes 'file-metadata' documents according to a well defined strategy (which is outside the scope of this document). For example, the ESC can be a centralized intermediary facilitator for a given community, or it can be a super-node of a SIP Peer-to-Peer (P2P) network.

A user that searches for one or more files issues a SUBSCRIBE request (either a subscription or a fetch of state, see RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265]) to the 'file' event package. Because a subscription to all of the files published in the community is likely to contain a large amount of data, the subscriber will typically attach a filter (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.) [RFC4661] that describes the files under search. This will result in the generation of one or more NOTIFY requests that contains the searched items. Once the information on files is retrieved, the subscriber can use any suitable mechanism (such as the one defined in "Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer" (Garcia, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, “A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer,” February 2009.) [I‑D.ietf‑mmusic‑file‑transfer‑mech]) to actually download the file. Such file transfer mechanisms are outside the scope of this memo.

In the file descriptor, sometimes the URI points to the file itself itself (such as an HTTP URI that points to an image file). In other cases the URI merely resolves to a host where the content is available (for example, the SIP URI of a camera phone that stores images).

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] and indicate requirement levels for compliant implementations.

3.  The 'file' Event Package

RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] defines a SIP extension for subscribing to, and receiving notifications of changes (events) in the state of remote nodes. It leaves the definition of many aspects of these events to concrete extensions, known as event packages. This document qualifies as an event package. This section fills in the information required for all event packages by RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265].

Additionally, RFC 3903 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903] defines an extension that allows SIP User Agents to publish event state. According to RFC 3903 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903] any event package intended to be used in conjunction with the SIP PUBLISH method has to include a considerations section. This section also fills the information for all event packages to be used with PUBLISH requests.

We define a new 'file' event package. Event Publication Agents (EPA) use PUBLISH requests to inform an Event State Compositor (ESC) of changes in the 'file' event package. The ESC, acting as a notifier, notifies subscribers to the 'file' event package when changes occur.

3.1.  Package Name

The name of this package is 'file'. As specified in RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265], this value appears in the Event header field present in SUBSCRIBE and NOTIFY requests. As specified in the RFC 3903 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903], this value appears as well in the Event header field present in PUBLISH requests.

3.2.  Event Package Parameters

RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] allows event packages to define additional parameters carried in the Event header field. This event package, 'file', does not define additional parameters.

3.3.  SUBSCRIBE Bodies

According to RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265], a SUBSCRIBE request can contain a body. The purpose of the body depends on its type. Subscriptions to the 'file' event package MAY contain a filter body according to the format specified in [RFC4661] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.). Filters are used to reduce the number of results during searches.

3.4.  Subscription duration

From the functional point of view, there are two kinds of subscriptions to the 'file' even package. In one, the user may want to either perform a single search operation on the existing files. In the other, the user may want to monitor the changes in the state information of files. These functionalities can be controlled by the duration of the subscription.

A search on existing files can be implemented with a single fetch operation (where the Expires header field is set to zero) or by a subscription of a short duration (typically on the order of a few minutes). The other functionality, where a user wants to monitor the changes of a state, is typically implemented as a lengthy subscription, on the order of hours, as the user needs to be notified whenever a change in the file has occurred.

Due to the lack of congruence in the two types of subscriptions, it is hard to select a default expiration value. We have decided to select a mean default value that accommodate both types of subscriptions: 1800 seconds. As per RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265], the subscriber MAY specify an alternate expiration in the Expires header field. It is RECOMMENDED that UACs always include an explicit Expires header field with the desired subscription value.

3.5.  NOTIFY Bodies

As described in RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265], the NOTIFY message can contain a body describing the state of the subscribed resources. This body is either in a format listed in the Accept header field of the SUBSCRIBE request, or in a package-specific default format, if the Accept header field was omitted from the SUBSCRIBE request.

In this event package, the body of the notification contains a 'file-metadata' document, specified in the XML Data Format for describing files (Garcia-Martin, M. and M. Matuszewski, “An Extensible Data Format (XML) for Describing Files,” November 2007.) [I‑D.garcia‑app‑area‑file‑data‑format]. A 'file-metadata' document can be expressed as a full or partial document. An ESC can receive 'file-metadata' documents from different EPAs or other sources. The ESC applies a composition policy, and composes a 'file-metadata' document that contains all the available known files to the EPA. If the ESC is not able to resolve a conflict, due to contradictory information provided by two different EPAs, the ESC provides a comprehensive information for that file, so that the subscriber can resolve the conflict.

All subscribers and notifiers of 'file' event package MUST support the "application/file+xml" data format described in XML Data Format for describing files (Garcia-Martin, M. and M. Matuszewski, “An Extensible Data Format (XML) for Describing Files,” November 2007.) [I‑D.garcia‑app‑area‑file‑data‑format]. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/file+xml" (assuming that the Event header field contains a value of 'file'). If the Accept header field is present, it MUST include "application/file+xml", and MAY include any other types capable of representing 'file-metadata' documents.

When composing a 'file-metadata' document, the ESC MAY include several <instance> elements per <file> element. This would be the case when the ESC has acquired information concerning the same file, for example, through publications from different EPAs.

3.6.  Notifier processing of SUBSCRIBE requests

The contents of a 'file-metadata' document can contain sensitive information that can reveal some privacy information. For example, it can contain a list of valuable files and the address (SIP URI) of the SIP User Agent where those are stored. While this information itself is not very useful, it can be used by malicious agents, e.g., to mount an attack to avoid other users to retrieve such a file. Therefore, 'file-metadata' documents MUST only be sent to authorized subscribers. In order to determine if a subscription originates in an authorized user, the user MUST be authenticated as described in Section 3.6.1 (Authentication) and then he MUST be authorized to be a subscriber as described in Section 3.6.2 (Authorization).

3.6.1.  Authentication

Notifiers SHOULD authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] and other authentication extensions.

3.6.2.  Authorization

Once authenticated, the notifier makes an authorization decision. A notifier MUST NOT accept a subscription unless authorization has been provided by the user. The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page, or provided with the Common Policy Framework (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].

3.7.  Notifier Generation of NOTIFY Requests

RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY request, how to compute the state of the resource, how to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the 'file' event package.

A notifier MAY send a NOTIFY at any time. The NOTIFY request MAY contain a body containing a 'file-metadata' document or any other type indicated by the subscriber in the Accept header field of the SUBSCRIBE request. The times at which the NOTIFY is sent to a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that governs the subscription, but typically will contain an indication of those known files for which a change has occurred.

Since 'file-metadata' documents can contain full or partial state, the first 'file-metadata' document that a notifier sends to subscriber MUST contain be a full 'file-metadata' document. Subsequent documents sent to the same subscriber MAY contain full 'file-metadata' documents or partial 'file-metadata' documents (the XML Data Format for describing files (Garcia-Martin, M. and M. Matuszewski, “An Extensible Data Format (XML) for Describing Files,” November 2007.) [I‑D.garcia‑app‑area‑file‑data‑format] provides further discussion about full and partial 'file-metadata' documents).

In the case of a pending subscription, when final authorization is determined, a NOTIFY request can be sent. If the result of the authorization decision was success, a NOTIFY SHOULD be sent and SHOULD contain a full 'file-metadata' document with the current state of the files known by the notifier at that moment. If the subscription is rejected, a NOTIFY MAY be sent. As described in RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265], the Subscription-State header field indicates the state of the subscription.

Frequently, the notifier will have a incomplete view of the available files described in a 'file-metadata' document. For the duration of the subscription, the notifier can be running searches for the availability of the searched files. When new state information is made available to the notifier, the notifier SHOULD provide this information to the subscribers, typically as notifications that contain a partial 'file-metadata' document.

The body of the NOTIFY MUST be sent using one of the types listed in the Accept header field in the most recent SUBSCRIBE request, or using the type "application/file+xml" if no Accept header field was present.

Notifiers will typically act as Event State Compositors (ESC) and thus, will learn the 'file' event state via PUBLISH requests sent from the user's Event Publication Agent (EPA) when the user makes one or more files available or via subscriptions passed further to other ESCs.

For reasons of privacy, it will frequently be necessary to encrypt the contents of the notifications. This can be accomplished using S/MIME (Ramsdell, B., “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification,” July 2004.) [RFC3851]. The encryption can be performed using the key of the subscriber as identified in the From field of the SUBSCRIBE request. Similarly, integrity of the notifications is important to subscribers. As such, the contents of the notifications MAY provide authentication and message integrity using S/MIME (Ramsdell, B., “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification,” July 2004.) [RFC3851]. This will require the notifier to sign the content of the notification with the notifier's private key.

3.8.  Subscriber Processing of NOTIFY Requests

RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] leaves it to event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request, including any logic required to form a coherent resource state.

In this specification, each NOTIFY request contains either no 'file-metadata' document, a full 'file-metadata' document representing files which are available at one or more SIP User Agents, or a partial 'file-metadata' document that represent changes with respect a previously notified 'file-metadata' document. Within a dialog, when a 'file-metadata' document is received in a NOTIFY request with a higher CSeq header field value than a previously received NOTIFY, and when the 'version' attribute value of the <patch> element is increased by one it contains a partial 'file-metadata' document that updates a previously received 'file-metadata' document (see the XML Data Format for describing files (Garcia-Martin, M. and M. Matuszewski, “An Extensible Data Format (XML) for Describing Files,” November 2007.) [I‑D.garcia‑app‑area‑file‑data‑format] for more details).

3.9.  Handling of Forked Requests

RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] requires each package to describe handling of forked SUBSCRIBE requests.

This specification allows several dialogs to be constructed as a result of emitting an initial SUBSCRIBE request, i.e., in cases where the SUBSCRIBE request forked to several notifiers. In this case, the subscriber will keep several simultaneous dialogs. The subscriber SHOULD merge the several 'file-metadata' documents received in NOTIFY requests. It might be possible that new <file> elements are received in forked 'file-metadata' documents, or it might be possible that existing <file> elements are updated with new information (e.g., a new <gruu> element). In both cases the merge should provide a logical OR operation of all the available information such as new entries and added information to existing entries.

3.10.  Rate of Notifications

RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] requires each package to specify the maximum rate at which notifications can be sent.

Notifiers of 'file-metadata' documents SHOULD NOT generate notifications for a single user at a higher rate than once every second.

3.11.  State Agents

RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] requires each package to consider the role of state agents in the package, and if they are used, to specify how authentication and authorization are done.

This specification allows state agents to be located in the network. A given file might be available at different SIP User Agents in the network. ESCs can act as state agents by compiling and aggregating state towards, e.g., subscribers, other networks or communities. State agents MUST use any of the mechanism specified in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] or any other SIP extension to authenticate and authorize users prior to accepting publications.

If the state agent acts as an aggregator, the state agent SHOULD aggregate all the information related to the same available file. In this case, it is expected that, because the same file is available in different endpoints, there might be different URIs for a given available file.

3.12.  Examples

Examples of 'file-metadata' documents are provided in the XML Data Format for describing files (Garcia-Martin, M. and M. Matuszewski, “An Extensible Data Format (XML) for Describing Files,” November 2007.) [I‑D.garcia‑app‑area‑file‑data‑format].

3.13.  Use of URIs to Retrieve State

RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] allows packages to use URIs to retrieve large state documents.

A 'file-metadata' document can be of any arbitrary length, and can also become too large to be reasonably sent in a SIP request. To avoid the burden of transmitting large documents through SIP proxies and to avoid potential congestion scenarios, it is possible that the notifier instead includes a URI that points to the contents, rather than the actual contents. For example, the notifier can include an HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] URI that points to the notifier itself. Since HTTP requests are transferred via a congestion controlled protocol (such as TCP (Postel, J., “Transmission Control Protocol,” September 1981.) [RFC0793]), the inclusion of a URI to retrieve state mitigates the problem of large 'file-metadata' documents.

3.14.  PUBLISH bodies

RFC 3903 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903] requires event packages to define the content types expected in PUBLISH requests.

In this event package, the body of a PUBLISH request contains a 'file-metadata' document (see the XML Data Format for describing files (Garcia-Martin, M. and M. Matuszewski, “An Extensible Data Format (XML) for Describing Files,” November 2007.) [I‑D.garcia‑app‑area‑file‑data‑format]). This 'file-metadata' document describes the availability of one or more files (typically, but not necessarily, stored at the EPA). EPAs SHOULD only publish the description of locally available files, i.e., the URI of the file SHOULD resolve to the EPA itself.

All EPAs and ESCs MUST support the "application/file+xml" data format described in the XML Data Format for describing files (Garcia-Martin, M. and M. Matuszewski, “An Extensible Data Format (XML) for Describing Files,” November 2007.) [I‑D.garcia‑app‑area‑file‑data‑format]. and MAY support other formats.

When the EPA is composing a 'file-metadata' document, the EPA SHOULD include only one <instance> element per <file> element, and the data SHOULD include only the local description of the file.

Allowing EPAs to provide a description of non-locally stored files could be maliciously used for creating, e.g., denial of service attacks.

EPAs MUST NOT publish non-local URIs in the <uri> element, although they MAY publish several URIs for a single file, e.g., if the file is available through several protocols and URIs.

EPAs MUST NOT include <user-aor> containing addresses-of-record that point to other users than the one whose file EPA is publishing. ESCs MUST verify that a <user-aor> element received in a PUBLISH request belongs to the same user who published the request; this requires the ESC to first authenticate the publisher.

3.15.  PUBLISH Response Bodies

This specification does not associate semantics to a body in a PUBLISH response.

3.16.  Multiple Sources for Event State

RFC 3903 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903] requires event packages to specify whether multiple sources can contribute to the event state view at the ESC.

This event package allows different EPAs to publish the availability of the same file. For the same file, each EPA publishes data that is invariant with the instance of the file, and data that is specific with each instance. The ESC SHOULD merge the data pertaining to the same file according to a composition policy. This policy can, e.g., list all the difference instances where each file is available.

3.17.  Event State Segmentation

RFC 3903 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903] defines segments within a state document. Each segment is defined as one of potentially many identifiable sections in the published event state.

In this 'file' event package, each <file> element composes a segment.

3.18.  Rate of Publication

RFC 3903 (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) [RFC3903] allows event packages to define their own rate of publication.

There are no rate limiting recommendations for 'file' publication. It is expected that new files are added at the time of creation (e.g., a new image is taken with a camera phone), and that they are not changed often. Thus, a typical rate of publication does not exist and there is no foreseen need to limit the rate of publications.

4.  Security Considerations

TBD

5.  Acknowledgements

The authors would like to thank Nicklas Beijar and Juuso Lehtinen held fruitful discussions with the authors that lead to the design of this event package. Pekka Kuure and Arto Leppisaari provided helpful comments during the initial review.

6.  IANA Considerations

6.1.  Registration of the 'file' Event Package

This specification registers an event package, based on the registration procedures defined in RFC 3265 (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265]. The following is the information required for such a registration:

Package Name: file

Package or Template-Package: This is a package.

Published Document: RFC XXX [Replace by the RFC number of this specification].

Person to Contact: Miguel A. Garcia-Martin, miguel.garcia@nsn.com

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses

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.