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

Out of curiosity, will anything "break" if the anonymized H-I entries are simply removed?  I'm not suggesting we document doing that in the draft, just asking if any apps/use-cases/whatever will break if it happens.  Because my guess is some of us will just remove them, and I'd like to know if there's any real reason I shouldn't.

-hadriel

On Nov 9, 2010, at 10:50 PM, Shida Schubert wrote:

> 
> 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
>>> 
>>> 
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore