Subject: Re: [sipcore] 4244bis and privacy

From: "Ian Elz" <[email-masked]>
Date: Wed, 24 Jun 2009 09:57:21 +0200

Mary,

[I have added the list to this thread for wider comment.]

In the previous discussions I commented that in RFC4424 that a Privacy
header with value "history" effectively makes all H-I entries private
with the result that the H-I entries may be removed.

There has now been a comprehensive discussion on indication of the
initial 'target' to the final recipient for call handling purposes.

The main use case related to a freephone example where the answering
location may be a call centre where the original freephone number may be
required for correct call handling.

If you now consider the following example (modified from Francois' text
in the latest draft - excuse any errors that I may have inserted)

INVITE sip:sip:[email-masked];user=phone;p=x
Privacy: history
History-Info:
<sip:[email-masked];user=phone;p=x>;index=1;rt;aor         (1)
History-Info: <sip:[email-masked]>;index=1.1;mp;aor
(2)
History-Info: <sip:[email-masked]>;index=1.1.1;rc
(3)

In this case due to the Privacy header all of the H-I entries are
considered private and the +18001234567 will not be delivered to the
final destination with the result that call handling may not be correct.
The Privacy header may have been inserted by any of the nodes which
routed the message and inserted a H-I entry.

If however the H-I was allowed to include a header parameter of
"?Privacy=none" in the H-I entry and that an explicit H-I entry privacy
value would be considered to have precedence over a Privacy header with
a value of "history" then the mapping of the +18001234567 could be
explicitly specified as not private and may be passed on.

Thus when the mapping from sip:[email-masked] to
sip:[email-masked] when H-I entry (2) above is included could
also insert the Privacy header parameter in H-I entry (1).

Thus the message would appear as follows:

INVITE sip:sip:[email-masked]; user=phone;p=x
Privacy: history
History-Info:
<sip:[email-masked]?Privacy=none;user=phone;p=x>;index=1;rt;ao
r
History-Info: <sip:[email-masked]>;index=1.1;mp;aor
History-Info: <sip:[email-masked]>;index=1.1.1;rc

This would result in all the H-I entries except (1) being considered
private with the result that the =1800... Number is passed for call
handling purposes.

This change is backward compatible with the existing implementation as
any node using the existing functionality as defined in RFC4244 will
continue to be supported.

The alternative is to remove the ability to include the value "history"
in the Privacy header and only allow this value in the Privacy header
parameter. This alternative is not backward compatible.

Without this change a single node in the message path which includes a
header "Privacy: history" will prevent delivery of the aor and thus
prevent proper call handling.

Ian Elz

-----Original Message-----
From: Christer Holmberg 
Sent: 23 June 2009 19:40
To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert
Cc: Ian Elz
Subject: RE: 4244bis and privacy

Hi,

I include Ian, so he can comment to your resposne himself.

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 9:40 PM
To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida
Schubert
Subject: RE: 4244bis and privacy

Here was the thread of response and the last comment was from Ian that
he would consider the response:
http://www.ietf.org/mail-archive/web/sip/current/msg26948.html

And, there was not agreement on the "none" but rather to qualify the
SHOULD NOT forward.  However, in the sipcore-4244bis-00, rather than
changing the text such that the headers SHOULD be removed, we recommend
that they be anonymized (in section 4.3.3.3.1).  That is entirely
consistent with RFC 3324 and thus we have removed the recommendations to
remove the headers entirely. However, that changed never got done in
section 3.2, so we would need to change this:
   "Thus, the History- Info header
   SHOULD NOT be included in Requests where the requestor has indicated
   a priv-value of Session- or Header-level privacy."

But, I'm really beginning to be of the mindset that we should just
remove all the subsections of section 3 (i.e., leave the text in the
upper level section), so we don't have to keep worrying about
consistency.

So, lets either fixt the text in 3.2 or remove altogether and then I
think we are really at the point of needing to submit this version so
folks that actually have an interest in it can review the updated
document. 

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 1:10 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik
van Elburg; Shida Schubert
Subject: 4244bis and privacy

Hi,

Below is a comment/proposal which one of my collegues (Ian Elz) gave on
the list a while ago, when the first version of 4244bis was submitted,
but was not incorporated. Do you think it would be useful?

-------

While the HI approach to target may solve the problem of being able to
deliver the target URI to the final destination there is no guarantee
that it will actually be delivered.

The problem arises with how Privacy is defined for HI.

4424 defines a new Privacy value "history" which may be placed in either
the Privacy header or as a header parameter to the HI entry.

If one node uses the former option "Privacy: history" then this will
make all headers private and will result in all HI entries being removed
or made anonymous when the message containing the HI is delivered to the
user.

There is a simple solution to this and that is to also allow the use of
the "none" Privacy value as a header parameter in the HI entry. This
would explicitly state that no privacy is required to the HI entry and
this would override a "history" value in the Privacy header.

I pointed this out to Mary when the 4424bis draft was first published
but the change has not been made in the latest draft.

The change is backward compatible and would not cause an issue with any
existing implementations.

------

Regards,

Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 24 Jun 2009 09:47:56 -0500

Hi Ian,

