Re: [sipcore] 4244bis and privacy

["Elwell, John" <[e-mail]>]

Yes, I think something like this makes sense.

John 

> -----Original Message-----
> From: Francois Audet [mailto:[e-mail]] 
> Sent: 30 June 2009 00:06
> To: Ian Elz; Elwell, John; Mary Barnes; [e-mail]; 
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [sipcore] 4244bis and privacy
> 
> 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?
> 
> > -----Original Message-----
> > From: Ian Elz [mailto:[e-mail]] 
> > Sent: Monday, June 29, 2009 03:26
> > To: Audet, Francois (SC100:3055); Elwell, John; Barnes, Mary 
> > (RICH2:AR00); [e-mail]; [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [sipcore] 4244bis and privacy
> > 
> > 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:[e-mail]]
> > Sent: 26 June 2009 16:55
> > To: Ian Elz; Elwell, John; Mary Barnes; [e-mail]; 
> > [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [sipcore] 4244bis and privacy
> > 
> > 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?
> >  
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Ian Elz
> > > Sent: Friday, June 26, 2009 01:08
> > > To: Elwell, John; Barnes, Mary (RICH2:AR00); [e-mail]; 
> > > [e-mail]
> > > Cc: [e-mail]; [e-mail]
> > > Subject: Re: [sipcore] 4244bis and privacy
> > > 
> > > 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:[e-mail]]
> > > Sent: 26 June 2009 08:30
> > > To: Mary Barnes; [e-mail]; [e-mail]
> > > Cc: Ian Elz; [e-mail]; [e-mail]
> > > Subject: RE: [sipcore] 4244bis and privacy
> > > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Mary Barnes
> > > > Sent: 25 June 2009 22:45
> > > > To: [e-mail]; [e-mail]
> > > > Cc: [e-mail]; [e-mail]; [e-mail]
> > > > Subject: Re: [sipcore] 4244bis and privacy
> > > > 
> > > > 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.  
> > > [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. 
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]]
> > > > Sent: Thursday, June 25, 2009 4:32 PM
> > > > To: [e-mail]
> > > > Cc: Barnes, Mary (RICH2:AR00); [e-mail];
> > > [e-mail];
> > > > [e-mail]
> > > > Subject: AW: [sipcore] 4244bis and privacy
> > > > 
> > > > 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:[e-mail]]
> > > > Gesendet: Donnerstag, 25. Juni 2009 22:32
> > > > An: Jesske, Roland
> > > > Cc: [e-mail]; [e-mail]; 
> > [e-mail]; 
> > > > [e-mail]
> > > > Betreff: 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
> > > > 
> > > > 
> > > > [e-mail] wrote:
> > > > > 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: [e-mail]
> > > [mailto:[e-mail]] Im
> > > > > Auftrag von Mary Barnes
> > > > > Gesendet: Donnerstag, 25. Juni 2009 18:29
> > > > > An: Ian Elz
> > > > > Cc: [e-mail]; Shida Schubert
> > > > > Betreff: Re: [sipcore] 4244bis and privacy
> > > > >
> > > > > Hi Ian,
> > > > >
> > > > > Responses inline below [MB2].
> > > > >
> > > > > Mary.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Ian Elz [mailto:[e-mail]]
> > > > > Sent: Thursday, June 25, 2009 10:13 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 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.
> > > > > [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
> > > > >
> > > > >
> > > > >
> > > > > -----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];user=phone;p=x
> > > > > Privacy: history
> > > > > History-Info:
> > > > > 
> > > > <sip:[e-mail];user=phone;p=x>;index=1;rt;aor  
> > > >        (1)
> > > > > History-Info: <sip:[e-mail]>;index=1.1;mp;aor
> > > > > (2)
> > > > > History-Info: <sip:bob@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] to 
> > > > > sip:[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]; 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]>;index=1.1;mp;aor
> > > > > History-Info: <sip:bob@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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > sipcore mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/sipcore
> > > > > _______________________________________________
> > > > > sipcore mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/sipcore
> > > > >   
> > > > _______________________________________________
> > > > sipcore mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/sipcore
> > > > 
> > > _______________________________________________
> > > sipcore mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sipcore
> > > 
> > 
>