Re: [sipcore] 4244bis and privacy

["Francois Audet" <[e-mail]>]

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.

> -----Original Message-----
> From: Elwell, John [mailto:[e-mail]] 
> Sent: Tuesday, June 30, 2009 00:30
> To: Audet, Francois (SC100:3055); Ian Elz; Barnes, Mary 
> (RICH2:AR00); [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [sipcore] 4244bis and privacy
> 
> 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
> > > > 
> > > 
> > 
>