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

[Ballot comment]
Suggested text for 4.3.1

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:

In 4.3.1, the draft says:

   
  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 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.  By initiating the capturing
  of the History Information, the UAC ensures that in cases of retargeting
  without further population of the header, the end consumer can at
  minimum detect that its was not the original target URI.

[Ballot discuss]
Suggest text for the diagnostic issue :  "The utility of this as a diagnostic tool will be limited
in cases where one or more entities chooses not to populate the header".

[Ballot discuss]
Minor, easily-fixed ABNF detail:

          History-Info = "History-Info" HCOLON

                            hi-entry *(COMMA hi-entry)

Blank lines aren't permitted inside a rule.  Although the document has a whitespace-only line, which does technically make it a continuation, that's pretty subtle; deleting the whitespace-only line would be more straightforward.

IANA Comments:
Upon approval of this document the IANA will register a new SIP header field name: History-Info and a new option tag: histinfo.  These registrations will go in .
The IANA will also register "history" as a SIP Privacy header.  This registration will be in the following registry:

[Ballot discuss]
I have two concerns:  the presumed diagnostic utility of this mechanism (first mentioned in section 1),
in that it is optional, and the SHOULD for UACs in 4.3.1 (which adds needless bloat to cases where
the target URI is actually reached).

Consider the case where the User agent choose to put the original request URI in a history info
header, the session is then forward from that target URI to another target without update to
the history-info section, and from there to a third target (the office-cell-phone-vmserver
example being one practical case).  If the history-info is examined at this point, the data is
incomplete, for which read "wrong".  Starting a diagnostic process there will not help.

In 4.3.1, the draft says:

   
  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. 

Why is this SHOULD?  If it is meant to be "UACs complying with this spec",
then it seems like MUST is required; if it is optional, then it looks like MAY.
Frankly, it seems like needless bloat for cases where the target URI is reached
and not much of a gain in situations where a forwarder will add the new target
URI; for those forwarders, reading in the original target seems like a trivial
addition.  Am I missing something from the use cases here?

[Ballot discuss]
In section 2.1, the list of potential security problems should include
  a rogue application deleting some or all of the history information.

  In section 3.2, I do not believe that TLS provides the authentication
  required by SEC-req-3.  TLS provides authentication of the sender, but
  not each contributor to the history.  Thus, the sender can alter any
  of the previously added content.

[Ballot comment]
(from review by Michael Patton)

I had two concerns, neither of which is strong enough to warrant
delaying the document, although if they are easy to fix that would be
worth it.

I'm not sure I believe the "stronger security" claim at the end of
Section 1.  I see this as analogous to the BGP problem.  Even though
each link was secured, in the end you can't be sure of anything except
the link closest to you.  Now, this _may_ be stronger than basic SIP
in some sense, but it's not really compelling to me.  Possibly because
I iniitally thought the per-hop securing of BGP was good enough until
in an hour-long discussion with a security person, I was finally
convinced that it only helped very marginally, if at all, and
contributed mostly to a false sense of security.

When I first started reading Section 2 I saw the "-req" notation as
short for request but later realized it was probably intended to be
short for requirement.  Is that correct?  I suggest that this
potential confusion could lead to readers making errors and, unless
it's following some established precedent, I'd recommend using
something like "-rqmt" which is less likely to be confused.


There were also a few typos I saw, which can just be fixed by RFC-Ed:
---------------------------------------------------------------------

At the very end of 4.1 one of the entries in the BNF is indented an
extra space.

Section 4.5: "would try several some of the same places" either
"several" or "some" should be removed,

Appendix A: "UA 1sends" => "UA1 sends"