Network Working Group R. Sparks Internet-Draft dynamicsoft Expires: October 25, 2002 April 26, 2002 The Referred-By Header Field draft-sparks-sip-referredby-split-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 October 25, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines the Referred-By header field. This SIP extension is used with REFER to carry information about the Referror to the resource indicated by the Refer-To URI when that URI is a SIP URI. Sparks Expires October 25, 2002 [Page 1] Internet-Draft The Referred-By Header Field April 2002 Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Changes from draft-ietf-sip-refer-02 . . . . . . . . . . . 3 3. The Referred-By Header . . . . . . . . . . . . . . . . . . 3 3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Header Field Support for the REFER Method . . . . . . . . 4 3.3 Behavior of SIP User Agents . . . . . . . . . . . . . . . 4 3.3.1 Processing a REFER request . . . . . . . . . . . . . . . . 4 3.3.1.1 Processing non-REFER requests . . . . . . . . . . . . . . 4 3.3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3.2.1 Prototypical REFER callflow . . . . . . . . . . . . . . . 5 3.3.2.2 Multiple REFERs in a dialog . . . . . . . . . . . . . . . 6 3.3.3 Security Considerations . . . . . . . . . . . . . . . . . 8 4. Historic Material . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 9 References . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . 10 Sparks Expires October 25, 2002 [Page 2] Internet-Draft The Referred-By Header Field April 2002 1. Overview This document defines the Referred-By header field. This SIP [1] extension is used with REFER [2] to allow the Referror to provide information to the target indicated in a SIP Refer-To header beyond what is encoded in that URI. 2. Changes from draft-ietf-sip-refer-02 This section will be removed before forwarding this draft to the IESG. o Split Referred-By into (this) separate document o Aligned syntax with RFC3261's use of RFC2234 ABNF o Provided appropriate IANA registration material o TODO Populate Initial Security Considerations section o TODO add S/MIME security mechanism, revise security consideration section 3. The Referred-By Header Referred-By is a request-header as defined by [1]. It can appear in any request. It conveys the identity of the original REFERrer to the referred-to party. Referred-By = ("Referred-By" / "b") HCOLON referrer-url *( SEMI generic-param ) referrer-url = ( name-addr / addr-spec ) The referrer-url contains the SIP URL of the party sending the REFER request. A REFER request MUST contain either zero or exactly one Referred-By header field value. The Referred-By header MAY be encrypted as part of end-end encryption. Sparks Expires October 25, 2002 [Page 3] Internet-Draft The Referred-By Header Field April 2002 3.1 Examples Referred-By: sip:alice@atlanta.com Referred-By: "Bob" 3.2 Header Field Support for the REFER Method Referred-By is a Request header field. It MAY appear in any sip request, but is meaningless for ACK and CANCEL. The following row should be interpreted as if it appeared in Table 3 of RFC 3261. Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________________ Referred-By R - o - o o o 3.3 Behavior of SIP User Agents 3.3.1 Processing a REFER request If the URI provided in the Refer-To header field of a well formed REFER request is a SIP URI, any Referred-By header field value in the REFER request SHOULD be copied into the request sent to the referred- to resource. 3.3.1.1 Processing non-REFER requests If a Referred-By header appears in a request other than REFER, it is an indication that this request was generated in response to a REFER request. The agent receiving this Referred-By header can display the information in the Referred-By header field value, or use it to affect the processing of the request. There are significant security issues associated with using this header field value discussed later in this document. 3.3.2 Examples Sparks Expires October 25, 2002 [Page 4] Internet-Draft The Referred-By Header Field April 2002 3.3.2.1 Prototypical REFER callflow Agent A Agent B | | | F1 REFER | |----------------------->| | F2 202 Accepted | |<-----------------------| | | | |-------> | | (whatever) | |<------ | | | F3 NOTIFY | |<-----------------------| | F4 200 OK | |----------------------->| | | | | Here are examples of what the four messages between Agent A and Agent B might look like if the reference to (whatever) that Agent B makes is successful. The details of this flow indicate this particular REFER occurs outside a session (there is no To: tag in the REFER request). If the REFER occurs inside a session, there would be a non-empty To: tag in the request. Message One (F1) REFER sip:b@agentland SIP/2.0 Via: SIP/2.0/UDP agenta.agentland To: From: ;tag=193402342 Call-ID: 898234234@agenta.agentland CSeq: 93809823 REFER Refer-To: (whatever URL) Referred-By: Contact: sip:a@agentland Content-Length: 0 Message Two (F2) Sparks Expires October 25, 2002 [Page 5] Internet-Draft The Referred-By Header Field April 2002 SIP/2.0 202 Accepted Via: SIP/2.0/UDP agenta.agentland To: ;tag=4992881234 From: ;tag=193402342 Call-ID: 898234234@agenta.agentland CSeq: 93809823 REFER Contact: sip:b@agentland Content-Length: 0 Message Three (F3) NOTIFY sip:a@agentland SIP/2.0 Via: SIP/2.0/UDP agentb.agentland To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.agentland CSeq: 1993402 NOTIFY Event: refer Contact: sip:b@agentland Content-Type: message/sipfrag;version=2.0 Content-Length: 16 SIP/2.0 200 OK Message Four (F4) SIP/2.0 200 OK Via: SIP/2.0/UDP agentb.agentland To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.agentland CSeq: 1993402 NOTIFY Contact: sip:a@agentland Content-Length: 0 3.3.2.2 Multiple REFERs in a dialog Message One above brings an implicit subscription dialog into existance. Suppose Agent A issued a second REFER inside that dialog: Sparks Expires October 25, 2002 [Page 6] Internet-Draft The Referred-By Header Field April 2002 Agent A Agent B | | | F5 REFER | |----------------------->| | F6 202 Accepted | |<-----------------------| | | | |-------> | | (something different) | |<------ | | | F7 NOTIFY | |<-----------------------| | F8 200 OK | |----------------------->| | | | | Message Five (F5) REFER sip:b@agentland SIP/2.0 Via: SIP/2.0/UDP agenta.agentland To: ;tag=4992881234 From: ;tag=193402342 Call-ID: 898234234@agenta.agentland CSeq: 93809824 REFER Refer-To: (some different URL) Referred-By: Contact: sip:a@agentland Content-Length: 0 Message Six (F6) SIP/2.0 202 Accepted Via: SIP/2.0/UDP agenta.agentland To: ;tag=4992881234 From: ;tag=193402342 Call-ID: 898234234@agenta.agentland CSeq: 93809824 REFER Contact: sip:b@agentland Content-Length: 0 Message Seven (F7) Sparks Expires October 25, 2002 [Page 7] Internet-Draft The Referred-By Header Field April 2002 NOTIFY sip:a@agentland SIP/2.0 Via: SIP/2.0/UDP agentb.agentland To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.agentland CSeq: 1993403 NOTIFY Event: refer;cseq=93809824 Contact: sip:b@agentland Content-Type: message/sipfrag;version=2.0 Content-Length: 16 SIP/2.0 200 OK Message Eight (F8) SIP/2.0 200 OK Via: SIP/2.0/UDP agentb.agentland To: ;tag=193402342 From: ;tag=4992881234 Call-ID: 898234234@agenta.agentland CSeq: 1993403 NOTIFY Contact: sip:a@agentland Content-Length: 0 3.3.3 Security Considerations The security considerations of [1] for request header fields in general apply to the Referred-By header field. TODO: Much text will go here explaining the security issues with Referred-By. A revision will add mechanism to address some of them. 4. Historic Material During the evolution of this specification, the Referred-By header optionally contained a copy of the referrenced URL and a signature over the referrer-url and referrenced URL so that the refer target had a mechanism to verify that a request it received actually happened as a result of a REFER to its particular URL. This mechanism was removed in anticipation of using the more general security mechanisms being developed in SIP. 5. IANA Considerations (Note to RFC Editor: Please fill in all occurances of XXXX in this section with the RFC number of this specification). Sparks Expires October 25, 2002 [Page 8] Internet-Draft The Referred-By Header Field April 2002 This document defines a new SIP header field name with a compact form (Referred-By and b respectively). The following information should be added to the header sub-registry under http://www.iana.org/assignmemts/sip-parameters. Header Name: Referred-By Compact Form: b Reference: RFC XXXX 6. Acknowledgments This draft is a collaborative product of the SIP working group. References [1] PlaceHolder, A., "Placeholder", RFC 3261, placeholder 2002. [2] PlaceHolder, A., "Placeholder", internet-draft refer, placeholder 2002. Author's Address Robert J. Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 EMail: rsparks@dynamicsoft.com Sparks Expires October 25, 2002 [Page 9] Internet-Draft The Referred-By Header Field April 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 October 25, 2002 [Page 10]