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

Note: This ballot was opened for revision 09 and is now closed.

(Richard Barnes) Yes

(Spencer Dawkins) (was Discuss) Yes

Comment (2013-10-04 for -11)
No email
send info
Thanks to my fellow ADs for helping me clear my Discuss Discuss.

I had one minor comment, which is a comment because I think I understand the text. Please let me know if I don't understand the text.

In 6.  User Agent Handling of the History-Info Header Field

   A back-to-back user agent (B2BUA) MAY follow the behavior of a SIP
   intermediary as an alternative to following the behavior of a user
   agent server (UAS) per Section 6.2 and a UAC per Section 6.1.  In
   behaving as an intermediary, a B2BUA carries forward hi-entries
   received in requests at the UAS to requests being forwarded by the
   UAC, as well as carrying forward hi-entries in responses received at
   the UAC to the responses forwarded by the UAS, subject to privacy
   considerations per Section 10.1.

I'm not seeing that the section title matches the contents - something like "Back-to-back User Agent Handling of the History-Info Header Field" would be closer. Given the current title, I'd expect this section to describe what's common between 6.1 and 6.2, but it's only saying that B2BUAs have the option of doing what's in 6.1 and 6.2.

Also in this text, it would be helpful to have a reference for "behavior of a SIP intermediary", if there's an obvious candidate.

(Robert Sparks) Yes

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-10-09 for -11)
No email
send info
Thanks for these 2 sections, which I like very much for a bis document:

   16. Changes from RFC 4244  . . . . . . . . . . . . . . . . . . . . 29
     16.1. Backwards compatibility  . . . . . . . . . . . . . . . . . 30

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-10-30)
No email
send info
Thanks for handling my discuss points. On reflection it'd be 
wrong to try to force the issue of whether TLS is more than
a SHOULD for SIP in this document, so I've cleared. 

But that is something I hope that SIP/RAI folks will work on 
more generally. For example, its very easy to see implementers 
getting the added MUST in section 13 wrong, or just doing 
nothing about it. The bit I mean is this:

   If TLS is NOT used, the
   intermediary MUST ensure that the messages are only sent within an
   environment that is secured by other means or that the messages don't
   leave the intermediary's domain.

(Brian Haberman) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2013-10-09 for -11)
No email
send info
Section 5, after the ABNF:
   The ABNF definitions for "generic-param" and "name-addr" are from

I think addr-spec is also from RFC 3261?

In section 9.3:
   Step 2:  Add Reason header field

      The SIP entity adds one or more Reason header fields to the hi-
      targeted-to-uri in the (newly) cached hi-entry reflecting the SIP
      response code in the non-100 response, per the procedures of
      Section 10.2.

But in 10.2:
   A Reason header field is added to the "headers" component in an hi-
   targeted-to-uri when the hi-entry is added to the cache based upon
   the receipt of a non-100 or non-2xx SIP response, as described in
   Section 9.3. 

Section 9.3 seems to miss excluding non-200 responses, unless I misunderstood it.   I think that 9.3 and 10.2 should be mutually consistent.

Otherwise, looks good to my SIP-innocent eyes.  :)

(Pete Resnick) No Objection

Comment (2013-10-09 for -11)
No email
send info
Section 3, list item 2: The terminology is not what email folks would use. Instead, "Email relaying whereby the recipient obtains a detailed "trace of the path" of the message from originator to receiver, including the time of each relay." You could get more complicated and talk about resent events, but I think the above is fine for just an example.

Section 5:

   The ABNF definitions for "generic-param" and "name-addr" are from

Also, HCOLON, COMMA, SEMI, EQUAL, and addr-spec.

Section 6: That "MAY" is not a 2119 MAY. I suggest lowercasing, or changing it to "can".

6.1, 6.2, 7, 8, 9.1, 9.2: I find the forward references using "MUST follow the procedures defined in..." a bit weird. Seems like it would have been easier to follow if all of the MUSTs were collected together in the target section. No big deal; just editorial.

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection