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

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