Network Working Group J. Rosenberg Request for Comments: 3680 dynamicsoft Category: Standards Track March 2004 A Session Initiation Protocol (SIP) Event Package for Registrations Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved.
AbstractThis document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications. 1. Introduction ................................................. 2 2. Terminology .................................................. 3 3. Usage Scenarios .............................................. 3 3.1. Forcing Re-Authentication .............................. 3 3.2. Composing Presence ..................................... 3 3.3. Welcome Notices ........................................ 4 4. Package Definition ........................................... 4 4.1. Event Package Name ..................................... 4 4.2. Event Package Parameters ............................... 5 4.3. SUBSCRIBE Bodies ....................................... 5 4.4. Subscription Duration .................................. 5 4.5. NOTIFY Bodies .......................................... 6 4.6. Notifier Processing of SUBSCRIBE Requests .............. 6 4.7. Notifier Generation of NOTIFY Requests ................. 7 4.7.1. The Registration State Machine ................. 7
4.7.2. Applying the state machine ..................... 9 4.8. Subscriber Processing of NOTIFY Requests ............... 9 4.9. Handling of Forked Requests ............................ 9 4.10. Rate of Notifications .................................. 10 4.11. State Agents ........................................... 10 5. Registration Information ..................................... 10 5.1. Structure of Registration Information .................. 10 5.2. Computing Registrations from the Document .............. 14 5.3. Example ................................................ 15 5.4. XML Schema ............................................. 16 6. Example Call Flow ............................................ 18 7. Security Considerations ...................................... 21 8. IANA Considerations .......................................... 21 8.1. SIP Event Package Registration ......................... 21 8.2. application/reginfo+xml MIME Registration .............. 22 8.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:reginfo ......................... 23 9. References ................................................... 23 9.1. Normative References ................................... 23 9.2. Informative References ................................. 24 10. Contributors ................................................. 25 11. Acknowledgements ............................................. 25 12. Author's Address ............................................. 25 13. Full Copyright Statement ..................................... 26 1] provides all of the functions needed for the establishment and maintenance of communications sessions between users. One of the functions it provides is a registration operation. A registration is a binding between a SIP URI, called an address-of-record, and one or more contact URIs. These contact URIs represent additional resources that can be contacted in order to reach the user identified by the address-of-record. When a proxy receives a request within its domain of administration, it uses the Request-URI as an address-of-record, and uses the contacts bound to the address-of-record to forward (or redirect) the request. The SIP REGISTER method provides a way for a user agent to manipulate registrations. Contacts can be added or removed, and the current set of contacts can be queried. Registrations can also change as a result of administrator policy. For example, if a user is suspected of fraud, their registration can be deleted so that they cannot receive any requests. Registrations also expire after some time if not refreshed.
Registrations represent a dynamic piece of state maintained by the network. There are many cases in which user agents would like to know about changes to the state of registrations. The SIP Events Framework  defines a generic framework for subscription to, and notification of, events related to SIP systems. The framework defines the methods SUBSCRIBE and NOTIFY, and introduces the notion of a package. A package is a concrete application of the event framework to a particular class of events. Packages have been defined for user presence , for example. This specification defines a package for registration state. RFC 2119  and indicate requirement levels for compliant implementations. 9]. User presence represents the willingness and ability of a user to communicate with other users on the network. It is composed of a set of contact addresses that represent the various means for contacting the user. Those contact addresses might represent the contact address for voice, for example. Typically, the contact address
listed for voice will be an address-of-record. The status of that contact (whether its open or closed) may depend on any number of factors, including the state of any registrations against that address-of-record. As a result, registration state can be viewed as an input to the process which determines the presence state of a user. Effectively, registration state is "raw" data, which is combined with other information about a user to generate a document that describes the user's presence. In fact, this event package allows for a presence server to be separated from a SIP registration server, yet still use registration information to construct a presence document. When a presence server receives a presence subscription for some user, the presence server itself would generate a subscription to the registration server for the registration event package. As a result, the presence server would learn about the registration state for that user, and it could use that information to generate presence documents. 10] to the device, welcoming the user and providing any necessary information. Section 4.4 of . 2], this value appears in the Event header present in SUBSCRIBE and NOTIFY requests.
Example: Event: reg
default duration of subscriptions to registration state is slightly longer, 3761 seconds. This helps avoid any potential problems with coupling of subscription and registration refreshes. Of course, clients MAY include an Expires header in the SUBSCRIBE request asking for a different duration. Section 5. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/reginfo+xml". If the header field is present, it MUST include "application/reginfo+xml", and MAY include any other types capable of representing registration information. Of course, the notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request. 1]. Authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made. It is RECOMMENDED that a user be allowed to subscribe to their own registration state. Such subscriptions are useful when there are many devices that represent a user, each of which needs to learn the registration state of the other devices. We also anticipate that applications and automata will frequently be subscribers to the
registration state. In those cases, authorization policy will typically be provided ahead of time. Figure 1. The machine is very simple. An instance of this machine is associated with each address-of-record. When there are no contacts registered to the address-of-record, the state machine is in the init state. It is important to note that this state machine exists, and is well-defined, for each address-of-record in the domain, even if there are no contacts registered to it. This allows a user agent to subscribe to an address-of-record, and learn that there are no contacts registered to it. When the first contact is registered to that address-of-record, the state machine moves from init to active.
+------------+ | | | Init | | | +------------+ | V +------------+ | | | Active | | | +------------+ | V +------------+ | | | Terminated | | | +------------+ Figure 1: Registration State Machine As long as there is at least one contact bound to the address-of- record, the state machine remains in the active state. When the last contact expires or is removed, the registration transitions to terminated. From there, it immediately transitions back to the init state. This transition is invisible, in that it MUST NOT ever be reported to a subscriber in a NOTIFY request. This allows for an implementation optimization whereby the registrar can destroy the objects associated with the registration state machine once it enters the terminated state and a NOTIFY has been sent. Instead, the registrar can assume that, if the objects for that state machine no longer exist, the state machine is in the init state. In addition to this state machine, each registration is associated with a set of contacts, each of which is modeled with its own state machine. Unlike the FSM for the address-of-record, which exists even when no contacts are registered, the per-contact FSM is instantiated when the contact is registered, and deleted when it is removed. The diagram for the per-contact state machine is shown in Figure 2. This FSM is identical to the registration state machine in terms of its states, but has many more transition events. When a new contact is added, the FSM for it is instantiated, and it moves into the active state. Because of that, the init state here is transient. There are two ways in which it can become active. One is
through an actual SIP REGISTER request (corresponding to the registered event), and the other is when the contact is created administratively, or through some non-SIP means (the created event). +------+ | | refreshed | | shortened V | +------------+ +------------+ +------------+ | | | | | | | Init |----------->| Active |----------->| Terminated | | | | | | | +------------+ registered +------------+ expired +------------+ created deactivated probation unregistered rejected Figure 2: Contact State Machine The FSM remains in the active state so long as the contact is bound to the address-of-record. When a contact is refreshed through a REGISTER request, the FSM stays in the same state, but a refreshed event is generated. Likewise, when an administrator modifies the expiration time of a binding (without deleting the binding) to trigger the contact to re-register and possibly re-authenticate, the FSM stays in the active state, but a shortened event is generated. When the contact is no longer bound to the address-of-record, the FSM moves to the terminated state, and once a NOTIFY is sent, the state machine is destroyed. As a result, the terminated state is effectively transient. There are several reasons this can happen. The first is an expiration, which occurs when the contact was not refreshed by a REGISTER request. The second reason is deactivated. This occurs when the administrator has removed the contact as a valid binding, but still wishes the client to attempt to re-register the contact. In contrast, the rejected event occurs when an active contact is removed by the administrator, but re-registrations will not help to re-establish it. This might occur if a user does not pay their bills, for example. The probation event occurs when an active contact is removed by the administrator, and the administrator wants the client to re-register, but to do so at a later time. The unregistered event occurs when a REGISTER request sets the expiration time of that contact to zero.
Section 5 outlines the process for the application/reginfo+xml format. Section 4.4.9 of the SIP Events framework .
4] that MUST be well-formed and SHOULD be valid. Registration information documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying registration information documents and document fragments. The namespace URI for elements defined by this specification is a URN , using the namespace identifier 'ietf' defined by  and extended by . This URN is: urn:ietf:params:xml:ns:reginfo A registration information document begins with the root element tag "reginfo". It consists of any number of "registration" sub-elements, each of which contains the registration state for a particular address-of-record. The registration information for a particular address-of-record MUST be contained within a single "registration" element; it cannot be spread across multiple "registration" elements within a document. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are two attributes associated with the "reginfo" element, both of which MUST be present: version: This attribute allows the recipient of registration information documents to properly order them. Versions start at 0, and increment by one for each new document sent to a subscriber. Versions are scoped within a
subscription. Versions MUST be representable using a 32 bit integer. state: This attribute indicates whether the document contains the full registration state, or whether it contains only information on those registrations which have changed since the previous document (partial). Note that the document format explicitly allows for conveying information on multiple addresses-of-record. This enables subscriptions to groups of registrations, where such a group is identified by some kind of URI. For example, a domain might define sip:email@example.com as a subscribable resource that generates notifications when the state of any address-of-record in the domain changes. The "registration" element has a list of any number of "contact" sub-elements, each of which contains information on a single contact. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are three attributes associated with the "registration" element, all of which MUST be present: aor: The aor attribute contains a URI which is the address-of- record this registration refers to. id: The id attribute identifies this registration. It MUST be unique amongst all other id attributes present in other registration elements conveyed to the subscriber within the scope of their subscription. In particular, if two URI identifying an address-of-record differ after their canonicalization according to the procedures in step 5 of Section 10.3 of RFC 3261 , the id attributes in the "registration" elements for those addresses-of-record MUST differ. Furthermore, the id attribute for a "registration" element for a particular address-of-record MUST be the same across all notifications sent within the subscription. state: The state attribute indicates the state of the registration. The valid values are "init", "active" and "terminated". The "contact" element contains a "uri" element, an optional "display-name" element, and an optional "unknown-param" element. Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored. There are several attributes associated with the "contact" element which MUST be present:
id: The id attribute identifies this contact. It MUST be unique amongst all other id attributes present in other contact elements conveyed to the subscriber within the scope of their subscription. In particular, if the URI for two contacts differ (based on the URI comparison rules in RFC 3261 ), the id attributes for those contacts MUST differ. However, unlike the id attribute for an address- of-record, if the URI for two contacts are the same, their id attributes SHOULD be the same across notifications. This requirement is at SHOULD strength, and not MUST strength, since it is difficult to compute such an id as a function of the URI without retaining additional state. No hash function applied to the URI can, in fact, meet a MUST requirement. This is because equality of the SIP URI is not transitive. However, a hash function which includes unknown URI parameters (that is, any not defined in RFC 3261), will always result in a value that is the different if two URI are different, and usually the same if the URI are equal. state: The state attribute indicates the state of the contact. The valid values are "active" and "terminated". event: The event attribute indicates the event which caused the contact state machine to go into its current state. Valid values are registered, created, refreshed, shortened, expired, deactivated, probation, unregistered and rejected. If the event attribute has a value of shortened, the "expires" attribute MUST be present. It contains an unsigned long integer which indicates the number of seconds remaining until the binding is due to expire. This attribute MAY be included with any event attribute value for which the state of the contact is active. If the event attribute has a value of probation, the "retry-after" attribute MUST be present. It contains an unsigned long integer which indicates the amount of seconds after which the owner of the contact is expected to retry its registration. The optional "duration-registered" attribute conveys the amount of time that the contact has been bound to the address-of-record, in seconds. The optional "q" attribute conveys the relative priority of this contact compared to other registered contacts. The optional "callid" attribute contains the current Call-ID carried in the REGISTER that was last used to update this contact, and the optional "cseq" attribute contains the last CSeq value present in a REGISTER request that updated this contact value.
The "uri" element contains the URI associated with that contact. The "display-name" element contains the display name for the contact. The "display-name" element MAY contain the xml:lang attribute to indicate the language of the display name. The "unknown-param" element is used to convey contact header field parameters that are not specified in RFC 3261. One example are the user agent capability parameters specified in . Each "unknown- param" element describes a single contact header field parameter. The name of the parameter is contained in the mandatory name attribute of the "unknown-param" element, and the value of the parameter is the content of the "unknown-param" element. For contact header field parameters that have no value, the content of the "unknown-param" element is empty.
each "contact" element. If the reginfo contains partial state, as indicated by the value of the "state" attribute in the "reginfo" element, the document is used to update the existing tables. For each "registration" element, the subscriber checks to see if a table exists for that registration. This check is done by comparing the value in the "id" attribute of the "registration" element with the ID associated with the table. If a table doesn't exist for that registration, one is created. For each "contact" element in the registration, the subscriber checks to see whether a row exists for that contact. This check is done by comparing the ID in the "id" attribute of the "contact" element with the ID associated with the row. If the contact doesn't exist in the table, a row is added, and its state is set to the information from that "contact" element. If the contact does exist, its state is updated to be the information from that "contact" element. If a row is updated or created, such that its state is now terminated, that entry MAY be removed from the table at any time.
</xs:simpleType> </xs:attribute> </xs:complexType> </xs:element> <xs:element name="contact"> <xs:complexType> <xs:sequence> <xs:element name="uri" type="xs:anyURI"/> <xs:element name="display-name" minOccurs="0"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute ref="xml:lang" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="unknown-param" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="name" type="xs:string" use="required"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="state" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="active"/> <xs:enumeration value="terminated"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="event" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="registered"/> <xs:enumeration value="created"/> <xs:enumeration value="refreshed"/> <xs:enumeration value="shortened"/> <xs:enumeration value="expired"/> <xs:enumeration value="deactivated"/> <xs:enumeration value="probation"/>
<xs:enumeration value="unregistered"/> <xs:enumeration value="rejected"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="duration-registered" type="xs:unsignedLong"/> <xs:attribute name="expires" type="xs:unsignedLong"/> <xs:attribute name="retry-after" type="xs:unsignedLong"/> <xs:attribute name="id" type="xs:string" use="required"/> <xs:attribute name="q" type="xs:string"/> <xs:attribute name="callid" type="xs:string"/> <xs:attribute name="cseq" type="xs:unsignedLong"/> </xs:complexType> </xs:element> </xs:schema> User Registrar Application | |(1) SUBSCRIBE | | |Event:reg | | |<------------------| | |(2) 200 OK | | |------------------>| | |(3) NOTIFY | | |------------------>| | |(4) 200 OK | | |<------------------| |(5) REGISTER | | |------------------>| | |(6) 200 OK | | |<------------------| | | |(7) NOTIFY | | |------------------>| | |(8) 200 OK | | |<------------------| |(9) MESSAGE | | |<--------------------------------------| Figure 3: Example Call Flow
This section provides an example call flow, shown in Figure 3. It shows an implementation of the welcome notice application described in Section 3.3. First, the application SUBSCRIBEs to the registration event package for the desired user (1): SUBSCRIBE sip:firstname.lastname@example.org SIP/2.0 Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7 From: sip:app.example.com;tag=123aa9 To: sip:email@example.com Call-ID: firstname.lastname@example.org CSeq: 9887 SUBSCRIBE Contact: sip:app.example.com Event: reg Max-Forwards: 70 Accept: application/reginfo+xml The registrar (which is acting as the notifier for the registration event package) generates a 200 OK to the SUBSCRIBE: SIP/2.0 200 OK Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds7 ;received=192.0.2.1 From: sip:app.example.com;tag=123aa9 To: sip:email@example.com;tag=xyzygg Call-ID: firstname.lastname@example.org CSeq: 9987 SUBSCRIBE Contact: sip:server19.example.com Expires: 3600 The registrar then generates a notification (3) with the current state. Since there is no active registration, the state of the registration is "init": NOTIFY sip:app.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:email@example.com;tag=xyzygg To: sip:app.example.com;tag=123aa9 Call-ID: firstname.lastname@example.org CSeq: 1288 NOTIFY Contact: sip:server19.example.com Event: reg Max-Forwards: 70 Content-Type: application/reginfo+xml Content-Length: ...
<?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0" state="full"> <registration aor="sip:email@example.com" id="a7" state="init" /> </reginfo> Later on, the user registers (5): REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnaaff From: sip:firstname.lastname@example.org;tag=99a8s To: sip:email@example.com Call-ID: firstname.lastname@example.org CSeq: 9976 REGISTER Contact: sip:email@example.com This results in a NOTIFY being generated to the application (7): NOTIFY sip:app.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij From: sip:firstname.lastname@example.org;tag=xyzygg To: sip:app.example.com;tag=123aa9 Call-ID: email@example.com CSeq: 1289 NOTIFY Contact: sip:server19.example.com Event: reg Max-Forwards: 70 Content-Type: application/reginfo+xml Content-Length: ... <?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="1" state="partial"> <registration aor="sip:firstname.lastname@example.org" id="a7" state="active"> <contact id="76" state="active" event="registered" duration-registered="0"> <uri>sip:email@example.com</uri> </contact> </registration> </reginfo>
The application can then send its instant message to the device (9): MESSAGE sip:firstname.lastname@example.org SIP/2.0 Via: SIP/2.0/UDP app.example.com;branch=z9hG4bKnashds8 From: sip:app.example.com;tag=123aa10 To: sip:email@example.com Call-ID: firstname.lastname@example.org CSeq: 82779 MESSAGE Max-Forwards: 70 Content-Type: text/plain Content-Length: ... Welcome to the example.com service! RFC 3265 , and those considerations apply here. Registration information is sensitive, potentially private, information. Subscriptions to this event package SHOULD be authenticated and authorized according to local policy. Some policy guidelines are suggested in Section 4.6. In addition, notifications SHOULD be sent in such a way to ensure confidentiality, message integrity and verification of subscriber identity, such as sending subscriptions and notifications using a SIPS URL or protecting the notification bodies with S/MIME.
RFC 3023 . Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 . Security considerations: See Section 10 of RFC 3023  and Section 7 of this specification. Interoperability considerations: none. Published specification: This document. Applications which use this media type: This document type is being used in notifications to alert SIP user agents that their registrations have expired and must be redone. Additional Information: Magic Number: None File Extension: .rif or .xml Macintosh file type code: "TEXT" Personal and email address for further information: Jonathan Rosenberg, <email@example.com> Intended usage: COMMON Author/Change controller: The IETF.
7]. URI: The URI for this namespace is urn:ietf:params:xml:ns:reginfo. Registrant Contact: IETF, SIMPLE working group, <firstname.lastname@example.org>, Jonathan Rosenberg <email@example.com>. XML: BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Registration Information Namespace</title> </head> <body> <h1>Namespace for Registration Information</h1> <h2>urn:ietf:params:xml:ns:reginfo</h2> <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc3680.txt"> RFC3680</a>.</p> </body> </html> END  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.  Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.  Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
 W. W. W. C. (W3C), "Extensible markup language (xml) 1.0." The XML 1.0 spec can be found at http://www.w3.org/TR/1998/REC-xml-19980210.  Moats, R., "URN Syntax", RFC 2141, May 1997.  Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.  Murata, M., St. Laurent, S. and D. Kohn, "XML media types", RFC 3023, January 2001.  Rosenberg, J., "Session initiation protocol (SIP) extensions for presence", Work In Progress.  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.  Schulzrinne, H. and J. Rosenberg, "Session initiation protocol (SIP) caller preferences and callee capabilities", Work In Progress.  Mayer, G. and M. Beckmann, "Registration event package", Work In Progress.
12]. They can be contacted at: Georg Mayer Siemens AG Hoffmannstr. 51 Munich 81359 Germany EMail: Georg.Mayer@icn.siemens.de Mark Beckmann Siemens AG P.O. Box 100702 Salzgitter 38207 Germany EMail: Mark.Beckmann@siemens.com Rohan Mahy provided editorial work in order to progress this specification. His contact address is: Rohan Mahy Cisco Systems 170 West Tasman Dr, MS: SJC-21/3/3 Phone: +1 408 526 8570 EMail: firstname.lastname@example.org
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 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 email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.