I'm not sure if I'm clear on your concern here - what is the "something" in the "Why should History-Info enforce..."?
If by the "something" you mean removing the history-info header (if it's session or header level privacy), we have to go back to the fundamental History-Info solution requirements and consider the functionality provided by the Privacy header in RFC 3324. This isn't about application-agnostic or not. The information in the hi-entries can be considered of the same ilk as the other information that is intended to be kept private by the use of the Privacy header, thus if the request indicates session or header levels of privacy, the proxy SHOULD NOT forward the hi-entries. Note, it's a SHOULD NOT. If your network configuration is such that there is no privacy issue with sharing that information, then you can document as such and explain why it's perfectly okay to forward the hi-entries. However, per my note below, even if the prior hop strips out information that is appropriate to the next domain, the last hi-entry can be added by that next hop proxy to preserve the information before that proxy might change the request-uri. Mary. -----Original Message----- From: Hans Erik van Elburg [mailto:[email protected]] Sent: Wednesday, March 11, 2009 5:05 PM To: Barnes, Mary (RICH2:AR00) Cc: Ian Elz; Audet, Francois (SC100:3055); [email protected] Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt I believe in this case the History-Info application-agnosticness principle applies. Why should History-Info enforce something, that goes against the whishes of a domain that is adding a hi-entry and should be considered best equiped in judging what privacy rules apply for this specific entry. /Hans Erik Mary Barnes wrote: > 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 > _______________________________________________ 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
