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.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
