An Extension to the Session Initiation Protocol (SIP) for Request History Information
RFC 4244

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    sip mailing list <sip@ietf.org>, 
    sip chair <sip-chairs@tools.ietf.org>
Subject: 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 '
   <draft-ietf-sip-history-info-07.txt> 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.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-07.txt

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