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.
Ian Elz
Office: + 44 24 764 35256
[email protected]
-----Original Message-----
From: Mary Barnes [mailto:[email protected]]
Sent: 12 March 2009 13:55
To: Ian Elz
Cc: [email protected]; 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:[email protected]]
Sent: Thursday, March 12, 2009 8:43 AM
To: Barnes, Mary (RICH2:AR00)
Cc: [email protected]; 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
[email protected]
-----Original Message-----
From: Mary Barnes [mailto:[email protected]]
Sent: 11 March 2009 16:53
To: Ian Elz; Francois Audet
Cc: [email protected]
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:[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
