Network Working Group R. Sparks Internet-Draft dynamicsoft Expires: May 22, 2002 November 21, 2001 Obtaining Responses to a Forked Request draft-sparks-sip-fu-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 22, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This draft explores an extension to SIP elements that results in ALL final responses to a forked requests being returned to the requester. Sparks Expires May 22, 2002 [Page 1] Internet-Draft Obtaining Responses to a Forked Request November 2001 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Forked SUSBCRIBEs . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Aggregating error response . . . . . . . . . . . . . . . . . . 4 3. The fu Extension . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Proxy Responsibilities . . . . . . . . . . . . . . . . . . . . 4 3.2 Client Responsibilities . . . . . . . . . . . . . . . . . . . 5 4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 Sparks Expires May 22, 2002 [Page 2] Internet-Draft Obtaining Responses to a Forked Request November 2001 1. Overview A number of scenarios have been recently discussed on the SIP-related lists where a requester needs information from every end-point responding to a forked request. This draft defines an extension wherein proxies gather all final responses to a forked request, returning them in a single multipart response. The draft defines an extension tag: fu, and a final response code 381 Multiple Responses. This draft is a thought-experiment intended to stimulate discussion - implementation of these concepts is currently not recommended. 2. Motivation Discussions on the sip, sipping, and sip-implementors lists have uncovered several situations where the responders to a forked request all have information that the original requester may need in order for the system to behave properly. 2.1 Forked SUSBCRIBEs For some events, it may be more appropriate to establish a subscription dialog with each endpoint a SUBSCRIBE request reaches. Unfortunately, only one 2xx response gets returned to the requester. Sip-events[1] provides a workaround. Each endpoint returning a 2xx response will also send an immediate NOTIFY. Depending on the event package, the requester takes one of the following approaches: Accept only the NOTIFY with the tag matching that in the 2xx to the SUBSCRIBE, rejecting all others with a 481 Accept all NOTIFYs matching the dialog identifiers except for the far-side tag, creating new dialogs, each with its own Route-set established by information in the NOTIFY. Unfortunately, if any leg returns a 2xx response, all potential NOTIFYers that may have needed more information (such as credentials) before proceeding are rendered unreachable. If every final response was returned to a SUBSCRIBE, the subscriber can choose to maintain dialogs with one or more of the endpoints returning 2xx class responses as well as take subsequent action with those returning error responses such as 3xx, 401/407 or 503. Sparks Expires May 22, 2002 [Page 3] Internet-Draft Obtaining Responses to a Forked Request November 2001 2.2 Aggregating error response The bis draft contains provisions for aggregating information from 401 and 407 responses so that subsequent requests can contain responses for challenges on all branches of a fork, not just the one branch. Without this behavior (or something like it) a proxy prevents successful signaling with the challenging entities on the other branches. Unfortunately, 401 and 407 are not the only responses that contain information that may be needed to make subsequent requests work as intended. For instance, responses like 420 Bad Extension and 415 Unsupported media type contain information that a requester can use to modify subsequent requests, potentially leading to their success. The current aggregation mechanism doesn't easily extend to cover situations where there are different causes for an error. Returning each of the responses without attempting to blend them avoids that problem. 3. The fu Extension Use of this extension is signaled through the use of the option-tag "fu" for "full understanding" 3.1 Proxy Responsibilities A stateful proxy receiving a request containing a Proxy-Require header with the "fu" tag present acts as described in the bis draft with the following exceptions: No final responses are returned immediately. On receipt of a 2xx or 6xx class response, the proxy CANCELs any pending branches and gathers final responses for them before proceeding. Once every branch has received a final response, EVERY response in the response context is modified as if it were going to be forwarded upstream. In particular, record-route processing will be applied to each response independently. The proxy returns a single 381 Multiple Responses error response with a multipart-MIME body containing each response as a separate message/sip element. (If there was only one final response in the context, it SHOULD forward just that response instead of a 381). When a proxy receives a 381 error response, it MUST retrieve each of the individual responses from the multipart body and place them in its response context. "Nested" 381 error responses MUST not be created. Sparks Expires May 22, 2002 [Page 4] Internet-Draft Obtaining Responses to a Forked Request November 2001 All other proxy processing remains the same. For example, a proxy invoking the fu extension is still free to recurse on 3xx class responses if it chooses. A stateless proxy receiving a request containing a Proxy-Require header with the "fu" tag present need only recognize the extension (i.e. not reject it with a 420). A stateless proxy will simply forward the single final response it sees. If that response is not a 381, it does not need to change it into one. If it is a 381, the proxy MUST apply its message forwarding logic to each of the embedded responses. 3.2 Client Responsibilities A requester wishing to see every final response to a request MUST include the "fu" option-tag in a Proxy-Require header field in the request. A requester receiving a 381 error response MUST process each contained response as if it were the final response to the request. This is similar to the way existing endpoints create multiple dialogs as a result of receiving multiple 200 OKs to an INVITE, but extends to every response contained in the 381. For example, if the 381 contains two 200 OKs (with tag t1 and t2), a 407 (with tag t3), and a 415 (with tag t4), the endpoint would enter into dialogs with the endpoints sending t1 and t2 (each with their own route sets), send a new request (if it wants) with credentialing information to the endpoint returning tag t3, and make some SDP changes before submitting a new request to the endpoint at t4). No changes need to be made to the responder role of an endpoint (UAS) to support this extension. 4. Limitations This extension may increase the amount of time it takes to complete a transaction, particularly if one branch returns a 2xx class response. One non-responding (in the transport sense) branch will cause a proxy to hold its response until that transaction times out, even if it already has one or more 2xx class responses ready to go. However, the majority of transactions will still complete in a timely fashion - after receiving the first 2xx, the proxy will CANCEL any outstanding legs - if the transport to those legs is not broken the net delay added before forwarding the 381 containing that 2xx is on the order of the max of the RTTs to the endpoints down any outstanding branches. In the presence of many branches, the 381 responses may get very Sparks Expires May 22, 2002 [Page 5] Internet-Draft Obtaining Responses to a Forked Request November 2001 large, and the contained responses are necessarily highly redundant. This can be addressed by defining a more compact representation of the contained responses (care will have to be taken to not re-break e-e transparency). 5. Security Considerations This extension creates no new security issues. In fact, it improves the effectiveness of challenge/response authentication mechanism in the system by allowing challenges to be delivered even in the presence of other successfully completing branches. References [1] Roach, A., "SIP-Specific Event Notification", draft-sip-events- 01 (work in progress), November 2001. Author's Address Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Sparks Expires May 22, 2002 [Page 6] Internet-Draft Obtaining Responses to a Forked Request November 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sparks Expires May 22, 2002 [Page 7]