SIP D. Worley Internet-Draft Pingtel Expires: August 28, 2007 February 24, 2007 Response Codes Regarding URIs that Cannot Be Routed to a Destination in the Session Initiation Protocol (SIP) draft-worley-ex-uri-00 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 August 28, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Worley Expires August 28, 2007 [Page 1] Internet-Draft Ex-URIs February 2007 Abstract The Session Initiation Protocol (SIP) provides a number of response codes which a SIP agent can use to indicate that it cannot find a suitable destination to which to send a request. Unfortunately, this set of response codes was not carefully designed, making it difficult in many cases for a proxy to select a response code that accurately reflects the proxy's knowledge about the request URI. This document describes these response codes and their current usage. Table of Contents 1. The Current Response Codes . . . . . . . . . . . . . . . . . . 3 1.1. 404 Not Found . . . . . . . . . . . . . . . . . . . . . . 3 1.2. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. 480 Temporarily Unavailable . . . . . . . . . . . . . . . 3 1.4. 604 Does Not Exist Anywhere . . . . . . . . . . . . . . . 4 2. Examples in RFCs . . . . . . . . . . . . . . . . . . . . . . . 5 3. Deficiencies . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Worley Expires August 28, 2007 [Page 2] Internet-Draft Ex-URIs February 2007 1. The Current Response Codes This section lists the existing response codes that can be used by an agent to indicate that it cannot find a destination for a request- URI, and their definitions in [1]. 1.1. 404 Not Found The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request. It is not clear what the statement "the user does not exist at the domain" means. If it were to just mean that the agent has no contacts for the request-URI, then it would be redundant, since if there were contact points, no 4xx class response would be generated. So it appears to be intended that the agent should have a database of "existing users", some of which might not have contact points at presenct, and the 404 response means that the user-part of the request-URI was in the database. 1.2. 410 Gone The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. The 410 response indicates that the agent has no contact for the request-URI and that it has knowledge that it will not have a contact in the future. 1.3. 480 Temporarily Unavailable The callee's end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the "do not disturb" feature). The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere (unbeknownst to this server). The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be settable by the UA. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure. Worley Expires August 28, 2007 [Page 3] Internet-Draft Ex-URIs February 2007 This status is also returned by a redirect or proxy server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user. It is not clear what is meant by "not logged in", as the obvious meaning for "logged in" would be "having a registered contact". But given that it says "the callee's end system was contacted successfully", it seems that the 480 response is to be used by a UA to indicate "do not disturb" status and similar situations. Within this interpretation, the 480 response is not to be used by proxies, only UAs. 1.4. 604 Does Not Exist Anywhere The server has authoritative information that the user indicated in the Request-URI does not exist anywhere. This description is similar to the description of the 404 response in that it talks of the "existence" of "users". But it suffers from the deficiency of all 6xx class responses, in that it terminates all forks of the request, and an agent cannot have the knowledge needed to do so legitimately, because it cannot know the URIs through which the request was forwarded to it. Worley Expires August 28, 2007 [Page 4] Internet-Draft Ex-URIs February 2007 2. Examples in RFCs Some examples of the problematic 480 response code are given in RFCs: [2] shows two examples: (1) a proxy responding 480 to report that it got no response from the destination UA, and (2) a UA responding 480 to report unwillingness to take the call (reason unspecified). (The first example seems incorrect, and I wonder if it should have been 408?) [3], [4], and [5] show response code 480 to report a variety of call failure situations (including "ring no answer") in interworking with the PSTN. The caller preferences system ([6] and [7]) uses a 480 response that there are no acceptable contacts according to the caller preferences in the request. Worley Expires August 28, 2007 [Page 5] Internet-Draft Ex-URIs February 2007 3. Deficiencies Setting aside the 604 response (because it is a 6xx class response), we have the 404, 410, and 480 responses for use by proxies. The first deficiency is that both of these responses assert more than that there is no contact for the request-URI. The 404 response asserts that the request-URI identifies a user, and that user is not contained in a defined set of users. The 410 response asserts that there will not be a contact for the request-URI in the future as well. The 480 response appears to assert that the identified user is contained in a defined set of users. The result is that there is no way for an agent to assert the absence of contacts for a request-URI without asserting additional facts about the request-URI (which it may not possess). Worley Expires August 28, 2007 [Page 6] Internet-Draft Ex-URIs February 2007 4. Security Considerations The only known security consideration for this topic is a matter of privacy: When a call is not routable to a destination, the response code may provide more information about the targeted user than just the fact of non-routability. Under some circumstances, this might be a breach of the user's privacy. Worley Expires August 28, 2007 [Page 7] Internet-Draft Ex-URIs February 2007 5. Normative References [1] 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. [2] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", RFC 3665, BCP 75, December 2003. [3] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002. [4] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows", RFC 3666, BCP 76, December 2003. [5] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, "Interworking between the Session Initiation Protocol (SIP) and QSIG", RFC 4497, BCP 117, May 2006. [6] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [7] Rosenberg, J. and P. Kyzivat, "Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension", RFC 4596, July 2006. Worley Expires August 28, 2007 [Page 8] Internet-Draft Ex-URIs February 2007 Author's Address Dale R. Worley Pingtel Corp. 400 West Cummings Park, Suite 2200 Woburn, MA 01801 US Phone: +1 781 938 5306 x173 Email: dworley@pingtel.com URI: http://www.pingtel.com Worley Expires August 28, 2007 [Page 9] Internet-Draft Ex-URIs February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Worley Expires August 28, 2007 [Page 10]