Mary,
I was only considering the specific domain case as included in paragraph 2 of section 3.3 in the draft:
Thus, local policy
MAY also be used to determine whether to include the History-Info
header at all, whether to capture a specific Request-URI in the
header, or whether it be included only in the Request as it is
retargeted within a specific domain (PRIV-req-3). In the latter
case, this is accomplished by adding a new priv-value, history, to
the Privacy header [RFC3323] indicating whether any or a specific
History-Info header(s) SHOULD be forwarded.
And from Section 4.1
o Privacy: An optional parameter for History-Info, reflected in the
History-Info header field values by including the Privacy Header
[RFC3323] with a priv-value of "history" escaped in the hi-
targeted-to-uri or by adding the Privacy header with a priv-value
of "history" to the Request. The use of the Privacy Header with a
priv-value of "history" indicates whether a specific or all
History-Info headers should not be forwarded.
(There appears to be an inconsistency here as sections 3.3 and 4.1 appear to contradict. [Perhaps it just needs clarification that section 3.3 allows forwarding within the domain and 4.1 prohibits forwarding outside the domain?])
Assuming that the value 'history' means that presentation and forwarding should not occur.
In this case the inclusion of the value 'history' in the Privacy header impacts all H-I entries. If one node includes the value 'history' in the Privacy header then there is no way for another node to specifically allow the uri included in the hi-targeted-to-uri to not be restricted. To allow forwarding of a specific H-I entry there needs to be another value which can be included in the Privacy header parameter of for the hi-targeted-to-uri.
If the value "none" has specific meanings which will cause confusion then another value should be used.
More comments in-line
Nit in A.3
In both the sequence and the text you indicate that the INVITE to UA-B will retransmit. This should not occur if a 100 Trying has been received from UA-B. This means that the retransmit timer cannot be used to determine if UA-B does not respond. There will be a separate timer specified for determining no answer after the 180 has been received.
Office: + 44 24 764 35256
ian.elz at ericsson.com
-----Original Message-----
From: Mary Barnes [mailto:mary.barnes at nortel.com]
Sent: 12 March 2009 13:55
To: Ian Elz
Cc: sip at ietf.org; Francois Audet
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt
Ian,
Okay, so I think I might understand now - you want to use the "none" to
override the Privacy header that would be (in current 4244/4244bis)
applied to the whole message as it traverses across the n/w from the UAC
to the UAS. Is that correct?
[ige] Yes - currently a Privacy header with value 'history' will prevent any H-I entries from being passed. If the Privacy header does not contain the value 'history' then individual H-I entries may have privacy associated. Those which do will not be forwarded but those with no privacy will be forwarded.
That then though changes the meaning of the
Privacy header, as I understand it - i.e., the "none" I thought had to
do with specifying that an intermediary MUST NOT change the value of the
Privacy header. But, I guess you are saying we specify a slightly
different usage in 4244bis such that when we add it to an hi-entry, it
specifies that that hi-entry MUST NOT be dropped by an intermediary.
That might work, although, we would need verbage about the "risks" of
doing so.
[ige] I would not be as strong as MUST NOT. There may be local policy which will override what is included. I would prefer the words NEED NOT be removed {Scott B will hate me for that.} or perhaps MAY be forwarded based upon local policy.
Thanks,
Mary.
-----Original Message-----
From: Ian Elz [mailto:ian.elz at ericsson.com]
Sent: Thursday, March 12, 2009 8:43 AM
To: Barnes, Mary (RICH2:AR00)
Cc: sip at ietf.org; Audet, Francois (SC100:3055)
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt
Mary,
(Written after reading your discussion with Hans Erik.)
First an apology for not making it clear in my original email that a
value of "none" in a Privacy header parameter in a History-Info entry
was only applicable to the uri contained in the hi-targeted-to-uri.
I only suggested using the value "none" as this is a value defined for
the Privacy header which explicitly indicates that privacy is not
required. Any other value with the meaning of explicitly indicating that
there is no privacy required for the specific uri could be used.
With regard to your second paragraph below I understand that the SIP and
PSTN models do not align. You are correct in your assumption that this
problem is not unique for History-Info. The problem also arises with the
Referred-By header.
I have raised this for History-Info at this time as your new draft
presents an opportunity to correct this problem for the H-I case.
The general SIP privacy issue arises as when the Privacy header was
defined the concept of carrying third party identities in the SIP
messages was not defined. This came later with the REFER Request and the
associated Referred-By header and the History-Info header.
We should take what opportunities arise to discuss and correct this if
there is a will to make these changes.
Ian Elz
Office: + 44 24 764 35256
ian.elz at ericsson.com
-----Original Message-----
From: Mary Barnes [mailto:mary.barnes at nortel.com]
Sent: 11 March 2009 16:53
To: Ian Elz; Francois Audet
Cc: sip at ietf.org
Subject: RE: I-D Action:draft-barnes-sip-rfc4244bis-00.txt
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:ian.elz at ericsson.com]
Sent: Wednesday, March 11, 2009 4:54 AM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055)
Cc: sip at ietf.org
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: i-d-announce-bounces at ietf.org
[mailto:i-d-announce-bounces at ietf.org] On Behalf Of
Internet-Drafts at ietf.org
Sent: 04 March 2009 15:15
To: i-d-announce at ietf.org
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.