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?
I dont think there is a conflict it is just adding some higher level of
granularity in controlling the privacy of specific entries.
/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.tx
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
