Re: [sipcore] 4244bis and privacy

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

 

> -----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
>