Responses below [MB]. -----Original Message----- From: Hans Erik van Elburg [mailto:[email protected]] Sent: Wednesday, March 11, 2009 6:56 PM To: Barnes, Mary (RICH2:AR00) Cc: [email protected]; Ian Elz; Audet, Francois (SC100:3055) Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt
But you do not have control over a previously visited proxy using the header. Why should that one dictate the privacy needs of the next hop proxy in the same domain? [MB] If the Privacy header is for the request as a whole (i.e., it's not tagged against a specific hi-entry), then by the definition of the header in RFC 3323 (with the addition of the priv-value="history"), it does apply to how the handled is request at every node. And, again, it is a SHOULD NOT, so it is possible that there might be conditions under which you don't want to "dictate the privacy needs..." - you just need to specify the conditions. Also, within the same domain, the hi-entries are NOT removed even if the Privacy header is used. If Proxy 1 and Proxy 2 are responsible for the same domain, then you don't remove the hi-entries until you leave that domain. [/MB] I dont think there is a conflict it is just adding some higher level of granularity in controlling the privacy of specific entries. [MB] I had interpreted the "none" to be used with the Privacy header (for the whole request, not just specific hi-entries), so that the specific entry can be forwarded outside a domain. [/MB] /Hans Erik Mary Barnes wrote: > And, if you have a network whereby you believe that none of the > information that Proxy 2 will put in hi-entries reveals any > information that is considered private, then you can set your flag, or > whatever and not drop the hi-entries when they leave that domain - > that's why it's a SHOULD NOT - i.e., don't do it unless you've > evaluated why it's okay to do it in that case. It is clearly > documented in 4244 that there is indeed a loss of information when you > use the Privacy header versus tagging individual hi-entries with the > privacy header. Now, we could add a Recommendation that the Privacy > header be used only to tag individual entries. > > Yes, I agree the "none" is not a good idea (and conflicts with the > Privacy header) as it kindof overrides it, so to speak. > > Mary. > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Hans Erik van Elburg > Sent: Wednesday, March 11, 2009 6:02 PM > To: Barnes, Mary (RICH2:AR00) > Cc: [email protected]; Ian Elz; Audet, Francois (SC100:3055) > Subject: Re: [Sip] I-D Action:draft-barnes-sip-rfc4244bis-00.txt > > When a proxy1 adds a Privacy header with the value history, then why > should a proxy 2 not be able to say: fine but I override the general > privacy rule for the specific hi-entry that I add or am responsible for? > > I was reacting to "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." > > /Hans Erik > > Mary Barnes wrote: > >> 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.t >>> x >>> t >>> >>> 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 > _______________________________________________ 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
