From: The IESG To: IETF-Announce Message-Id: Date: Mon, 16 May 2005 15:37:42 -0400 Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor Subject: [Sip] Protocol Action: 'An Extension to the Session Initiation Protocol for Request History Information' to Proposed Standard The IESG has approved the following document: - 'An Extension to the Session Initiation Protocol for Request History Information ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document defines a standard mechanism for capturing the history information associated with a SIP request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. WG Summary There was extended working group review, including a requirements document, which was absorbed eventually into this specification, and a lengthy debate to obtain methods for provision of privacy. The working group reached a good consensus to advance this solution. Protocol Quality Some implementation and testing have been discussed. The WG Chair shepherd for this document was Rohan Mahy. Notes to the RFC Editor Section 1, 2nd to last paragraph OLD: o Some diagnostic information for debugging SIP requests. NEW: o Some diagnostic information for debugging SIP requests. (Note that the diagnostic utility of this mechanism is limited by the fact that its use by entities which retarget is optional.) Section 2.1, insert after 3rd para NEW: 3) A rogue application could delete some or all of the Request History information. Section 2.1, 3rd para from the end OLD: 3) SEC-req-3: The entity receiving the information conveyed by the Request History must be able to authenticate the source of the information. NEW: 3) SEC-req-3: The entity receiving the information conveyed by the Request History must be able to authenticate the entity providing the request. Section 3.2: Insert immediately after last paragraph NEW: Note that while using the SIPS scheme protects History-Info from tampering by arbitrary parties outside the SIP message path, all the intermediaries on the path are trusted implicitly. A malicious intermediary could arbitrarily delete, rewrite, or modify History-Info. This specification does not attempt to prevent or detect attacks by malicious intermediaries. Section 4.1: Please delete the blank line indicated below with --> OLD: History-Info = "History-Info" HCOLON --> hi-entry *(COMMA hi-entry) NEW: History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) Section 4.3.1, 1st paragraph OLD: The UAC SHOULD include the "histinfo" option tag in the Supported header in any request not associated with an established dialog for which the UAC would like the History-Info header in the Response. In addition, the UAC SHOULD initiate the capturing of the History Information by adding a History-Info header, using the Request-URI of the request as the hi-targeted-to-uri and initializing the index to the RECOMMENDED value of 1 in the hi-entry. NEW: The UAC SHOULD include the "histinfo" option tag in the Supported header in any request not associated with an established dialog for which the UAC would like the History-Info header in the response. In addition, the UAC MAY improve the diagnostic utility of its request by adding a History-Info header, using the Request-URI of the request as the hi-target-to-uri and initializing the index to the RECOMMENDED value of 1 in the hi-entry. As a result, intermediaries and the UAS will know at least the original Request-URI, and if the Request-URI was modified by a previous hop. Appendix A OLD: UA 1sends NEW: UA1 sends