Re: [Geopriv] Location-by-value in a SIP Location Header

At 04:27 PM 7/18/2006 -0400, Henning Schulzrinne wrote:
>James M. Polk wrote:
>>Henning
>>Remind us what the unique use-case is for a data URL, where neither a 
>>by-reference URI nor a by-value PIDF-LO can be used?
>
>The use case is proxy-inserted location, where the proxy does not have 
>access to a globally-accessible HTTP server where it can deposit this 
>information. This could be a proxy behind a (corporate) firewall or NAT, 
>for example.

ok, but how would a UA know it's behind a corporate NAT/FW, instead of at a 
home using the SP's LIS beyond the NAT/FW, to know to use a data URL 
instead of by-value or by-reference PIDF-LO?

>>In other words, why is this needed, and what would it be used for that 
>>every element necessary couldn't use one of the two methods of Location 
>>Conveyance already specified in the doc?
>
>See above. The incremental complexity is essentially zero.
>
>>Complexity is an issue in location conveyance - especially during 
>>emergency calling, but I've heard you state this isn't an issue with a 
>>data URL.  Are you sure?  Are others sure?
>
>I don't get your complexity point.

We're talking about all SIP elements that understand this extension now, if 
we do as you and Hannes are suggesting, include a third 
representation.  That's more code for every UA to include, and every 
location aware SIP server.

I hear your arguments below essentialling meaning location by-reference is 
a woefully underspecified user-case, and that it is the one that ought to 
be the one that may be dropped from the list within this extension proposal 
(because there is not enough there).  Are you going down that path here?

>The complexity of a data URL is likely to be significantly lower than
>
>- setting up a custom web server outside the security or NAT perimeter
>- that allows remote writes by the proxy server
>- using a proxy-to-webserver protocol that isn't standardized
>- using a webserver-to-proxy protocol (to get the object identifier back) 
>that isn't standardized, either
>- automatically cleaning up location state just at the right time (not too 
>early to avoid resolution problems and not too late to avoid exposure and 
>denial-of-service problems where the attacker uses bogus SIP INVITEs to 
>create lots of location entries)
>- and hoping that the server is always accessible, so that emergency calls 
>don't fail
>
>The data URL solution is self-contained; the reference solution is 
>basically of the "and then magic happens" kind, where the proposed 
>solution only provides a tiny part of what's needed to actually build a 
>real system.

should by-reference be taken out as an incomplete piece to an 
underspecified solution, IYO?


>Henning

_______________________________________________
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