Re: [sipcore] Understanding Privacy: history invoked by UAS

 I think RFC4244 was quite vague about how privacy is 
requested and due to that, both privacy header outside 
H-I header or part of hi-entry are used without any clear 
distinction.

 Thus for backward compatibility, I don't think we can 
eliminate the use of Privacy:history, I think we can definitely 
clarify the use of them by saying proxy SHOULD or MUST 
use privacy=header and UAC uses Privacy:history. 

 I do think we should clarify the procedure of how history-info 
is anonymized, may be something along the line as follows.

1. Setting privacy indication.

 UAC sets privacy by setting privacy:header or privacy:history
 Proxy/UAS sets privacy by setting privacy=history in hi-entry

2. Applying privacy to request.

 Privacy service at the boundary of domain checks if privacy:header 
or privacy:history exists.

 If privacy:history or privacy:header exists then it anonymize all the 
hi-entry from its responsible domain by changing the hi-target-to-uri 
to URI with anonymous.invalid. 

 If the hi-entry that is a target of anonymization and has privacy=history, 
it will remove the privacy=history after anonymizing the hi-entry.

 If the hi-entry is already anonymized (URI with anonymous.invalid) it 
will leave the entry as is. 

 After anonymizing all the hi-entry from its responsible domain it will 
remove the priv-value of "history" from Privacy header (real header).

 If there are no priv-value remaining in the Privacy header then it will 
remove the Privacy header itself following the procedure in RFC3323.

 If there is no priv-value of "history" or "header", privacy service 
looks through hi-entries and see if there are URI from its domain 
with privacy=history.

 For each hi-entry with privacy=history, privacy service will anonymize 
the hi-target-to-uri and remove the privacy=history after anonymizing 
the hi-entry. 

3. Privacy:none

 With regards to privacy:none, it's tad tricky because 
as Ian said, how it's honored depends on the regulation etc. 

 Regards
  Shida

On Nov 10, 2010, at 10:30 AM, Elwell, John wrote:

> In which case we don't need Privacy: history in the response, since it is only a partial solution?
> 
> John 
> 
>> -----Original Message-----
>> From: Shida Schubert [mailto:shida@ntt-at.com] 
>> Sent: 09 November 2010 06:24
>> To: Elwell, John
>> Cc: sipcore@ietf.org
>> Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS
>> 
>> 
>> Hi John;
>> 
>> In practice, if C cares about its privacy, there should be 
>> a priori arrangement with the service provider or 
>> configuration in proxy to withhold its identity.
>> 
>> This will allow the proxy sending the 4xx which sets the hi-entry 
>> to ensure privacy is applied by setting escaped privacy header 
>> or Privacy:header. 
>> 
>> Regards
>>  Shida 
>> 
>> On Nov 9, 2010, at 11:32 AM, Elwell, John wrote:
>> 
>>> Suppose a request from A is targeted initially at B, this 
>> is mapped to C, and then to registered contact D. The UAS (D) 
>> puts Privacy: history in the response, and therefore prevents 
>> A learning about C and D. Fine.
>>> 
>>> Now, supposing D is not registered at the time, i.e., there 
>> is no registered contact for C. This results in a 4xx 
>> response to A. How do we ensure that the identity of C is not 
>> disclosed to A, in line with what is achieved when D is registered?
>>> 
>>> John
>>> 
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>> 
>> 