Ian, This is an interesting question. I need to think about it some more, but I don't like the "none" idea as it really must be up to the entity that added the Privacy header to the request, as to whether it wants the HI entries that it adds to go outside a domain. My initial thought is that we can't overrule the overall Privacy header. The thing is that the Privacy header doesn't preclude gathering the information and using within a domain AND if it were to not include an hi-entry when the request leaves the domain for which the proxy is responsible, the recipient can add the hi-entry for the current request-uri before it adds the new hi-entry.
Your PSTN example doesn't strictly map obviously to a SIP model and I would think you might consider the PSTN hop to be within the same domain for which the proxy (or gw, I guess) is responsible OR consider this a walled garden whereby the Privacy header doesn't apply. Which brings me to a more general question as to how you all deal with other headers when you do your mapping to the PSTN when there is a Privacy header? It would seem this problem isn't unique to History-Info, although I know little about the details of PSTN I/W. Regards, Mary. -----Original Message----- From: Ian Elz [mailto:[email protected]] Sent: Wednesday, March 11, 2009 4:54 AM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055) Cc: [email protected] Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt Mary, Francois, Section 4.1 of the draft allows for the addition of the Privacy header parameter with a value of "history" to be included with the hi-targeted-to-uri. Can this be extended to also allow the value "none". A node adding a H-I entry is allowed to specify the privacy value "history" either in the Privacy header or as a header parameter associated with the hi-targeted-to-uri. If the former action is taken by one node this results in privacy for all history info header entries even if this is not required. There is no way for privacy of an individual H-I entry to be set to none if no Privacy is required for the uri. This creates a specific problem when interworking with the PSTN where the privacy is associated with each E.164 number included in the protocol. If an INVITE is being mapped to ISUP and the H-I entries are being used to map to redirection numbers then a single Privacy header with the value "history" will result in all numbers being restricted. If the Privacy header parameter could include the value "none" then this would explicitly indicate that the associated uri was allowed to be presented. The ability to explicitly allow presentation of specific H-I entries may also be useful in pure sip implementations. I don't believe that this change would create any backward compatibility issues. The existing implementations will continue as deployed but new implementations could explicitly set no privacy for a specific uri. There are no security issues other than those already defined in the draft that an intervening node could modify an existing H-I entry. The Privacy header value of "none" should only be included by the node in the same manner as the existing inclusion of the "history" value. Ian Elz -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 04 March 2009 15:15 To: [email protected] Subject: I-D Action:draft-barnes-sip-rfc4244bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sip-rfc4244bis-00.txt Pages : 49 Date : 2009-03-04 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