I do not believe we should do the "override" behavior as I think that
violates RFC 3323, as the "history" is really a subset of the cases
whereby a UAC or proxy would add "session" or "header" to the request.
And, the latter two cases have the same (undesireable) result.   I agree
this impacts your services, but we can't mandate that proxies provide
information that might violate their local policies and indeed a proxy's
local policies can result in the information being anonymized (or
removed if they can't anonymize) even in the "none" case. 

I do believe it's reasonable that we strongly recommend that the request
level (versus specific hi-entries) not be used and if it is used, the
consequence is that some services will not have the information they
need - this was the gist of my previous response (to which I did not get
any additional feedback). Now, we could add some text that the "none"
case SHOULD be used (e.g., added by first hop proxy) if it is desired
that the information not be subject to privacy restrictions. I do not
think it is then particularly useful to add logic around the proxy then
being able to tag the entries within their domain as subject to privacy.
I think that conflicts with the intent of the request level "none".
However, as I mention above, per the current text, a proxy can (based on
local policy) remove entries - so a proxy can capture hi within their
domain and not forward any of that information to the next hop in
another domain - you already have that functionality.  But, I think this
introduces the general problem that you might be impacting other
services further down the line, which I thought was the problem you were
wanting to solve - not specifically your example service but, for
example, in the case that someone is debugging and they want the entire
history, so depending upon the service, this is also undesirable
behavior.  

Regards,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Wednesday, June 24, 2009 2:57 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
[email-masked]; Audet, Francois (SC100:3055)
Subject: RE: 4244bis and privacy

 Mary,

Ian Elz

-----Original Message-----
From: Christer Holmberg
Sent: 23 June 2009 19:40
To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert
Cc: Ian Elz
Subject: RE: 4244bis and privacy

Hi,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 9:40 PM
To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida
Schubert

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 1:10 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik

Hi,

-------

------

Regards,

Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 24 Jun 2009 11:26:41 -0500

Hi Ian,

Responses inline below [MB].

Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Wednesday, June 24, 2009 10:37 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Mary,

I was not proposing that we change the handling of H-I which is based
upon local policy. If that causes an issue for a network operator then
they can modify their local policy accordingly or arrange with the proxy
vendor to modify their equipment to be more flexible with regards to
policy.

Can you clarify for me:

If you have a Privacy header with either "session" or "header" doe this
impact the H-I entries or will only a value of "history" impact the H-I
entries?
[MB] Yes, both "session" and "header" level privacy, consistent with RFC
3323, mandate that entries be anonymized or dropped, with the latter
being the recommendation for "session" level privacy. RFC 4244 mandated
that they be dropped and 4244bis recommends they be anonymized. The
original intent for the value of "history" was for the tagging of the
individual entries, but you end up getting the header level
functionality as well. [/MB] 

If you have a Privacy header with a value of "none" and a H-I entry with
Privacy header parameter with value "history" what is the privacy of the
individual H-I entry?
[MB] We did not explicitly address the "none" in RFC 4244, but the
general statement is the privacy headers at the request level override
any at the hi-entry level. [/MB]

>From reading RFC4244 a Privacy header with value "history" will
effectively make all H-I entries private and there is currently no
option to  include a H-I Privacy header parameter with value "none".
[MB] Correct, per my comment above. [/MB]

H-I at present allows the inclusion of Privacy header parameters to
explicitly express privacy for an individual H-I entry but a single node
which includes a header "Privacy: history" makes all H-I entries private
even if this is not the requirements for the specific URI.
[MB] Correct, but the only node that should add the header is a node
which is responsible for the domain associated with the Request URI in
the incoming request or is authorized to do so. [/MB]

I will admit that having worked in a telephony environment for a long
time I am used to having privacy of identities set on a per number basis
and the relative inflexibility of the IETF Privacy header is relatively
restrictive as to specifying which identities may be presented and which
not.
[MB] Yes, this is an entirely different paradigm.  I developed telephony
s/w for over a decade and this is entirely different - it provides a lot
more flexibility, which makes things far, far less deterministic than
what you have in telephony switches where your routing and translations
are configured for the most part, with just a few capabilities for
controlling the privacy and it's a closed network.  

With RFC4244/4244bis, there MUST be a mechanism at the UAS or end
application that can handle a request that doesn't have the appropriate
information either because nodes didn't support History-Info or some
random node in the network applied privacy (which I think is highly
unlikely) - this is normative per section 5 of RFC 4244.  So, the worst
case scenario I see for this 800 service  (which will get to the right
UAS but without the exact 800 number that was dialed) is that it goes to
a default ACD group/customer service agent, etc. who then needs to
gather the appropriate information and in my experience this is often an
IVR system these days.  So, the service is not broken when privacy is
applied in an undesireable manner, it's just not optimal.  This is
something that should be addressed in the target-uri draft which has all
the details of how specific services use History-Info.
One other thing to consider is that most networks that are emulating
telephony type features use B2BUAs, which follow the UAS/UAC rules for
the header rather than the proxy rules, noting that the UAC can set the
Privacy header to whatever value it sees as appropriate for the request.
[/MB]

Regards 

Ian

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 24 June 2009 15:48
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
[email-masked]; Francois Audet
Subject: RE: 4244bis and privacy

Hi Ian,

Regards,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Wednesday, June 24, 2009 2:57 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

 Mary,

Ian Elz

-----Original Message-----
From: Christer Holmberg
Sent: 23 June 2009 19:40
To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert
Cc: Ian Elz
Subject: RE: 4244bis and privacy

Hi,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 9:40 PM
To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida
Schubert

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 1:10 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik

Hi,

-------

------

Regards,

Christer

---

From: "Ian Elz" <[email-masked]>
Date: Wed, 24 Jun 2009 17:36:54 +0200

Mary,

Can you clarify for me:

Regards 

Ian

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: 24 June 2009 15:48
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Hi Ian,

Regards,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Wednesday, June 24, 2009 2:57 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

 Mary,

Ian Elz

-----Original Message-----
From: Christer Holmberg
Sent: 23 June 2009 19:40
To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert
Cc: Ian Elz
Subject: RE: 4244bis and privacy

Hi,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 9:40 PM
To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida
Schubert

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 1:10 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik

Hi,

-------

------

Regards,

Christer

---

From: "Ian Elz" <[email-masked]>
Date: Thu, 25 Jun 2009 17:12:43 +0200

Mary,

I am a little concerned about one answer that you gave:

This means that if privacy is required for an individual H-I entry but
the originating user included "Privacy:none" in the request then there
is no option to include the real URI in the H-I entry.

This occurs as RFC3323 states in section 4.3: "However, if the Privacy
header value of 'none' is specified in a message, privacy services MUST
NOT perform any privacy function and MUST NOT remove or modify the
Privacy header."

The only option for an intermediate node including a H-I entry where
"Privacy:none" is specified and privacy for the H-I URI is required is
to include an anonymous entry or not include the H-I entry.

In your previous response you stated that we would violate RFC3323 if we
specified additional behaviour for privacy explicitly stated with a URI
-n the H-I entry. I don't believe that this is the case as RFC3323 only
considered privacy in a two party scenario and did not consider third
party identities being included in a message between two parties. H-I is
not the only case where this occurs as the Referred-By header when
included in the INVITE (or other request) which results from the REFER
has the same issue.

RFC4244 was the first time that there was a recognition that privacy for
these individual third party identities may be required. To allow this
explicit statement of privacy to be overridden by a generic statement
which is applicable to a different user is counterintuitive.

The original Privacy header is usually included by or on behalf of the
originating user and should not be allowed to specify the privacy of the
original called user, e.g. the 800 number, and prevent this identity
being presented if this user does not have the same level of privacy.

The real issue with the 800 scenario is as you have stated is that the
answerer will not know the original called identity and will not be able
to correctly handle the call. As more generic call centres are used
which will answer calls on behalf of many different organizations using
CTI and the original called identity to have to implement a generic
system asking the caller who he originally called appear unprofessional,
is inefficient and unproductive.

We have an opportunity to allow presentation of specific identities and
to solve this particular problem so we should take it.

I hope that we can get some wider discussion on this issue so a more
general consensus can be obtained.

Regards

Ian

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: 24 June 2009 17:27
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Hi Ian,

Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Wednesday, June 24, 2009 10:37 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Mary,

Can you clarify for me:

Regards 

Ian

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 24 June 2009 15:48
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Hi Ian,

Regards,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Wednesday, June 24, 2009 2:57 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

 Mary,

Ian Elz

-----Original Message-----
From: Christer Holmberg
Sent: 23 June 2009 19:40
To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert
Cc: Ian Elz
Subject: RE: 4244bis and privacy

Hi,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 9:40 PM
To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida
Schubert

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 1:10 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik

Hi,

-------

------

Regards,

Christer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 25 Jun 2009 17:48:18 +0200

Ok Ian, now I see what you mean.
You are saying that if A calls B which forwards to C, that A indicating that
privacy is required should not prohibit B to choose to deliver its identity
to C, right?

I think I agree with you that this is a point that needs to be addressed by
4244bis.

Best Regards,
/Hans Erik van Elburg

On Thu, Jun 25, 2009 at 5:12 PM, Ian Elz <[email-masked]> wrote:

> INVITE sip:sip:[email-masked]<[email-masked]>
> ;user=phone;p=x
> Privacy: history
> History-Info:
> <sip:[email-masked] <[email-masked]>;user=phone;p=x>;index=1;rt;aor
>         (1)
> History-Info: <sip:[email-masked] <[email-masked]>
> >;index=1.1;mp;aor
> (2)
> History-Info: <sip:[email-masked] <[email-masked]>>;index=1.1.1;rc
> (3)
>
> Thus when the mapping from sip:[email-masked]<[email-masked]>to
> sip:[email-masked] <[email-masked]> when H-I entry
> (2) above is included could
> INVITE sip:sip:[email-masked]<[email-masked]>;
> user=phone;p=x
> Privacy: history
> History-Info:
> History-Info: <sip:[email-masked] <[email-masked]>
> >;index=1.1;mp;aor
> History-Info: <sip:[email-masked] <[email-masked]>>;index=1.1.1;rc
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 25 Jun 2009 11:27:23 -0500

You mean "should not prohibit B to choose to deliver the identity of B to C", right?

________________________________

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: Thursday, June 25, 2009 08:48
	To: Ian Elz
	Cc: Barnes, Mary (RICH2:AR00); Christer Holmberg; Shida Schubert; [email-masked]; Audet, Francois (SC100:3055)
	Subject: Re: 4244bis and privacy

	You are saying that if A calls B which forwards to C, that A indicating that privacy is required should not prohibit B to choose to deliver its identity to C, right?

	I think I agree with you that this is a point that needs to be addressed by 4244bis.

	Best Regards,
	/Hans Erik van Elburg

		Mary,

		

		

		

		Regards
		
		Ian

		-----Original Message-----
		
		Sent: 24 June 2009 17:27
		To: Ian Elz
		
		Hi Ian,

		Mary.
		
		-----Original Message-----
		From: Ian Elz [mailto:[email-masked]]
		Sent: Wednesday, June 24, 2009 10:37 AM
		To: Barnes, Mary (RICH2:AR00)
		Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
		[email-masked]; Audet, Francois (SC100:3055)
		Subject: RE: 4244bis and privacy
		
		Mary,

		Can you clarify for me:

		

		

		Regards
		
		Ian
		
		-----Original Message-----
		From: Mary Barnes [mailto:[email-masked]]
		Sent: 24 June 2009 15:48
		To: Ian Elz
		Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
		[email-masked]; Francois Audet
		Subject: RE: 4244bis and privacy
		
		Hi Ian,

		Regards,
		Mary.
		
		-----Original Message-----
		From: Ian Elz [mailto:[email-masked]]
		Sent: Wednesday, June 24, 2009 2:57 AM
		To: Barnes, Mary (RICH2:AR00)
		Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
		[email-masked]; Audet, Francois (SC100:3055)
		Subject: RE: 4244bis and privacy

		 Mary,

		

		
		INVITE sip:sip:[email-masked] <mailto:[email-masked]> ;user=phone;p=x
		Privacy: history
		History-Info:
		<sip:[email-masked] <mailto:[email-masked]> ;user=phone;p=x>;index=1;rt;aor         (1)
		History-Info: <sip:[email-masked] <mailto:[email-masked]> >;index=1.1;mp;aor
		(2)
		History-Info: <sip:[email-masked] <mailto:[email-masked]> >;index=1.1.1;rc
		(3)

		
		Thus when the mapping from sip:[email-masked] <mailto:[email-masked]>  to
		sip:[email-masked] <mailto:[email-masked]>  when H-I entry (2) above is included could
		also insert the Privacy header parameter in H-I entry (1).

		INVITE sip:sip:[email-masked] <mailto:[email-masked]> ; user=phone;p=x
		Privacy: history
		History-Info:
		<sip:[email-masked]?Privacy=none;user=phone;p=x>;index=1;rt;ao
		r
		History-Info: <sip:[email-masked] <mailto:[email-masked]> >;index=1.1;mp;aor
		History-Info: <sip:[email-masked] <mailto:[email-masked]> >;index=1.1.1;rc

		

		Ian Elz

		-----Original Message-----
		From: Christer Holmberg
		Sent: 23 June 2009 19:40
		To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert
		Cc: Ian Elz
		Subject: RE: 4244bis and privacy

		Hi,

		Regards,
		
		Christer

		-----Original Message-----
		From: Mary Barnes [mailto:[email-masked]]
		Sent: Tuesday, June 23, 2009 9:40 PM
		To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida
		Schubert
		Subject: RE: 4244bis and privacy

		

		Mary.
		
		-----Original Message-----
		From: Christer Holmberg [mailto:[email-masked]]
		Sent: Tuesday, June 23, 2009 1:10 PM
		To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik
		van Elburg; Shida Schubert
		Subject: 4244bis and privacy

		Hi,

		-------

		

		

		------
		
		Regards,
		
		Christer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 25 Jun 2009 18:30:51 +0200

Yes.
/Hans Erik van Elburg

On Thu, Jun 25, 2009 at 6:27 PM, Francois Audet <[email-masked]> wrote:

>  ------------------------------
> *From:* Hans Erik van Elburg [mailto:[email-masked]]
> *Sent:* Thursday, June 25, 2009 08:48
> *To:* Ian Elz
> *Cc:* Barnes, Mary (RICH2:AR00); Christer Holmberg; Shida Schubert;
> *Subject:* Re: 4244bis and privacy
>
> You are saying that if A calls B which forwards to C, that A indicating
> that privacy is required should not prohibit B to choose to deliver its
> identity to C, right?
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 25 Jun 2009 18:47:42 +0200

That's another use case.
But given your set of info, I think that is correct.

/Hans Erik van Elburg

On Thu, Jun 25, 2009 at 6:37 PM, Francois Audet <[email-masked]> wrote:

> So, let's say A calls B, B forwards to C.
>
> B has privacy turned on.
>
> A calls B. A history-info entry is added with sip:B.
>
> B retargets to C and sets privacy.
>
> I guess that would mean that B's proxy would have to parse the
> History-Info
> and anonymize all entries corresponding to B?
>
> Is this correct?
>
> > From: Barnes, Mary (RICH2:AR00)
> > Sent: Thursday, June 25, 2009 09:29
> > To: Ian Elz
> > Responses inline below [MB2].
> >
> > Mary.
> >
> > Sent: Thursday, June 25, 2009 10:13 AM
> > If you have a Privacy header with a value of "none" and a H-I
> > entry with Privacy header parameter with value "history" what
> > is the privacy of the individual H-I entry?
> > [MB] We did not explicitly address the "none" in RFC 4244,
> > but the general statement is the privacy headers at the
> > request level override any at the hi-entry level. [/MB]
> >
> > This means that if privacy is required for an individual H-I
> > entry but the originating user included "Privacy:none" in the
> > request then there is no option to include the real URI in
> > the H-I entry.
> > [MB2] I'm confused here - the "none" definition is as you
> > note below, thus "none" prohibits the removal or
> > anonymization of the entries, thus I would think you would
> > fine this functionality desireable. However, this does not
> > prohibit an entity based on policy to anonymize (or remove
> > entries if privacy is required for that domain if the entity
> > does not have access to a privacy service). [/MB2]
> >
> > This occurs as RFC3323 states in section 4.3: "However, if
> > the Privacy header value of 'none' is specified in a message,
> > privacy services MUST NOT perform any privacy function and
> > MUST NOT remove or modify the Privacy header."
> >
> > The only option for an intermediate node including a H-I
> > entry where "Privacy:none" is specified and privacy for the
> > H-I URI is required is to include an anonymous entry or not
> > include the H-I entry.
> > [MB2] If privacy is required then yes, you include anonymous
> > entries or don't include. That's the basic privacy mechanism
> > for privacy levels of "session" "header" and "history" in the
> > R-URI or "history" in the specific entries, as well as when
> > there is a policy for privacy for the entries added by a
> > specific domain. The "none" really has no influence on the
> > later case per se. [/MB2]
> >
> > In your previous response you stated that we would violate
> > RFC3323 if we specified additional behaviour for privacy
> > explicitly stated with a URI -n the H-I entry. I don't
> > believe that this is the case as RFC3323 only considered
> > privacy in a two party scenario and did not consider third
> > party identities being included in a message between two
> > parties. H-I is not the only case where this occurs as the
> > Referred-By header when included in the INVITE (or other
> > request) which results from the REFER has the same issue.
> > [MB2] I can't necessarily disagree on this one (we can debate
> > it either way). But to fix it requires an update to RFC 3323
> > and shouldn't be something that we want to fix in 4244bis. [/MB2]
> >
> > RFC4244 was the first time that there was a recognition that
> > privacy for these individual third party identities may be
> > required. To allow this explicit statement of privacy to be
> > overridden by a generic statement which is applicable to a
> > different user is counterintuitive.
> > [MB2] See my comment above. But, as I have consistently said,
> > the idea that an entity might want to override the "none" is
> > entirely based on policy and 4244 and 4244bis allow privacy
> > to be applied to the entries that are added by that entity if
> > the policy dictates so (and we already say that). [/MB2]
> >
> > The original Privacy header is usually included by or on
> > behalf of the originating user and should not be allowed to
> > specify the privacy of the original called user, e.g. the 800
> > number, and prevent this identity being presented if this
> > user does not have the same level of privacy.
> > [MB2] As I tried to say in a previous response, a random
> > entity (i.e., one for whom the R-URI is not in a domain under
> > its control) cannot add a privacy header to the Request. Per
> > RFC 3323 an entity may add the header to a request only if it
> > has the appropriate relationship/authorization with the
> > original called user who intiated the request. And, I would
> > find it very surprising if an entity that did have
> > responsibility would apply privacy since that would be
> > counter intuitive and I would hope that SPs would be
> > judicious in specifying the appropriate and inappropriate
> > manner in which the proxies they deploy and interface with
> > privatize the messages. The protocol CANNOT control this
> > behavior and that's why there is the policy clause in 4244
> > and 4244bis. [/MB2]
> >
> > The real issue with the 800 scenario is as you have stated is
> > that the answerer will not know the original called identity
> > and will not be able to correctly handle the call. As more
> > generic call centres are used which will answer calls on
> > behalf of many different organizations using CTI and the
> > original called identity to have to implement a generic
> > system asking the caller who he originally called appear
> > unprofessional, is inefficient and unproductive.
> > [MB2] And, as I noted, it is rare for a call centre to route
> > a call directly to an agent without a user providing some
> > sort of input. Even companies like American Airlines, even
> > though they have the info that I enter via the IVR, they
> > still ask some basic questions and there are times when they
> > have to reroute me. I don't think we can totally automate
> > things.  And, again, once the call hits the domain that is
> > responsible for that 800 number the entities in that domain
> > have control over how they muck with the R-URI, such that
> > they should be able to use any IVR info to appropriately
> > direct the call - it's not the number that's meaningful, but
> > how the system gets the call to the right user and the
> > additional information they provide as the call is presented
> > to the agent. I would honestly think that having something
> > other than an 800 number show up on the display would be far
> > more useful and in my experience in the systems I developed
> > we're usually talking about CTI interfaces so you have a lot
> > you can do.  And, actually all of this really doesn't matter
> > in that you MUST be able to handle this situation independent
> > of the privacy since History-Info is optional, you need
> > default behavior assigned. [/MB2]
> >
> > We have an opportunity to allow presentation of specific
> > identities and to solve this particular problem so we should take it.
> > [MB2] The most we can do is to document the risks/impacts of
> > the use of the Privacy headers at the R-URI level. There is
> > already general text in 4244 and 4244bis that the privacy may
> > impact whether the applications get the information.  And, as
> > I noted before, most commercial systems are using B2BUAs
> > which will allow you far more control over the use of the
> > Privacy headers in the network. But, again, I don't think
> > that's something that should be address in 4244bis.  [/MB2]
> >
> > I hope that we can get some wider discussion on this issue so
> > a more general consensus can be obtained.
> >
> > Regards
> >
> > Ian
> >
> >
> >
> > I was not proposing that we change the handling of H-I which
> > is based upon local policy. If that causes an issue for a
> > network operator then they can modify their local policy
> > accordingly or arrange with the proxy vendor to modify their
> > equipment to be more flexible with regards to policy.
> >
> > Can you clarify for me:
> >
> > If you have a Privacy header with either "session" or
> > "header" doe this impact the H-I entries or will only a value
> > of "history" impact the H-I entries?
> > [MB] Yes, both "session" and "header" level privacy,
> > consistent with RFC 3323, mandate that entries be anonymized
> > or dropped, with the latter being the recommendation for
> > "session" level privacy. RFC 4244 mandated that they be
> > dropped and 4244bis recommends they be anonymized. The
> > original intent for the value of "history" was for the
> > tagging of the individual entries, but you end up getting the
> > header level functionality as well. [/MB]
> >
> > If you have a Privacy header with a value of "none" and a H-I
> > entry with Privacy header parameter with value "history" what
> > is the privacy of the individual H-I entry?
> > [MB] We did not explicitly address the "none" in RFC 4244,
> > but the general statement is the privacy headers at the
> > request level override any at the hi-entry level. [/MB]
> >
> > From reading RFC4244 a Privacy header with value "history"
> > will effectively make all H-I entries private and there is
> > currently no option to  include a H-I Privacy header
> > parameter with value "none".
> > H-I at present allows the inclusion of Privacy header
> > parameters to explicitly express privacy for an individual
> > H-I entry but a single node which includes a header "Privacy:
> > history" makes all H-I entries private even if this is not
> > the requirements for the specific URI.
> > [MB] Correct, but the only node that should add the header is
> > a node which is responsible for the domain associated with
> > the Request URI in the incoming request or is authorized to
> > do so. [/MB]
> >
> > I will admit that having worked in a telephony environment
> > for a long time I am used to having privacy of identities set
> > on a per number basis and the relative inflexibility of the
> > IETF Privacy header is relatively restrictive as to
> > specifying which identities may be presented and which not.
> > [MB] Yes, this is an entirely different paradigm.  I
> > developed telephony s/w for over a decade and this is
> > entirely different - it provides a lot more flexibility,
> > which makes things far, far less deterministic than what you
> > have in telephony switches where your routing and
> > translations are configured for the most part, with just a
> > few capabilities for controlling the privacy and it's a
> > closed network.
> >
> > With RFC4244/4244bis, there MUST be a mechanism at the UAS or
> > end application that can handle a request that doesn't have
> > the appropriate information either because nodes didn't
> > support History-Info or some random node in the network
> > applied privacy (which I think is highly
> > unlikely) - this is normative per section 5 of RFC 4244.  So,
> > the worst case scenario I see for this 800 service  (which
> > will get to the right UAS but without the exact 800 number
> > that was dialed) is that it goes to a default ACD
> > group/customer service agent, etc. who then needs to gather
> > the appropriate information and in my experience this is
> > often an IVR system these days.  So, the service is not
> > broken when privacy is applied in an undesireable manner,
> > it's just not optimal.  This is something that should be
> > addressed in the target-uri draft which has all the details
> > of how specific services use History-Info.
> > One other thing to consider is that most networks that are
> > emulating telephony type features use B2BUAs, which follow
> > the UAS/UAC rules for the header rather than the proxy rules,
> > noting that the UAC can set the Privacy header to whatever
> > value it sees as appropriate for the request.
> > [/MB]
> >
> >
> > Regards
> >
> > Ian
> >
> > I do not believe we should do the "override" behavior as I
> > think that violates RFC 3323, as the "history" is really a
> > subset of the cases whereby a UAC or proxy would add
> > "session" or "header" to the request.
> > this impacts your services, but we can't mandate that proxies
> > provide information that might violate their local policies
> > and indeed a proxy's local policies can result in the
> > information being anonymized (or removed if they can't
> > anonymize) even in the "none" case.
> >
> > I do believe it's reasonable that we strongly recommend that
> > the request level (versus specific hi-entries) not be used
> > and if it is used, the consequence is that some services will
> > not have the information they need - this was the gist of my
> > previous response (to which I did not get any additional
> > feedback). Now, we could add some text that the "none"
> > case SHOULD be used (e.g., added by first hop proxy) if it is
> > desired that the information not be subject to privacy
> > restrictions. I do not think it is then particularly useful
> > to add logic around the proxy then being able to tag the
> > entries within their domain as subject to privacy.
> > However, as I mention above, per the current text, a proxy
> > can (based on local policy) remove entries - so a proxy can
> > capture hi within their domain and not forward any of that
> > information to the next hop in another domain - you already
> > have that functionality.  But, I think this introduces the
> > general problem that you might be impacting other services
> > further down the line, which I thought was the problem you
> > were wanting to solve - not specifically your example service
> > but, for example, in the case that someone is debugging and
> > they want the entire history, so depending upon the service,
> > this is also undesirable behavior.
> >
> >
> > Regards,
> > Mary.
> >
> > In the previous discussions I commented that in RFC4424 that
> > a Privacy header with value "history" effectively makes all
> > H-I entries private with the result that the H-I entries may
> > be removed.
> >
> > There has now been a comprehensive discussion on indication
> > of the initial 'target' to the final recipient for call
> > handling purposes.
> >
> > The main use case related to a freephone example where the
> > answering location may be a call centre where the original
> > freephone number may be required for correct call handling.
> >
> > If you now consider the following example (modified from
> > Francois' text in the latest draft - excuse any errors that I
> > may have inserted)
> >
> > In this case due to the Privacy header all of the H-I entries
> > are considered private and the +18001234567 will not be
> > delivered to the final destination with the result that call
> > handling may not be correct.
> > The Privacy header may have been inserted by any of the nodes
> > which routed the message and inserted a H-I entry.
> >
> > If however the H-I was allowed to include a header parameter
> > of "?Privacy=none" in the H-I entry and that an explicit H-I
> > entry privacy value would be considered to have precedence
> > over a Privacy header with a value of "history" then the
> > mapping of the +18001234567 could be explicitly specified as
> > not private and may be passed on.
> >
> (2) above is
> > included could also insert the Privacy header parameter in
> > H-I entry (1).
> >
> > This would result in all the H-I entries except (1) being
> > considered private with the result that the =1800... Number
> > is passed for call handling purposes.
> >
> > This change is backward compatible with the existing
> > implementation as any node using the existing functionality
> > as defined in RFC4244 will continue to be supported.
> >
> > in the Privacy header and only allow this value in the
> > Privacy header parameter. This alternative is not backward compatible.
> >
> > Without this change a single node in the message path which
> > includes a header "Privacy: history" will prevent delivery of
> > the aor and thus prevent proper call handling.
> >
> > Ian Elz
> >
> >
> >
> > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg;
> > Shida Schubert
> > Here was the thread of response and the last comment was from
> > Ian that he would consider the response:
> > And, there was not agreement on the "none" but rather to
> > qualify the SHOULD NOT forward.  However, in the
> > sipcore-4244bis-00, rather than changing the text such that
> > the headers SHOULD be removed, we recommend that they be
> > anonymized (in section 4.3.3.3.1).  That is entirely
> > consistent with RFC 3324 and thus we have removed the
> > recommendations to remove the headers entirely. However, that
> > changed never got done in section 3.2, so we would need to
> > change this:
> > But, I'm really beginning to be of the mindset that we should
> > just remove all the subsections of section 3 (i.e., leave the
> > text in the upper level section), so we don't have to keep
> > worrying about consistency.
> >
> > So, lets either fixt the text in 3.2 or remove altogether and
> > then I think we are really at the point of needing to submit
> > this version so folks that actually have an interest in it
> > can review the updated document.
> >
> > Mary.
> >
> > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055);
> > Hans Erik van Elburg; Shida Schubert
> > Below is a comment/proposal which one of my collegues (Ian
> > Elz) gave on the list a while ago, when the first version of
> > 4244bis was submitted, but was not incorporated. Do you think
> > it would be useful?
> >
> > -------
> >
> > While the HI approach to target may solve the problem of
> > being able to deliver the target URI to the final destination
> > there is no guarantee that it will actually be delivered.
> >
> > 4424 defines a new Privacy value "history" which may be
> > placed in either the Privacy header or as a header parameter
> > to the HI entry.
> >
> > If one node uses the former option "Privacy: history" then
> > this will make all headers private and will result in all HI
> > entries being removed or made anonymous when the message
> > containing the HI is delivered to the user.
> >
> > There is a simple solution to this and that is to also allow
> > the use of the "none" Privacy value as a header parameter in
> > the HI entry. This would explicitly state that no privacy is
> > required to the HI entry and this would override a "history"
> > value in the Privacy header.
> >
> > I pointed this out to Mary when the 4424bis draft was first
> > published but the change has not been made in the latest draft.
> >
> > The change is backward compatible and would not cause an
> > issue with any existing implementations.
> >
> > ------
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 25 Jun 2009 11:37:23 -0500

