Re: RE: [Geopriv] Consensus on changes to location-conveyance

I think these are reasonable guidelines unless we're suddenly very  
selective about when privacy applies (or limit l-by-r to emergency  
calling in certain no-consent-required jurisdictions).

Specifying the precise 'limited amount of time' is probably something  
that local regulations need to address.

On Jul 25, 2006, at 8:17 PM, Andrew Newton wrote:

>
> On Jul 25, 2006, at 7:21 PM, Jeroen van Bemmel wrote:
>> For location-by-reference, you'd probably want some additional  
>> requirements:
>> - URL must be valid for a limited amount of time
>> - URL must be cryptographically hard to guess
>> - URL must not contain any information that identifies the user /  
>> device / AoR
>> - for whatever transport protocol is used: response must be marked  
>> as 'no cache'
>> - user must be able to remove the information at the URL, ie  
>> explicit invalidation
>> - user must be able to verify correctness of the issued  
>> information (ie user can access the URL himself)
>> - user must be able to control who accesses the URL, both upfront  
>> and history of accesses (for a reasonable period)
>> - there must be explicit consent before a proxy would insert user  
>> location
>
>
>
> Just thinking out loud here, but maybe the rule should be that  
> proxies never append a Location header except for emergencies.

I think that's desirable unless there's a clear indication by the  
caller to do otherwise, by some consent mechanism. However, by the  
time you implement the consent mechanism, you've probably already  
implemented the better UAC-based mechanism, so it seems hard to argue  
for that complexity. The only technical argument I've heard for proxy  
insertion is legacy equipment, where requiring adding consent flags  
is clearly a non-starter.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip