Re: Re: [Geopriv] SIP Location Conveyance: dereferencing location-by-reference

I suspect we're talking about two different use cases:

- proxies will find subscriptions rather tedious when doing call routing 
(do a SUBSCRIBE, wait for authorization, NOTIFY just to get a location 
to route a call?), and don't get any benefit from the subscription model;

- UASs will find subscriptions helpful, in some limited circumstances 
(e.g., if I call OnStar for directions, they might want to see where I'm 
going in real time, rather than where I was five minutes ago while all 
their agents were busy assisting other customers)

I don't see particular security issues as long as the UAC realizes that 
any subscription URI that it hands out might be used by anybody that is 
on the call path. In some cases, that's an acceptable model, 
particularly if the caller identity is obscured, so that you only know 
that "random caller abc17 is at location X waiting for tow truck". (In 
that case, subscriptions are probably somewhat pointless.)

In short, I think we should allow all of these and simply make sensible 
recommendations, such as that location information meant for call 
routing should NOT just use subscriptions and also provide location 
by-value/by-attachment, simply because location subscriptions are too 
painful and useless for proxies in practice.

Henning

Andrew Newton wrote:
> James M. Polk wrote:
>> At 05:25 PM 7/18/2006 -0400, Andrew Newton wrote:
>>> What happens when a client gets a subscribable location reference URI 
>>> via the L7-LCP,
>>
>> you mean a SIP or SIPS URI?
>>
>> You expect SIP to be a dereference capable protocol?  Why?
> 
> I actually didn't mention SIP as the dereference protocol.  What I am 
> asking is which dereference protocol with a subscription mechanism are 
> you going to specify?  Or should implementers assume XMPP for this 
> feature? :)
> 
>>> and puts that into a Location header in an INVITE?
>>
>> INVITEs don't do subscriptions, SUBSCRIBEs do, so this L7 value put 
>> into a Location header that's in an INVITE wouldn't create a 
>> subscription in the first place.
> 
> Thanks for the clarification, but I was talking about the dereference 
> being orchestrated via subscription rather than polling.  I wasn't 
> really talking about the conveyance itself, other than to ask how a 
> conveyee is to know what to do with the reference.
> 
>> The above offering is to make sure dereferencing is done with 
>> HTTP/HTTPS, not SIP.
> 
> I know, which is why I asked...
> 
>>>  How is the subscription done with HTTP?
> 
> -andy
> 
> 
> _______________________________________________
> 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