Internet Engineering Task Force Jun Koshiko Internet Draft NTT East Corporation Expiration: August 14th, 2005 File: draft-koshiko-sipping-reason-indicating-locations-01.txt Extending the Session Initiation Protocol Reason Header for Indicating Message Source February 14th, 2005 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to indicate the location of the SIP element which issued a certain SIP message. This capability enables many enhanced services by providing the information as to how and why a SIP message arrives at a specific application, user, or proxy server. This draft defines new reason-params for the protocol field of the Reason header field in RFC3326 [1]. Koshiko [Page 1] Internet Draft Reason Header for Location Response Source Feb 14th,2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Message Source Indication . . . . . . . . . . . . . . . . . 3 3.1 Example1: Location Indication of a 503 Message . . . . 5 3.1.1 A 503 response message from a proxy server . . . . . 5 3.1.2 A 503 response message from a UAS . . . . . . . . . . 6 3.2 Example2: Location Indication of a CANCEL request message . . . . . . . . . . . . . . . 8 3.2.1 A CANCEL request message from a proxy server . . . . 8 3.2.2 A CANCEL request message from a user agent client . . 11 3.3 Example3: Load balancing by using a 503 message with domains indicator . . . . . . . . . . . . . . 12 3.3.1 A 503 response message with listed service unavailable domains . . . . . . . . . . . . . . . . . 13 4. Security Consideration . . . . . . . . . . . . . . . . . . . 14 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 15 6. Normative Reference . . . . . . . . . . . . . . . . . . . . 15 7. Author Information . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The same SIP [1] message can be issued by different types of network element such as a UA, a proxy and the like. And with SIP[1], there is nothing to indicate the type of the network element that has issued the message, so messages from the network elements of different types are treated as same ones. But some users or applications may desire to know the location of the network element that issued the message. For example, if a uac received a 503 (Service Unavailable) message, which means that the server is temporarily unable to process the request due to a temporary overloading or maintenance of the server, it may choice the alternative server or route of a SIP message depending on the location (a proxy, a UA or the like) where the message has issued originally. As another example, when a UAS would receive a CANCEL request message and would stop session establishment, a user who uses a UAS may desire to know that the session closing was performed by a UAC, a proxy, or a non-ip based network inter-worked through a SIP gateway. To meet this demand, this document proposes the an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header and defines new protocol params, reason-location and reason-domain. Koshiko [Page 2] Internet Draft Reason Header for Location Response Source Feb 14th,2005 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. 3. Message Source Indication This document defines the following new reason-params value as a reason-extension for the protocol field of the Reason header field in RFC 3326 [1]. You may use this extension parameters combining with reason-params, or use only this extension independently on reason-params prescribed by RFC3326. RFC3326 [1] defines Reason-Header field as following: Reason = "Reason" HCOLON reason-value *(COMMA reason-value) reason-value = protocol *(SEMI reason-params) protocol = "SIP" / "Q.850" / token reason-params = protocol-cause / reason-text / reason-extension protocol-cause = "cause" EQUAL cause cause = 1*DIGIT reason-text = "text" EQUAL quoted-string reason-extension = generic-param This document defines two reason-params (reason-location, reason-domain). BNF definition is as followings: reason-params = reason-location / reason-domain reason-location = "location" EQUAL DQUOTE location-params DQUOTE location-params = "uac" / "uas" / "proxy" / "non-ip" / q.850-location-params reason-domain = "domain" EQUAL DQUOTE reason-domain-param *(COMMA reson-domain-param) DQUOTE reason-domain-param = host (HCOLON other-param) host = hostname / IPv4address / IPv6reference hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum other-param = token This fields would be used in order to indicate the location of the SIP element which issued the SIP message. Reason-location parameter means the type of network element which issued the SIP message. As Koshiko [Page 3] Internet Draft Reason Header for Location Response Source Feb 14th,2005 location-params, "uac", "uas", "proxy", "non-ip", q.850-location-params have been defined. Q.850-location-params means location parameter field value defined by ITU-T Q.850 [5]. Especially, if the reason-protocol value is "Q.850", location parameters SHOULD be of location parameters defined by ITU-T Q.850. The following values for location field have been defined: Location-params Description ---------------------------------------------------------------------- "uac" This value indicate that the message has been issued by a user agent client. "uas" This value indicate that the message has been issued by a user agent server. "proxy" This value indicate that the message has been issued by a proxy server. "non-ip" The message has been issued by a SIP gateway because it had received message by a Non-IP based network inter-working through a SIP gateway. q.850-location-params This message has been issued on a location which is indicated by location-parameter defined by ITU-T Q.850 [5]. Meanings of each location-parameter values follows the description of ITU-T Q.850 [5]. The reason-domain parameter is for indicating the domain name to which network element belongs. It is a optional parameter. You MAY use it with a reason-location parameter or not. Example syntax is as follows: Reason: SIP ; location="uac" Reason: SIP ; location="uas" ;domain="pc22.biloxi.example" Reason: SIP ; cause=503 ;text="Service Unavailable" ;location="proxy" ;domain="atlanta.example" Reason: SIP ; cause=408 ;text="Request Timeout" ;location="non-ip" ;domain="gw.atlanta.example" Reason: SIP ; cause=503 ;text="Service Unavailable" ;location="proxy" ;domain="beta.example:line1,gamma.example:line2" Sections 3.1, 3.2 and 3.3 provide uses cases and extended definitions for the above cause codes with message flow diagrams. Koshiko [Page 4] Internet Draft Reason Header for Location Response Source Feb 14th,2005 3.1 Example1: Location Indication of a 503 Message In this section, the example of location indication of a 503 service unavailable message has been described. A 503 response message means that a service is unavailable because of a temporary overload or a maintenance on a certain network element. And RFC3261[1] says that a client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. In such a case, the client may desire to recognize where the temporary overload or a maintenance occers when it decides the substitute destination to which it attempt to re-transmit the request. Reason-parameter extension of the Reason Header proposed in this document assumes using in such cases. A network element which issued the 503 response message would indicate the location on the reason-location field and the domain name on the reason-domain field, and the client would know the location where the temporary overload or the maintenance has occured alerted by the 503 response message. In the followings, we'll consider about the example of the SIP network consist of two proxy servers (atlanta.example, biloxi.example) and two UAs (alice, bob). 3.1.1 A 503 response messages from a proxy server A 503 response message for an INVITE may be issued by the proxy. In the 503 response messages, "proxy" is set on reason-location parameter field value, which means the message is issued by a proxy server. As previously assumed, on the network which includes more than one proxy servers, you may write the domain name, which indicates a certain proxy server, as a reason-domain parameter field value on the Reason Header. In the following example, in order to distinguish the 503 response message gerenated by atlanta.example, and the one generated by biloxi.example, the value of a reason-domain paramter value is changed. It is the 503 response messages from proxy server with the domain name of atlanta.example that the value of a domain parameter is "atlanta.example", and it means that a temporary overload or a maintenance have occurred in proxy server of atlanta.example. (See the following figure 3.1) Koshiko [Page 5] Internet Draft Reason Header for Location Response Source Feb 14th,2005 UAC Proxy Proxy UAS (alice) atlanta.example biloxi.example (bob) | | | | |INVITE bob@biloxi.example | | |------------->| | | | 503 Service Unavailable | | | Reason: SIP cause=503 ;text="Service Unavailable" | ;location="proxy"; domain="atlanta.example"| |<-------------| | | | | | | figure3.1 A 503 response message from proxy (atlanta.example) Moreover, if the value of a domain parameter is "biloxi.example", it means that the message has issued by a proxy of which domain name is biloxi.example. In this case, an temporary overload or a maintenance have occurred at biloxi.example and the service is not available. (See the following figure 3.2) UAC Proxy Proxy UAS (alice) atlanta.example biloxi.example (bob) | | | | | INVITE bob@biloxi.example | | |------------->| | | | | INVITE bob@biloxi.example | | |------------->| | | | 503 Service Unavailable | | | Reason: SIP cause=503 ;text="Service Unavailable" | | ;location="proxy"; domain="biloxi.example" | |<-------------| | | 503 Service Unavailable | | | Reason: SIP cause=503 ;text="Service Unavailable" | ;location="proxy"; domain="biloxi.example" | |<-------------| | | | | | | figure3.2 A 503 response message from proxy (biloxi.example) A value of a reason-domain parameter field would be decided depending on a local policy. Number of proxy servers MAY set the same value on a reason-domain parameter field. 3.1.2 A 503 response messages from a UAS A 503 response message for an INVITE may be issued by a user agent server (UAS). In the 503 response messages, "uas" is set on reason-location parameter field value, which means the message is issued by a UAS. (See the following figure3.3) Koshiko [Page 6] Internet Draft Reason Header for Location Response Source Feb 14th,2005 You would get to know that there is no meaning in trying in order that the client which received these 503 response messages may reach this UAS via another relay proxy server as substitution. UAC Proxy Proxy UAS (alice) atlanta.example biloxi.example (bob) | | | | | INVITE bob@biloxi.example | | |------------->| | | | | INVITE bob@biloxi.example | | |------------->| | | | | INVITE bob@pc22.biloxi.example | | |------------->| | | | 503 Service Unavailable | | | Reason: SIP cause=503 | | | ;text="Service Unavailable" | | | ;location="UAS" | | | ;domain="pc22.biloxi.example" | | |<-------------| | | 503 Service Unavailable | | | Reason: SIP cause=503 | | | ;text="Service Unavailable" | | | ;location="uas" | | | ;domain="pc22.biloxi.example" | |<-------------| | | 503 Service Unavailable | | | Reason: SIP cause=503 | | | ;text="Service Unavailable" | | | ;location="uas" | | | ;domain="pc22.biloxi.example" | |<-------------| | | | | | | figure 3.3 A 503 response message from a UAS Moreover, consider the case where a UAS acts as gateway to inter-work with network on another protocol. In the case that the temporary overload occured on the network on another protocol, the flow would be as the following figure.(See the following figure 3.4) Here, the domain of a gateway assumed to be "gw.biloxi.example" By this message, a UAC will know that an overload or a maintenance will be performed with a non-ip element. When a client performs access to substitute service, it may choose a path in consideration of being accessed to a different non-ip element. Koshiko [Page 7] Internet Draft Reason Header for Location Response Source Feb 14th,2005 UAC Proxy Proxy UAS/GW non-ip (alice) atlanta.example biloxi.example gw.biloxi.example network | | | | | | INVITE | | | | |------------->| | | | | | INVITE | | | | |------------->| | | | | | INVITE | | | | |------------->| | | | | |************| | | | |* Service *| | | | |* Un- *| | | | |* available*| | | | |* on the *| | | | |* non-ip *| | | | |* network *| | | | |************| | | | 503 Service Unavailable | | | | Reason: SIP cause=503 | | | | ;text="Service Unavailable" | | | ;location="non-ip" | | | | ;domain="gw.biloxi.example" | | |<-------------| | | | 503 Service Unavailable | | | | Reason: SIP cause=503 | | | | ;text="Service Unavailable" | | | | ;location="non-ip" | | | | ;domain="gw.biloxi.example" | | | |<-------------| | | | 503 Service Unavailable | | | | Reason: SIP cause=503 | | | | ;text="Service Unavailable" | | | | ;location="non-ip" | | | | ;domain="gw.biloxi.example" | | | |<-------------| | | | | | | | | figure 3.4 A 503 response message from a gateway 3.2 Example2: Location Indication of a CANCEL request message In this section, the example of location indication of a CANCEL request message has been described. In a Proxy server or UAS, when a timer (for example, timer C) is completed, a CANCEL message may be published and a session may be terminated. And these CANCEL messages may be issued by both UACs and proxy servers. The new parameter of a Reason header enables it to indicate the location of message source. Koshiko [Page 8] Internet Draft Reason Header for Location Response Source Feb 14th,2005 3.2.1 A CANCEL request messages from a proxy server A CANCEL message may be issued by the proxy server. In a CANCEL message, if the value of the location parameter by Reason header extension is "proxy", it would indicate that the message is issued by a proxy server. As previously assumed, on the network which includes more than one proxy servers, you may write the domain name, which indicates a certain proxy server, as a reason-domain parameter field value on the Reason Header. In the following example, in order to distinguish the CANCEL request message issued by atlanta.example, and the one issued by biloxi.example, the value of a reason-domain paramter value is changed. It is the 503 response messages from proxy server with the domain name of atlanta.example that the value of a domain parameter is "atlanta.example", and it means that a timeout or user cancelation have occurred on proxy server of atlanta.example. (See the following figure 3.5) UAC Proxy Proxy UAS (alice) atlanta.example biloxi.example (bob) | | | | | INVITE bob@biloxi.example | | |------------->| | | | | INVITE bob@biloxi.example | | 100 Trying |------------->| | |<-------------| | INVITE bob@biloxi.example | | 100 Trying |------------->| | |<-------------| 180 Ringing | | | 180 Ringing |<-------------| | 180 Ringing |<-------------| | |<-------------|*** | | | |*T* | | | |*i* | | | |*m* | | | |*e* | | | |*r* | | | |* * | | | |*C* | | | |*** | | | Request Timeout | | | | | | | | CANCEL | | | | Reason: SIP | | | | ;location="proxy" | | | ;domain="atlanta.example" | | |------------->| | | 408 Request Timeout | | | Reason: SIP cause=408 | | | ;text="Request Timeout" | | | ;location="proxy" | | | ;domain="atlanta.example" | | |<-------------| | | Koshiko [Page 9] Internet Draft Reason Header for Location Response Source Feb 14th,2005 | ACK | | | |------------->| 200 OK | | | |<-------------| | | | | CANCEL | | | | Reason: SIP | | | | ;location="proxy" | | | ;domain="atlanta.example" | | |------------->| | | | 200 OK | | | |<-------------| | | | 487 Request Terminated | | |<-------------| | | | ACK | | | |------------->| | | 487 Request Terminated | | |<-------------| | | | ACK | | | |------------->| | figure3.5 A CANCEL request from a proxy server (atlanta.example) Moreover, in the proxy of biloxi.example, when a CANCEL request is issued, the sequence would be as figure 3.6. UAC Proxy Proxy UAS (alice) atlanta.example biloxi.example (bob) | | | | | INVITE bob@biloxi.example | | |------------->| | | | | INVITE bob@biloxi.example | | 100 Trying |------------->| | |<-------------| | INVITE bob@biloxi.example | | 100 Trying |------------->| | |<-------------| 180 Ringing | | | 180 Ringing |<-------------| | 180 Ringing |<-------------| | |<-------------| | | | | |*** | | | |*T* | | | |*i* | | | |*m* | | | |*e* | | | |*r* | | | |* * | | | |*C* | | | |*** | | | Request Timeout | | | | | Koshiko [Page 10] Internet Draft Reason Header for Location Response Source Feb 14th,2005 | | | CANCEL | | | | Reason: SIP | | | | ;location="proxy" | | | ;domain="biloxi.example" | | |------------->| | | | 200 OK | | | |<-------------| | | | 487 Request Terminated | | |<-------------| | | | ACK | | | |------------->| | | 408 Request Timeout | | | Reason: SIP cause=408 | | | ;text="Request Timeout" | | | ;location="proxy" | | | ;domain="biloxi.example" | | |<-------------| | | | ACK | | | |------------->| | | 408 Request Timeout | | | Reason: SIP cause=408 | | | ;text="Request Timeout" | | | ;location="proxy" | | | ;domain="biloxi.example" | | |<-------------| | | | ACK | | | |------------->| | | figure3.6 A CANCEL message from a proxy server (biloxi.example) 3.2.2 A CANCEL message from a user agent client A CANCEL message may be issued by a user agent client. If the value of the location parameter by Reason header extension in a CANCEL message is "uac", it would indicate that the message is issued by a user agent server. UAC Proxy Proxy UAS (alice) atlanta.example biloxi.example (bob) | | | | | INVITE bob@biloxi.example | | |------------->| | | | | INVITE bob@biloxi.example | | 100 Trying |------------->| | |<-------------| | INVITE bob@biloxi.example | | 100 Trying |------------->| | |<-------------| 180 Ringing | | | 180 Ringing |<-------------| | 180 Ringing |<-------------| | |<-------------| | | Koshiko [Page 11] Internet Draft Reason Header for Location Response Source Feb 14th,2005 | | | | | CANCEL | | | | Reason: SIP | | | | ;location="uac" | | | ;domain="pc12.atlanta.example" | |------------->| | | | 200 OK | | | |<-------------| | | | | CANCEL | | | | Reason: SIP | | | | ;location="uac" | | | ;domain="pc12.atlanta.example" | |------------->| | | | 200 OK | | | |<-------------| | | | | CANCEL | | | | Reason: SIP | | | | ;location="uac" | | | ;domain="pc12.atlanta.example" | | |------------->| | | | 200 OK | | | |<-------------| | | | 487 Request Terminated | | |<-------------| | | | ACK | | | |------------->| | | 487 Request Terminated | | |<-------------| | | | ACK | | | |------------->| | | 487 Request Terminated | | |<-------------| | | | ACK | | | |------------->| | | figure3.7 A CANCEL message from a UAC (pc12.atlanta.example) 3.3 Example3: Load balancing by using a 503 message with domains indicator In this section, the example of load balancing by using a 503 service unavailable message with domains indicator has been described. Koshiko [Page 12] Internet Draft Reason Header for Location Response Source Feb 14th,2005 A 503 response message with reason-extension domain indicator means that listed domains are service unavailable domains because of a temporary overload or a maintenance on a certain network element. And RFC3261[1] says that a client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. In such a case, the Proxy which performs a load sharing on the network may want to know which domain is under temporary overload or maintenance. Reason-parameter extension of the Reason Header proposed in this document assumes using in such cases. When a Proxy which performs a load sharing receives a 503 response message with reason-extension domain indicator, a Proxy recognizes the direction, which the request message gets the response with listed service unavailable domains, can't receive more request to the domain and a request message to that domains should be detoured. In the followings, we'll consider about the example of the SIP network consist of a proxy which performs load sharing, and two proxies which connect some domains (alfa.example, beta.example, gamma.example). And a domain (beta.example) is connected from both proxies. 3.3.1 A 503 response message with listed service unavailable domains A 503 response message for an INVITE may be issued by the proxy. In the 503 response messages, "proxy" is set on reason-location parameter field value, which means the message is issued by a proxy server. As previously assumed, on the network which includes load sharing proxy and two proxies which connect some domains respectively, you may write the domain name, which indicates a certain proxy server can't connect to, as a reason-domain parameter field value on the Reason Header. In the following example, at the Proxy A which performs load sharing, the request message to "beta.example" is sent with a certain ratio to Proxy B and Proxy C. When the Proxy B detects that connection with domain "beta.example" is temporary overload, a 503 response with reason-extension and unavailable domain list should be answered. (See the following figure 3.8) Koshiko [Page 13] Internet Draft Reason Header for Location Response Source Feb 14th,2005 UAC Proxy A Proxy B Proxy C UAS (alice) (Load sharing) (alfa.example) (beta.example) (bob) (beta.example) (gamma.example) (beta.example) | | | | | |INVITE bob@beta.example | | | |------------->|INVITE bob@beta.example | | | |------------->| | | | | 503 Service Unavailable | | | | Reason: SIP cause=503 ;text="Service Unavailable" | | ;location="proxy"; domain="alfa.example,beta.example" | |<-------------| | | | | | | | figure3.8 A 503 response message with listed service unavailable domains from proxy B. When the Proxy A receives a 503 response message with unavailable domain list which contains domain "beta.example", the Proxy A changes the connecting ratio to domain "beta.example". The change period of a connecting ratio to listed domains may be specified with Retry-After header value. Moreover, if the value of a domain parameter is "beta.example", a temporary overload or a maintenance have occurred at "beta.example" and the service is not available through Proxy B. The Proxy A changes route to domain "beta.example" throgh Proxy C. (See the following figure 3.9) UAC Proxy Proxy Proxy UAS (alice) (Load sharing) (alfa.example) (beta.example) (bob) (beta.example) (gamma.example) (beta.example) | | | | | |INVITE bob@beta.example | | | |------------->|INVITE bob@beta.example | | | |---------------------------->|INVITE bob@beta.example | | | |------------->| figure3.9 Proxy A changes route to domain "beta.example". Furthermore, reason-domain-param has the value of other-param as extension. In addition, other-param can be used for implicit value. 4. Security Consideration Establishment of a session may be impossible if an unexpected change is made to the contents of the Reason header or an unsuitable value is set with malicious intent as them by spoofing. It is RECOMMENDED that the contents of the Reason header would be secured by a certain mechanism. Koshiko [Page 14] Internet Draft Reason Header for Location Response Source Feb 14th,2005 5. IANA Consideration RFC [XXXX} (this document) proposes the new SIP "Reason Header" [1] reason-extension: "location" with 5 defined values and "domain": In instances where this reason-extension is used to indicate that message is caused by UAC, the following syntax shall be used: Reason: SIP ; location="uac" In instances where this reason-extension is used to indicate that message is caused by UAS, the following syntax shall be used: Reason: SIP ; location="uas" In instances where this reason-extension is used to indicate that message is caused by proxy whose domain is "biloxy.com", the following syntax shall be used: Reason: SIP ; location="proxy" ;domain="biloxy.com" In instances where this reason-extension is used to indicate that message is caused by redirect server whose domain is "atlanta.example", the following syntax shall be used: Reason: SIP ; location="proxy" ;domain="atlanta.example" In instances where this reason-extension is used to indicate that message is caused by SIP gateway whose domain is "gw.atlanta.example", the following syntax shall be used: Reason: SIP ; location="proxy" ;domain="gw.atlanta.example" 6. Normative References [1] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header for the Session Initiation Protocol (SIP)", RFC 3326. [2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, March 1997. Koshiko [Page 15] Internet Draft Reason Header for Location Response Source Feb 14th,2005 7. Author Information Jun Koshiko NTT East Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan j.koshiko@rdc.east.ntt.co.jp Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. The Expiration date for this Internet Draft is: August 14th, 2005 Koshiko [Page 16]