B has privacy turned on.

Is this correct? 

> sip:[email-masked] when H-I entry (2) above is

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 25 Jun 2009 11:28:50 -0500

Hi Ian,

Mary.

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Thursday, June 25, 2009 10:13 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Mary,

 
This means that if privacy is required for an individual H-I entry but
the originating user included "Privacy:none" in the request then there
is no option to include the real URI in the H-I entry.
[MB2] I'm confused here - the "none" definition is as you note below,
thus "none" prohibits the removal or anonymization of the entries, thus
I would think you would fine this functionality desireable. However,
this does not prohibit an entity based on policy to anonymize (or remove
entries if privacy is required for that domain if the entity does not
have access to a privacy service). [/MB2]

The only option for an intermediate node including a H-I entry where
"Privacy:none" is specified and privacy for the H-I URI is required is
to include an anonymous entry or not include the H-I entry.
[MB2] If privacy is required then yes, you include anonymous entries or
don't include. That's the basic privacy mechanism for privacy levels of
"session" "header" and "history" in the R-URI or "history" in the
specific entries, as well as when there is a policy for privacy for the
entries added by a specific domain. The "none" really has no influence
on the later case per se. [/MB2]

In your previous response you stated that we would violate RFC3323 if we
specified additional behaviour for privacy explicitly stated with a URI
-n the H-I entry. I don't believe that this is the case as RFC3323 only
considered privacy in a two party scenario and did not consider third
party identities being included in a message between two parties. H-I is
not the only case where this occurs as the Referred-By header when
included in the INVITE (or other request) which results from the REFER
has the same issue.
[MB2] I can't necessarily disagree on this one (we can debate it either
way). But to fix it requires an update to RFC 3323 and shouldn't be
something that we want to fix in 4244bis. [/MB2]

