Based on all these discussions (including the proposal to remove emergency
related text from the draft), I can't help but wonder: is the use case for
"location conveyance for emergency calls" important and special enough to
warrant its own solution?
So far, it has been treated as merely a special case of location-based
routing. But the need for it (yesterday, regulatory driven), the
security/privacy aspects (ignore them), the required information (single
location, no shapes e.d.) all seem vastly different from the general case.
Link that to the observation that a header-based mechanism would be much
easier to generate (both by UEs and gateways) and parse at routing proxies
and PSAPs, reducing the chance at errors in situations that may cost lives
AND speeding up implementation rates, I'd say : separate it out?
Regards,
Jeroen
Henning Schulzrinne wrote:
I mis-spoke. I was actually thinking of a different solution, more
appropriate to the SIP header model. After all, for geo, two numbers
(long/lat) in WGS84 datum are all that matters in most circumstances,
on occasion augmented by a third (some 'measurement accuracy'
indication).
The XMPP XML model that Juha and you refer to isn't all that much
simpler than GEOPRIV civic or GML Point, just different, as you note.
(Whether supporting the multitude of geometric shapes in the pdif-lo
profile spec is truly required and where is another discussion which
belongs elsewhere.)
I don't know if by 'security' you refer to the embedded privacy
policies; in most cases, restrictive default values would do the
trick for those. Plus, for emergency calls, few PSAPs are going to
observe 'do not distribute' or 'do not retain' in any event, simply
because the law in many jurisdictions contradicts those desires.
Henning
On Apr 29, 2007, at 10:39 AM, Hannes Tschofenig wrote:
Hi Henning,
http://www.xmpp.org/extensions/xep-0080.html takes an interesting
approach by largely ignoring previous work on geolocation. It is
just too attractive to create your own flavor of civic and geodetic
location information format.
Interestingly enough there is a full-blown solution for XMPP
available as well that builds on the OMA protocols. I have to
search for the reference, if someone cares. That one is far more
complex than GEOPRIV.
If you argue for simplicity then you refer to http://www.xmpp.org/
extensions/xep-0080.html.
If you argue for functionality, different environments and
interworking with existing systems then you point to the OMA
extension.
It's so easy. Translated to our work in GEOPRIV this would mean the
following: If we want to convince people to use it then we just
point them to the easy WLAN or enterprise case with a simple civic
or a simple point representation.
Ciao
Hannes
PS: Last November I was at a conference on mobility protocols.
Someone gave a presentation on a new mobility protocol design. The
author claimed it was very simple. Indeed, it was simple -- because
it just didn't care about security.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
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
