Re: [sipcore] 4244bis and privacy

[Hans Erik van Elburg <[e-mail]>]

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 <[e-mail]> wrote:

> Mary,
>
> I am a little concerned about one answer that you gave:
>
>
> 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.
>
> 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:[e-mail]]
> Sent: 24 June 2009 17:27
> To: Ian Elz
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
> [e-mail]; Francois Audet
> Subject: RE: 4244bis and privacy
>
> Hi Ian,
>
> Responses inline below [MB].
>
> Mary.
>
> -----Original Message-----
> From: Ian Elz [mailto:[e-mail]]
> Sent: Wednesday, June 24, 2009 10:37 AM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
> [e-mail]; Audet, Francois (SC100:3055)
> Subject: RE: 4244bis and privacy
>
> 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:[e-mail]]
> Sent: 24 June 2009 15:48
> To: Ian Elz
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
> [e-mail]; Francois Audet
> Subject: RE: 4244bis and privacy
>
> 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:[e-mail]]
> Sent: Wednesday, June 24, 2009 2:57 AM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
> [e-mail]; Audet, Francois (SC100:3055)
> Subject: RE: 4244bis and privacy
>
>
>  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:[e-mail]<[e-mail]>
> ;user=phone;p=x
> Privacy: history
> History-Info:
> <sip:[e-mail] <[e-mail]>;user=phone;p=x>;index=1;rt;aor
>         (1)
> History-Info: <sip:[e-mail] <[e-mail]>
> >;index=1.1;mp;aor
> (2)
> History-Info: <sip:bob@192.0.2.3 <sip%3Abob@192.0.2.3>>;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 [phone] 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 [phone] could be
> explicitly specified as not private and may be passed on.
>
> Thus when the mapping from sip:[e-mail]<[e-mail]>to
> sip:[e-mail] <[e-mail]> 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:[e-mail]<[e-mail]>;
> user=phone;p=x
> Privacy: history
> History-Info:
> <sip:[e-mail]?Privacy=none;user=phone;p=x>;index=1;rt;ao
> r
> History-Info: <sip:[e-mail] <[e-mail]>
> >;index=1.1;mp;aor
> History-Info: <sip:bob@192.0.2.3 <sip%3Abob@192.0.2.3>>;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:[e-mail]]
> 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:[e-mail]]
> 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
>
>
>
>
>