RFC4244 was the first time that there was a recognition that privacy for
these individual third party identities may be required. To allow this
explicit statement of privacy to be overridden by a generic statement
which is applicable to a different user is counterintuitive.
[MB2] See my comment above. But, as I have consistently said, the idea
that an entity might want to override the "none" is entirely based on
policy and 4244 and 4244bis allow privacy to be applied to the entries
that are added by that entity if the policy dictates so (and we already
say that). [/MB2]

The original Privacy header is usually included by or on behalf of the
originating user and should not be allowed to specify the privacy of the
original called user, e.g. the 800 number, and prevent this identity
being presented if this user does not have the same level of privacy.
[MB2] As I tried to say in a previous response, a random entity (i.e.,
one for whom the R-URI is not in a domain under its control) cannot add
a privacy header to the Request. Per RFC 3323 an entity may add the
header to a request only if it has the appropriate
relationship/authorization with the original called user who intiated
the request. And, I would find it very surprising if an entity that did
have responsibility would apply privacy since that would be counter
intuitive and I would hope that SPs would be judicious in specifying the
appropriate and inappropriate manner in which the proxies they deploy
and interface with privatize the messages. The protocol CANNOT control
this behavior and that's why there is the policy clause in 4244 and
4244bis. [/MB2]  

The real issue with the 800 scenario is as you have stated is that the
answerer will not know the original called identity and will not be able
to correctly handle the call. As more generic call centres are used
which will answer calls on behalf of many different organizations using
CTI and the original called identity to have to implement a generic
system asking the caller who he originally called appear unprofessional,
is inefficient and unproductive.
[MB2] And, as I noted, it is rare for a call centre to route a call
directly to an agent without a user providing some sort of input. Even
companies like American Airlines, even though they have the info that I
enter via the IVR, they still ask some basic questions and there are
times when they have to reroute me. I don't think we can totally
automate things.  And, again, once the call hits the domain that is
responsible for that 800 number the entities in that domain have control
over how they muck with the R-URI, such that they should be able to use
any IVR info to appropriately direct the call - it's not the number
that's meaningful, but how the system gets the call to the right user
and the additional information they provide as the call is presented to
the agent. I would honestly think that having something other than an
800 number show up on the display would be far more useful and in my
experience in the systems I developed we're usually talking about CTI
interfaces so you have a lot you can do.  And, actually all of this
really doesn't matter in that you MUST be able to handle this situation
independent of the privacy since History-Info is optional, you need
default behavior assigned. [/MB2] 

