Re: [Geopriv] Re: teasing apart: http as a GEOPRIV using protocol

Hi Henning,

here is the reason why I think we are not talking about a 'using 
protocol' here: All we want is to perform dereferencing.

We don't want something that does all the fancy features of a presence 
solution.

I am not even sure where the privacy rules should come from. In the 
Geopriv L7 discussion we had at least a proposal that some of us didn't 
like (namely the end host provides the privacy rules to the LIS). I 
haven't seen such a proposal here.

Here is my question (I raised it already with my scenario list): Where 
does the SIP proxy get the information to construct a PIDF-LO?

* We assume that it gets the location information somehow. Not further 
specified and might depend on the deployment environment.

* What is the "entity" attribute of the 'presence' element?

* Where does the content for the usage-rules (e.g, 
'retransmission-allowed', 'retention-expires', 'ruleset-reference', 
'note-well') come from?

Note that these questions are independent of HTTP. They also apply to SIP.

You might also recall the discussion regarding the difference between 
RELO and HELD when it comes to the threat model.

In RELO you assume that the entity that learns the reference is allowed 
to resolve it. In HELD there is the assumption that the end host 
additionally uploads the Geopriv authorization policies to control the 
access. We never came to a conclusion about the threat model that is 
applicable in the Geopriv L7 case.

I strongly believe that the questions are similar here and there are no 
answers to them. We are just exchanging one protocol (HTTP of RELO and 
HELD) with another one: SIP and route the call via this entity in the 
access network. If the SIP proxy that adds location information (by 
reference or value) is not in the access network then it cannot know the 
  location information of the end host....

Ciao
Hannes

  Henning Schulzrinne wrote:
> For all protocols, the hardest part is specifying how authentication  
> works in conjunction with the privacy rules. This is far from obvious  
> for HTTP, for example. (Is it the Digest user identifier? Can Basic  
> over TLS be used instead? What about crypto-random request URIs? Is  
> HTTP ok in that case or is HTTPS needed - the answer isn't obvious  
> since an observer would only see a location, not a location-identity  
> pair.)
> 
> For SIP, this is largely done, except for the crypto-random request  URI 
> case and variations, such as user + password.
> 
> On Jul 27, 2006, at 9:27 AM, Brian Rosen wrote:
> 
>> I think HTTP requires some specification.  A raw GET based  retrieval 
>> of a
>> PIDF would be a fairly short RFC, but I think we need that RFC.
>>
>> While I don't think it's necessary (SIP SUBSCRIBE is sufficient), I  
>> don't
>> object to defining HTTP as a using protocol in a suitable RFC.
>>
>> Brian
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 


_______________________________________________
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