We have an opportunity to allow presentation of specific identities and
to solve this particular problem so we should take it.
[MB2] The most we can do is to document the risks/impacts of the use of
the Privacy headers at the R-URI level. There is already general text in
4244 and 4244bis that the privacy may impact whether the applications
get the information.  And, as I noted before, most commercial systems
are using B2BUAs which will allow you far more control over the use of
the Privacy headers in the network. But, again, I don't think that's
something that should be address in 4244bis.  [/MB2]

Regards

Ian

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 24 June 2009 17:27
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Hi Ian,

Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Wednesday, June 24, 2009 10:37 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Mary,

Can you clarify for me:

Regards 

Ian

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 24 June 2009 15:48
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Hi Ian,

Regards,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Wednesday, June 24, 2009 2:57 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

 Mary,

Ian Elz

-----Original Message-----
From: Christer Holmberg
Sent: 23 June 2009 19:40
To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert
Cc: Ian Elz
Subject: RE: 4244bis and privacy

Hi,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 9:40 PM
To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida
Schubert

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 1:10 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik

Hi,

-------

------

Regards,

Christer

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 25 Jun 2009 11:57:31 -0500

Yes.

-----Original Message-----
From: Audet, Francois (SC100:3055) 
Sent: Thursday, June 25, 2009 11:37 AM
To: Barnes, Mary (RICH2:AR00); 'Ian Elz'
Cc: 'Christer Holmberg'; 'Hans Erik van Elburg'; 'Shida Schubert';
[email-masked]'

B has privacy turned on.

I guess that would mean that B's proxy would have to parse the
History-Info and anonymize all entries corresponding to B?

Is this correct? 

> If you have a Privacy header with a value of "none" and a H-I entry 
> with Privacy header parameter with value "history" what is the privacy

> of the individual H-I entry?

> thus "none" prohibits the removal or anonymization of the entries, 
> thus I would think you would fine this functionality desireable. 
> However, this does not prohibit an entity based on policy to anonymize

> (or remove entries if privacy is required for that domain if the 
> entity does not have access to a privacy service). [/MB2]
> 

> header value of 'none' is specified in a message, privacy services 
> MUST NOT perform any privacy function and MUST NOT remove or modify 
> the Privacy header."
> 

> [MB2] If privacy is required then yes, you include anonymous entries 
> or don't include. That's the basic privacy mechanism for privacy 
> levels of "session" "header" and "history" in the R-URI or "history" 
> in the specific entries, as well as when there is a policy for privacy

> for the entries added by a specific domain. The "none" really has no 
> influence on the later case per se. [/MB2]
> 
> RFC3323 if we specified additional behaviour for privacy explicitly 
> stated with a URI -n the H-I entry. I don't believe that this is the 
> case as RFC3323 only considered privacy in a two party scenario and 
> did not consider third party identities being included in a message 
> between two parties. H-I is not the only case where this occurs as the

> [MB2] I can't necessarily disagree on this one (we can debate it 
> either way). But to fix it requires an update to RFC 3323 and 
> shouldn't be something that we want to fix in 4244bis. [/MB2]
> 
> RFC4244 was the first time that there was a recognition that privacy 
> for these individual third party identities may be required. To allow 
> this explicit statement of privacy to be overridden by a generic 
> statement which is applicable to a different user is counterintuitive.

> that are added by that entity if the policy dictates so (and we 
> already say that). [/MB2]
> 

> originating user and should not be allowed to specify the privacy of 
> the original called user, e.g. the 800 number, and prevent this 
> identity being presented if this user does not have the same level of 
> privacy.

> one for whom the R-URI is not in a domain under its control) cannot 
> add a privacy header to the Request. Per RFC 3323 an entity may add 
> the header to a request only if it has the appropriate 
> the request. And, I would find it very surprising if an entity that 
> did have responsibility would apply privacy since that would be 
> counter intuitive and I would hope that SPs would be judicious in 
> specifying the appropriate and inappropriate manner in which the 
> proxies they deploy and interface with privatize the messages. The 
> protocol CANNOT control this behavior and that's why there is the 
> policy clause in 4244 and 4244bis. [/MB2]
> 

> answerer will not know the original called identity and will not be 
> able to correctly handle the call. As more generic call centres are 
> used which will answer calls on behalf of many different organizations

> using CTI and the original called identity to have to implement a 
> generic system asking the caller who he originally called appear 

> companies like American Airlines, even though they have the info that 
> I enter via the IVR, they still ask some basic questions and there are

> responsible for that 800 number the entities in that domain have 
> control over how they muck with the R-URI, such that they should be 
> able to use any IVR info to appropriately direct the call - it's not 
> the number that's meaningful, but how the system gets the call to the 
> right user and the additional information they provide as the call is 
> presented to the agent. I would honestly think that having something 
> other than an 800 number show up on the display would be far more 
> useful and in my experience in the systems I developed we're usually 
> talking about CTI interfaces so you have a lot you can do.  And, 
> actually all of this really doesn't matter in that you MUST be able to

> handle this situation independent of the privacy since History-Info is

> optional, you need default behavior assigned. [/MB2]
> 
> We have an opportunity to allow presentation of specific identities 
> and to solve this particular problem so we should take it.
> [MB2] The most we can do is to document the risks/impacts of the use 
> of the Privacy headers at the R-URI level. There is already general 
> text in 4244 and 4244bis that the privacy may impact whether the 
> applications get the information.  And, as I noted before, most 
> commercial systems are using B2BUAs which will allow you far more 
> control over the use of the Privacy headers in the network. But, 
> again, I don't think that's something that should be address in 
> 4244bis.  [/MB2]
> 

> they can modify their local policy accordingly or arrange with the 
> proxy vendor to modify their equipment to be more flexible with 
> regards to policy.
> 
> Can you clarify for me:
> 
> If you have a Privacy header with either "session" or "header" doe 
> this impact the H-I entries or will only a value of "history" impact 
> the H-I entries?
> [MB] Yes, both "session" and "header" level privacy, consistent with 
> RFC 3323, mandate that entries be anonymized or dropped, with the 
> latter being the recommendation for "session" level privacy. RFC 4244 
> mandated that they be dropped and 4244bis recommends they be 
> anonymized. The original intent for the value of "history" was for the

> tagging of the individual entries, but you end up getting the header 
> level functionality as well. [/MB]
> 
> If you have a Privacy header with a value of "none" and a H-I entry 
> with Privacy header parameter with value "history" what is the privacy

> of the individual H-I entry?

> will effectively make all H-I entries private and there is currently 
> no option to  include a H-I Privacy header parameter with value 
> "none".
> explicitly express privacy for an individual H-I entry but a single 
> node which includes a header "Privacy:
> history" makes all H-I entries private even if this is not the 
> requirements for the specific URI.

> time I am used to having privacy of identities set on a per number 
> basis and the relative inflexibility of the IETF Privacy header is 
> relatively restrictive as to specifying which identities may be 
> presented and which not.
> [MB] Yes, this is an entirely different paradigm.  I developed 
> telephony s/w for over a decade and this is entirely different - it 
> provides a lot more flexibility, which makes things far, far less 
> deterministic than what you have in telephony switches where your 
> routing and translations are configured for the most part, with just a

> few capabilities for controlling the privacy and it's a closed 
> network.
> 
> application that can handle a request that doesn't have the 
> appropriate information either because nodes didn't support 
> History-Info or some random node in the network applied privacy (which

> I think is highly
> unlikely) - this is normative per section 5 of RFC 4244.  So, the 
> worst case scenario I see for this 800 service  (which will get to the

> right UAS but without the exact 800 number that was dialed) is that it

> goes to a default ACD group/customer service agent, etc. who then 
> needs to gather the appropriate information and in my experience this 
> is often an IVR system these days.  So, the service is not broken when

> privacy is applied in an undesireable manner, it's just not optimal.  
> This is something that should be addressed in the target-uri draft 
> which has all the details of how specific services use History-Info.

> the header rather than the proxy rules, noting that the UAC can set 
> the Privacy header to whatever value it sees as appropriate for the 
> request.
> [/MB]
> 
> 
> Regards
> 
> Ian
> 
> information that might violate their local policies and indeed a 
> proxy's local policies can result in the information being anonymized 
> (or removed if they can't
> I do believe it's reasonable that we strongly recommend that the 
> request level (versus specific hi-entries) not be used and if it is 
> used, the consequence is that some services will not have the 
> information they need - this was the gist of my previous response (to 
> which I did not get any additional feedback). Now, we could add some 
> text that the "none"
> think it is then particularly useful to add logic around the proxy 
> then being able to tag the entries within their domain as subject to 
> privacy.
> However, as I mention above, per the current text, a proxy can (based 
> on local policy) remove entries - so a proxy can capture hi within 
> their domain and not forward any of that information to the next hop 
> in another domain - you already have that functionality.  But, I think

> this introduces the general problem that you might be impacting other 
> services further down the line, which I thought was the problem you 
> were wanting to solve - not specifically your example service but, for

> example, in the case that someone is debugging and they want the 
> entire history, so depending upon the service, this is also 
> undesirable behavior.
> 
> 
> Regards,
> Mary. 
> 

> location may be a call centre where the original freephone number may 
> be required for correct call handling.
> 
> If you now consider the following example (modified from Francois' 
> text in the latest draft - excuse any errors that I may have inserted)
> 
> "?Privacy=none" in the H-I entry and that an explicit H-I entry 
> privacy value would be considered to have precedence over a Privacy 
> header with a value of "history" then the mapping of the +18001234567 
> could be explicitly specified as not private and may be passed on.
> 

> changing the text such that the headers SHOULD be removed, we 
> recommend that they be anonymized (in section 4.3.3.3.1).  That is 
> entirely consistent with RFC 3324 and thus we have removed the 
> recommendations to remove the headers entirely. However, that changed 
> never got done in section 3.2, so we would need to change this:

> Elz) gave on the list a while ago, when the first version of 4244bis 
> was submitted, but was not incorporated. Do you think it would be 
> useful?
> 
> -------
> 

> 4424 defines a new Privacy value "history" which may be placed in 
> either the Privacy header or as a header parameter to the HI entry.
> 
> make all headers private and will result in all HI entries being 
> removed or made anonymous when the message containing the HI is 
> delivered to the user.
> 
> There is a simple solution to this and that is to also allow the use 
> of the "none" Privacy value as a header parameter in the HI entry. 
> This would explicitly state that no privacy is required to the HI 
> entry and this would override a "history"
> The change is backward compatible and would not cause an issue with 
> any existing implementations.
> 
> ------
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
>

---

From: <[email-masked]>
Date: Thu, 25 Jun 2009 21:13:41 +0200

Hi Marry and Ian,
The whole discussion puzzle me. We have specified CDIV within TISPAN and 3GPP. 
There is described that privacy "none" can be used for entries. BUT assuming that each entry has its own privacy statement if needed. 
I fully agree on Mary's comment that a privacy "history" cannot overruled by a privacy value "none" within a entry. 
There may be operators that would like to keep the whole History Info private even if entries has other statements, so the entity could add privacy history to the whole header. Nothing more.

On the other side a Application Server including a entry should have the possibility to rewrite the entries so that instead of "history" for the whole header the all received entries within the History-Info header will be marked with "history" and the added header (which shall be presented to the terminating user) will either be marked with "none" or will not be marked.

Perhaps a hint could be given, but I do not insist on it.

Best Regards,

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Mary Barnes
Gesendet: Donnerstag, 25. Juni 2009 18:29
An: Ian Elz
Cc: [email-masked]; Shida Schubert
Betreff: Re: [sipcore] 4244bis and privacy

Hi Ian,

Mary.

-----Original Message-----
From: Ian Elz [mailto:[email-masked]] 
Sent: Thursday, June 25, 2009 10:13 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Mary,

 

Regards

Ian

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 24 June 2009 17:27
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Hi Ian,

Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Wednesday, June 24, 2009 10:37 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Mary,

Can you clarify for me:

Regards 

Ian

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: 24 June 2009 15:48
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

Hi Ian,

Regards,
Mary. 

-----Original Message-----
From: Ian Elz [mailto:[email-masked]]
Sent: Wednesday, June 24, 2009 2:57 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;

 Mary,

Ian Elz

-----Original Message-----
From: Christer Holmberg
Sent: 23 June 2009 19:40
To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert
Cc: Ian Elz
Subject: RE: 4244bis and privacy

Hi,

Regards,

Christer

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 9:40 PM
To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida
Schubert

Mary. 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, June 23, 2009 1:10 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik

Hi,

-------

------

Regards,

Christer

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 25 Jun 2009 22:32:09 +0200

Hi Roland,

I don't understand the argument, by the time that the History-Info 
leaves operator A that wishes complete privacy, all the History-Info 
headers should be anonymised according to 4244 and 4244bis.

What is the point in mandating that operator A to force operator B to 
also anonymise the entries "owned" by operator B.

It is of course without question that each operator has full privacy 
control over its own added entries. And each operator can based on local 
policy decide to remove the entire history if it things that is wise to do.

/Hans Erik

---

From: <[email-masked]>
Date: Thu, 25 Jun 2009 23:31:36 +0200

Hi Hans Erik,
We have also to take regulatory into consideration. In Germany the last trusted network is responsible for anonymising information. 

But nevertheless if Network provider A wants to have History completely private this operator will set privacy history for the header.
If the succeeding Operator want to present elements the AS which adds a entry has then to re label all entries from the preceding network and the entries from it's own network will be unmarked within the Header.

But never the less I fully agree to your last sentence.

The real Question is if this should really be allowed that a entry marked with "none" overrules the privacy statement "history" for the complete header.

I'm against this behaviour. 

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Hans Erik van Elburg [mailto:[email-masked]] 
Gesendet: Donnerstag, 25. Juni 2009 22:32
An: Jesske, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [sipcore] 4244bis and privacy

Hi Roland,

/Hans Erik

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 25 Jun 2009 16:34:48 -0500

I agree with Hans and the important point is the last statement. A proxy can add as many entries as they want within their domain(s) of responsibility, it's when that message leaves that domain, that the message MUST follow the RFC 3323 rules for the message.  And, I do think the issues being discussed are more with how RFC 3323 is specified than with the use of privacy in 4244/4244bis.  We reference RFC 3323 and I think it would cause more problems than it would help to try to pull in more detail as to how that works with History-Info. To me, that's more something that the applications must consider and I believe we have enough information in the document currently telling them such. The best approach IMHO would be to add some of the examples we have been discussing to the target-uri document which describes how you can realize these services using the core SIP building blocks of 4244/4244bis and RFC 3323.  

Regards,
Mary. 

-----Original Message-----
From: Hans Erik van Elburg [mailto:[email-masked]] 
Sent: Thursday, June 25, 2009 3:32 PM
To: [email-masked]
Cc: Barnes, Mary (RICH2:AR00); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sipcore] 4244bis and privacy

Hi Roland,

I don't understand the argument, by the time that the History-Info leaves operator A that wishes complete privacy, all the History-Info headers should be anonymised according to 4244 and 4244bis.

What is the point in mandating that operator A to force operator B to also anonymise the entries "owned" by operator B.

It is of course without question that each operator has full privacy control over its own added entries. And each operator can based on local policy decide to remove the entire history if it things that is wise to do.

/Hans Erik

[email-masked] wrote:
> In your previous response you stated that we would violate RFC3323 if 
> we specified additional behaviour for privacy explicitly stated with a 
> URI -n the H-I entry. I don't believe that this is the case as RFC3323 
> only considered privacy in a two party scenario and did not consider 
> third party identities being included in a message between two 
> parties. H-I is not the only case where this occurs as the Referred-By 
> header when included in the INVITE (or other request) which results 
> from the REFER has the same issue.
> identity being presented if this user does not have the same level of privacy.
> text in
> node which includes a header "Privacy: history" makes all H-I entries 
> private even if this is not the requirements for the specific URI.
> few capabilities for controlling the privacy and it's a closed network.
>
> the Privacy header to whatever value it sees as appropriate for the request.
> [/MB]
>
>
> Regards
>
> Ian
>
> (or removed if they can't anonymize) even in the "none" case.
>
> which I did not get any additional feedback). Now, we could add some text that the "none"
> then being able to tag the entries within their domain as subject to privacy.
> Below is a comment/proposal which one of my collegues (Ian Elz) gave 
> on the list a while ago, when the first version of 4244bis was 
> submitted, but was not incorporated. Do you think it would be useful?
>
> -------
>
> entry and this would override a "history" value in the Privacy header.
>

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 25 Jun 2009 16:45:22 -0500

Roland,

The reason you can't have "none" at the request level and "history" at the entry level is because RFC 3323 states that you MUST NOT apply privacy to the message. Even if you put "history" in the entries, the privacy service would just ignore that - per RFC 3323.  So, if you want to change that behavior, then RFC 3323 should be changed - i.e., the MUST NOT for the "none" could be changed to a SHOULD NOT and then a general statement about possible exceptions. Then, we could add something to RFC 4244 for this case. But, changing RFC 3323 is totally out of scope for what we are currently working on.  

That all said, I would sure think that if you are leaving a "trusted network" that you have a B2BUA in there, as I've said in other threads. Thus, the B2BUA builds a new request and certainly can add a privacy header that it believes is appropriate since the outgoing request is done by the UAC function of a B2BUA. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 25, 2009 4:32 PM
To: [email-masked]
Cc: Barnes, Mary (RICH2:AR00); [email-masked]; [email-masked]; [email-masked]
Subject: AW: [sipcore] 4244bis and privacy

Hi Hans Erik,

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Hans Erik van Elburg [mailto:[email-masked]]
Gesendet: Donnerstag, 25. Juni 2009 22:32
An: Jesske, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [sipcore] 4244bis and privacy

Hi Roland,

/Hans Erik

---

From: <[email-masked]>
Date: Fri, 26 Jun 2009 00:01:42 +0200

Mary,
As I said before I don't want this behaviour. 

So everything shall be as it is already described.

Roland 

-----Ursprüngliche Nachricht-----
Von: Mary Barnes [mailto:[email-masked]] 
Gesendet: Donnerstag, 25. Juni 2009 23:45
An: Jesske, Roland; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sipcore] 4244bis and privacy

Roland,

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 25, 2009 4:32 PM
To: [email-masked]
Cc: Barnes, Mary (RICH2:AR00); [email-masked]; [email-masked]; [email-masked]
Subject: AW: [sipcore] 4244bis and privacy

Hi Hans Erik,

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Hans Erik van Elburg [mailto:[email-masked]]
Gesendet: Donnerstag, 25. Juni 2009 22:32
An: Jesske, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [sipcore] 4244bis and privacy

Hi Roland,

/Hans Erik

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 25 Jun 2009 17:33:19 -0500

Okay - I see what you were saying now - so no issue at all.

Thanks,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 25, 2009 5:02 PM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: AW: [sipcore] 4244bis and privacy

Mary,

Roland 

-----Ursprüngliche Nachricht-----
Von: Mary Barnes [mailto:[email-masked]]
Gesendet: Donnerstag, 25. Juni 2009 23:45
An: Jesske, Roland; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [sipcore] 4244bis and privacy

Roland,

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 25, 2009 4:32 PM
To: [email-masked]
Cc: Barnes, Mary (RICH2:AR00); [email-masked]; [email-masked]; [email-masked]
Subject: AW: [sipcore] 4244bis and privacy

Hi Hans Erik,

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Hans Erik van Elburg [mailto:[email-masked]]
Gesendet: Donnerstag, 25. Juni 2009 22:32
An: Jesske, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [sipcore] 4244bis and privacy

Hi Roland,

/Hans Erik

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 26 Jun 2009 08:30:17 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mary Barnes
> Sent: 25 June 2009 22:45
> To: [email-masked]; [email-masked]
> The reason you can't have "none" at the request level and 
> "history" at the entry level is because RFC 3323 states that 
> you MUST NOT apply privacy to the message. Even if you put 
> "history" in the entries, the privacy service would just 
> ignore that - per RFC 3323.  So, if you want to change that 
> behavior, then RFC 3323 should be changed - i.e., the MUST 
> NOT for the "none" could be changed to a SHOULD NOT and then 
> a general statement about possible exceptions. Then, we could 
> add something to RFC 4244 for this case. But, changing RFC 
> 3323 is totally out of scope for what we are currently working on.  
[JRE] I would interpret privacy 'none' in RFC 3323 as meaning that a downstream entity must not anonymise or remove any information that the UAC has already placed in the request. If a downstream entity chooses:
- not to add H-I,
- to add anonymised H-I, or
- to anonymise an H-I entry that some intermediate entity has added,
I don't see that as being in violation of what the UAC has requested.

John

> 
> That all said, I would sure think that if you are leaving a 
> "trusted network" that you have a B2BUA in there, as I've 
> said in other threads. Thus, the B2BUA builds a new request 
> and certainly can add a privacy header that it believes is 
> appropriate since the outgoing request is done by the UAC 
> function of a B2BUA. 
> 
> Mary. 
> 
> 
> We have also to take regulatory into consideration. In 
> Germany the last trusted network is responsible for 
> anonymising information. 
> 
> But nevertheless if Network provider A wants to have History 
> completely private this operator will set privacy history for 
> the header.
> If the succeeding Operator want to present elements the AS 
> which adds a entry has then to re label all entries from the 
> preceding network and the entries from it's own network will 
> be unmarked within the Header.
> 
> The real Question is if this should really be allowed that a 
> entry marked with "none" overrules the privacy statement 
> "history" for the complete header.
> 
> I don't understand the argument, by the time that the 
> History-Info leaves operator A that wishes complete privacy, 
> all the History-Info headers should be anonymised according 
> to 4244 and 4244bis.
> 
> What is the point in mandating that operator A to force 
> operator B to also anonymise the entries "owned" by operator B.
> 
> It is of course without question that each operator has full 
> privacy control over its own added entries. And each operator 
> can based on local policy decide to remove the entire history 
> if it things that is wise to do.
> 
> /Hans Erik
> 
> 
> > There is described that privacy "none" can be used for 
> entries. BUT assuming that each entry has its own privacy 
> statement if needed. 
> > I fully agree on Mary's comment that a privacy "history" 
> cannot overruled by a privacy value "none" within a entry. 
> > There may be operators that would like to keep the whole 
> History Info private even if entries has other statements, so 
> the entity could add privacy history to the whole header. 
> Nothing more.
> >
> > On the other side a Application Server including a entry 
> should have the possibility to rewrite the entries so that 
> instead of "history" for the whole header the all received 
> entries within the History-Info header will be marked with 
> "history" and the added header (which shall be presented to 
> the terminating user) will either be marked with "none" or 
> will not be marked.
> >
> note below, 
> the Privacy 
> entry where 
> RFC3323 if 
> Referred-By 
> behalf of the 
> entity (i.e., 
> consistent with 
> for a long 
> emulating 
> think that 
> can (based 
> answering 
> included could 
> considered 
> implementation as 
> Privacy header 
> includes a 
> qualify the 
> Elz) gave 
> being able to 
> this will 
> published

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 26 Jun 2009 10:07:30 +0200

John,

Your statement " not anonymise or remove any information that the UAC has already placed in the request " is the key here.

The UAC has not included the H-I entry, particularly the one containing the identity of the diverting party.

This was not considered in RFC3323 and we have an issue where we cannot determine which entity included which information. This creates a problem where a restriction by the originating party will prevent a downstream identity from permitting presentation of their identity.

I agree with Mary that this probably requires an update to RFC3323 so we should start by updating RFC3323 and then move on to the other impacted RFCs. The issue that this will raise for H-I is that there will be another change required after the Privacy RFC has been agreed.

This is far from ideal but the 4424bis draft contains a lot more than just this issue.

Ian

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 26 June 2009 08:30
To: Mary Barnes; [email-masked]; [email-masked]
Cc: Ian Elz; [email-masked]; [email-masked]
Subject: RE: [sipcore] 4244bis and privacy

> The reason you can't have "none" at the request level and "history" at 
> the entry level is because RFC 3323 states that you MUST NOT apply 
> privacy to the message. Even if you put "history" in the entries, the 
> privacy service would just ignore that - per RFC 3323.  So, if you 
> want to change that behavior, then RFC 3323 should be changed - i.e., 
> the MUST NOT for the "none" could be changed to a SHOULD NOT and then 
> a general statement about possible exceptions. Then, we could add 
> something to RFC 4244 for this case. But, changing RFC
[JRE] I would interpret privacy 'none' in RFC 3323 as meaning that a downstream entity must not anonymise or remove any information that the UAC has already placed in the request. If a downstream entity chooses:
- not to add H-I,
- to add anonymised H-I, or
- to anonymise an H-I entry that some intermediate entity has added, I don't see that as being in violation of what the UAC has requested.

John

> 
> That all said, I would sure think that if you are leaving a "trusted 
> network" that you have a B2BUA in there, as I've said in other 
> threads. Thus, the B2BUA builds a new request and certainly can add a 
> privacy header that it believes is appropriate since the outgoing 
> request is done by the UAC function of a B2BUA.
> 
> Mary. 
> 
> 
> We have also to take regulatory into consideration. In Germany the 
> last trusted network is responsible for anonymising information.
> 
> completely private this operator will set privacy history for the 
> header.
> If the succeeding Operator want to present elements the AS which adds 
> a entry has then to re label all entries from the preceding network 
> and the entries from it's own network will be unmarked within the 
> Header.
> 
> The real Question is if this should really be allowed that a entry 
> marked with "none" overrules the privacy statement "history" for the 
> complete header.
> 
> control over its own added entries. And each operator can based on 
> local policy decide to remove the entire history if it things that is 
> wise to do.
> 
> /Hans Erik
> 
> 
> entries. BUT assuming that each entry has its own privacy statement if 
> needed.
> History Info private even if entries has other statements, so the 
> entity could add privacy history to the whole header.
> Nothing more.
> >
> should have the possibility to rewrite the entries so that instead of 
> "history" for the whole header the all received entries within the 
> History-Info header will be marked with "history" and the added header 
> (which shall be presented to the terminating user) will either be 
> marked with "none" or will not be marked.
> >

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 26 Jun 2009 10:54:56 -0500

I do see things that we should fix right-away in History-Info, regarding privacy.

I also think that History-Info shouldn't "overstrech" and get too deep
into the nitty gritty of privacy. What should be in HI is high level guidance.

In section 3.1, for example, it says that Privacy header will determine if
a History-Info *header field* can be included by an intermediary. This does not make any
sense. What it should say is that the Privacy header will determine if 
a history-info *entry* can be added for the UA inserting the Privacy header.

So, in my opinion, we can go ahead and fix that right now.

I don't think we need to get into super low-level procedural 
descriptions of the type "proxy MUST this and that if Privacy ==
this and that". I believe privacy matters are policy-level decisions
that service providers and enteprises will have, and they are not going 
to be implemented by simplistic procedural rules from an RFC.

Comments?

> [mailto:[email-masked]] On Behalf Of Ian Elz
> Sent: Friday, June 26, 2009 01:08
> To: Elwell, John; Barnes, Mary (RICH2:AR00); 
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Your statement " not anonymise or remove any information that 
> the UAC has already placed in the request " is the key here.
> 
> The UAC has not included the H-I entry, particularly the one 
> containing the identity of the diverting party.
> 
> This was not considered in RFC3323 and we have an issue where 
> we cannot determine which entity included which information. 
> This creates a problem where a restriction by the originating 
> party will prevent a downstream identity from permitting 
> presentation of their identity.
> 
> I agree with Mary that this probably requires an update to 
> RFC3323 so we should start by updating RFC3323 and then move 
> on to the other impacted RFCs. The issue that this will raise 
> for H-I is that there will be another change required after 
> the Privacy RFC has been agreed.
> 
> "history" at 
> [JRE] I would interpret privacy 'none' in RFC 3323 as meaning 
> that a downstream entity must not anonymise or remove any 
> information that the UAC has already placed in the request. 
> If a downstream entity chooses:
> - not to add H-I,
> - to anonymise an H-I entry that some intermediate entity has 
> added, I don't see that as being in violation of what the UAC 
> has requested.
> 
> John
> 
> 
> > 
> "trusted 
> > Cc: Barnes, Mary (RICH2:AR00); [email-masked]; 
> [email-masked]; 
> > [email-masked]
> which adds 
> operator B to 
> statement if 
> instead of 
> > > Von: [email-masked] 
> [mailto:[email-masked]] Im 
> > > Auftrag von Mary Barnes
> identities 
> "header" doe 
> parameters to 
> Francois'

---

From: "Ian Elz" <[email-masked]>
Date: Mon, 29 Jun 2009 12:26:11 +0200

Francios,

I agree that 4244bis should not specify the actions of proxies etc where this is a matter of local policy.

My original proposed change was to allow the inclusion of the value "none" in the alongside the value "history" to be included in the Privacy header parameter escaped in the hi-targeted-to-uri. (RFC4244 section 4.1)

It appears however that the current interpretation of the Privacy header means that the value included in the Privacy header, which is applicable to the originating rather than retargeting user is applied to the retargeting user rather than the explicit value included for the retargeting user. The escaped privacy value is only used if there is no Privacy header or the Privacy header only contains the value "user".

The end result of this interpretation is that including an explicit value "none" escaped as a Privacy parameter would have no effect and would have the same meaning as not including a Privacy header parameter escaped in the hi-targeted-to-uri.

4244bis is not the place to extend the sip Privacy handling to specify how 3rd party identities in sip messages should have their own specific privacy maintained.

Allowing the inclusion of the explicitly Privacy=none value in the hi-targeted-to-uri would not change any handling at this time but would make the new H-I RFC suitable for use if an updated privacy RFC is proposed which does have specific support for 3rd party identities.

H-I is not the only place where the explicit privacy of 3rd party identities is required. The Referred-By header is one other case where a similar explicit privacy may need to be considered in the future.

regards

Ian

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: 26 June 2009 16:55
To: Ian Elz; Elwell, John; Mary Barnes; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [sipcore] 4244bis and privacy

I also think that History-Info shouldn't "overstrech" and get too deep into the nitty gritty of privacy. What should be in HI is high level guidance.

In section 3.1, for example, it says that Privacy header will determine if a History-Info *header field* can be included by an intermediary. This does not make any sense. What it should say is that the Privacy header will determine if a history-info *entry* can be added for the UA inserting the Privacy header.

I don't think we need to get into super low-level procedural descriptions of the type "proxy MUST this and that if Privacy == this and that". I believe privacy matters are policy-level decisions that service providers and enteprises will have, and they are not going to be implemented by simplistic procedural rules from an RFC.

Comments?

> To: Elwell, John; Barnes, Mary (RICH2:AR00); [email-masked]; 
> [email-masked]
> Your statement " not anonymise or remove any information that the UAC 
> has already placed in the request " is the key here.
> 
> This was not considered in RFC3323 and we have an issue where we 
> cannot determine which entity included which information.
> This creates a problem where a restriction by the originating party 
> will prevent a downstream identity from permitting presentation of 
> their identity.
> 
> RFC3323 so we should start by updating RFC3323 and then move on to the 
> other impacted RFCs. The issue that this will raise for H-I is that 
> there will be another change required after the Privacy RFC has been 
> agreed.
> 
> [JRE] I would interpret privacy 'none' in RFC 3323 as meaning that a 
> downstream entity must not anonymise or remove any information that 
> the UAC has already placed in the request.
> - to anonymise an H-I entry that some intermediate entity has added, I 
> don't see that as being in violation of what the UAC has requested.
> 
> John
> 
> 
> >

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 29 Jun 2009 18:05:47 -0500

I think the current "interpretation" is not terribly useful. I prefer
your suggestion. The current RFC 4244 text is not very clear.

It seems to me that:
- Privacy should associated with a specific hi-entry (and perhaps any
  entry that corresponds to that same user), and not the header itself.
- That way, it is possible that specific entries be anonymize, but not
  others. For example, if you call me without privacy, and I call forward
  you to John with privacy setup for myself, John should see an entry for
  you and an anonymized entry for me.
- There is no reason why "none" couldn't be used in this context. Again, 
  with the same example as above, John could requies "none" for him, and
  I could set privacy on for myself.

I don't think this type of rule for 4244bis would require any change
whatsoever to RFC 3323. It would be completely self-contained in
4244bis.

Comments?

> Sent: Monday, June 29, 2009 03:26
> To: Audet, Francois (SC100:3055); Elwell, John; Barnes, Mary 
> (RICH2:AR00); [email-masked]; [email-masked]
> I agree that 4244bis should not specify the actions of 
> proxies etc where this is a matter of local policy.
> 
> My original proposed change was to allow the inclusion of the 
> value "none" in the alongside the value "history" to be 
> included in the Privacy header parameter escaped in the 
> hi-targeted-to-uri. (RFC4244 section 4.1)
> 
> It appears however that the current interpretation of the 
> Privacy header means that the value included in the Privacy 
> header, which is applicable to the originating rather than 
> retargeting user is applied to the retargeting user rather 
> than the explicit value included for the retargeting user. 
> The escaped privacy value is only used if there is no Privacy 
> header or the Privacy header only contains the value "user".
> 
> The end result of this interpretation is that including an 
> explicit value "none" escaped as a Privacy parameter would 
> have no effect and would have the same meaning as not 
> including a Privacy header parameter escaped in the 
> hi-targeted-to-uri.
> 
> 4244bis is not the place to extend the sip Privacy handling 
> to specify how 3rd party identities in sip messages should 
> have their own specific privacy maintained.
> 
> Allowing the inclusion of the explicitly Privacy=none value 
> in the hi-targeted-to-uri would not change any handling at 
> this time but would make the new H-I RFC suitable for use if 
> an updated privacy RFC is proposed which does have specific 
> support for 3rd party identities.
> 
> H-I is not the only place where the explicit privacy of 3rd 
> party identities is required. The Referred-By header is one 
> other case where a similar explicit privacy may need to be 
> considered in the future.
> 
> regards
> 
> Ian
> 
> I also think that History-Info shouldn't "overstrech" and get 
> too deep into the nitty gritty of privacy. What should be in 
> HI is high level guidance.
> 
> In section 3.1, for example, it says that Privacy header will 
> determine if a History-Info *header field* can be included by 
> an intermediary. This does not make any sense. What it should 
> say is that the Privacy header will determine if a 
> history-info *entry* can be added for the UA inserting the 
> Privacy header.
> 
> descriptions of the type "proxy MUST this and that if Privacy 
> == this and that". I believe privacy matters are policy-level 
> decisions that service providers and enteprises will have, 
> and they are not going to be implemented by simplistic 
> procedural rules from an RFC.
> 
> Comments?
>  
> 
> > This is far from ideal but the 4424bis draft contains a lot 
> more than 
> > just this issue.
> > 
> > Ian
> > 
> Germany the 
> > > Cc: [email-masked]; [email-masked]; 
> [email-masked]; 
> > > [email-masked]
> judicious in 
> placed in

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 30 Jun 2009 08:30:11 +0100

Yes, I think something like this makes sense.

John 

> Sent: 30 June 2009 00:06
> developed 
> > > > > To: 'Mary Barnes'; Francois Audet; Hans Erik van 
> Elburg; Shida 
> > > > > Schubert
> > > > > Cc: Ian Elz
> [mailto:[email-masked]]

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 30 Jun 2009 12:38:26 -0500

Ok, I'll go ahead and write something up along those lines in the draft).

I will avoid getting into nitty gritty details in 4244bis because
I don't think we should be stepping on the toes of greater
Privacy issues (i.e., enhancement to 3323, extending for 
multiparty, and so on). 

Cheers.

> Sent: Tuesday, June 30, 2009 00:30
> To: Audet, Francois (SC100:3055); Ian Elz; Barnes, Mary 
> >   you to John with privacy setup for myself, John should 
> see an entry 
> > for
> > > My original proposed change was to allow the inclusion of 
> the value 
> > > "none" in the alongside the value "history" to be included in the 
> > > Privacy header parameter escaped in the 
> > > It appears however that the current interpretation of the Privacy 
> > > header means that the value included in the Privacy 
> header, which is 
> > > applicable to the originating rather than retargeting user is 
> > > applied to the retargeting user rather than the explicit value 
> > > included for the retargeting user.
> > > The escaped privacy value is only used if there is no 
> Privacy header 
> > > or the Privacy header only contains the value "user".
> > > 
> > > The end result of this interpretation is that including 
> an explicit 
> > > value "none" escaped as a Privacy parameter would have no 
> effect and 
> > > would have the same meaning as not including a Privacy header 
> > > parameter escaped in the hi-targeted-to-uri.
> > > 
> > > 4244bis is not the place to extend the sip Privacy handling to 
> > > specify how 3rd party identities in sip messages should 
> have their 
> > > Allowing the inclusion of the explicitly Privacy=none 
> value in the 
> > > hi-targeted-to-uri would not change any handling at this time but 
> > > would make the new H-I RFC suitable for use if an updated privacy 
> > > RFC is proposed which does have specific support for 3rd party 
> > > identities.
> > > 
> > > H-I is not the only place where the explicit privacy of 3rd party 
> > > identities is required. The Referred-By header is one other case 
> > > where a similar explicit privacy may need to be considered in the 
> > > future.
> > > 
> > > regards
> > > 
> > > Ian
> > > 
> > > I also think that History-Info shouldn't "overstrech" and get too 
> > > deep into the nitty gritty of privacy. What should be in 
> HI is high 
> > > level guidance.
> > > 
> > > determine if a History-Info *header field* can be included by an 
> > > intermediary. This does not make any sense. What it should say is 
> > > that the Privacy header will determine if a history-info 
> *entry* can 
> > > be added for the UA inserting the Privacy header.
> > > 
> > > that service providers and enteprises will have, and they are not 
> > > going to be implemented by simplistic procedural rules 
> from an RFC.
> > > 
> > > Comments?
> > >  
> > >