Hi Hannes,
You asked where I saw the complexity of the proposed solution. I see
complexity in trying to satisfy too many requirements / use cases with a
single solution. As you illustrate below, the use case for emergency service
alone is already quite complex by itself.
So, one way to simplify things would be to reduce the number of requirements
to be satisfied, by focusing on location conveyance for emergency calls only
(and then perhaps even be selective about the requirements to be included,
e.g. if the majority of regulators don't have strict privacy requirements
then don't include those, at least not in the base solution)
Regards,
Jeroen
Hannes Tschofenig wrote:
Hi Jeroen,
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?
The proposal to move emergency service related content from the SIP
Location Conveyance draft and from the PIDF-LO Profile draft to the
ECRIT Phone BCP document is a document management type of thing.
Nothing to worry about. Just to keep things together that belong
together.
A few of us also tend to quickly jump to examples about emergency
services when we talk about location-based routing or location-based
SIP applications.
I am not sure what you mean by special.
So far, it has been treated as merely a special case of
location-based routing. But the need for it (yesterday, regulatory
driven),
Please note that there are different regulatory requirements for
different parts. There are no regulatory requirement for plain VoIP
emergency services (without PSAP interworking or systems that claim
to be a replacement of the PSTN). Note, however, that I am not a
laywer and some folks on this list might know more about the state of
regulatory affairs throughout the world.
the
security/privacy aspects (ignore them),
Well. We have discussed many security aspects in the context of
emergency services. There are also privacy related aspects that need
to be considered. In fact, we recently had a separate panel
discussion at the SDO emergency services workshop to address this
topic. See http://www.emergency-services-coordination.info/2007/, the
slides for the panel sessions can be found here:
http://www.tschofenig.com/twiki/bin/view/EmergencyServices/EswPanelParticipants
It just varies from country to country. Japan, for example, has quite
challenging privacy rules even for emergency services.
the required information (single
location, no shapes e.d.) all seem vastly different from the general
case.
I don't know where you got the message that emergency services works
with simpler location shapes. In fact, it would even be necessary to
indicate what the different shapes would be used for since there are
different consumers in the entire message flow.
The SDO emergency services workshop I asked the audience about the
state-of-the-art location shape types that are being used and I got
the impression that fairly complex shapes are already in use today
(in the cellular world). I have asked NENA to solicit feedback from
the PSAP operator community to learn more about their needs with this
respect. A few responses from my own investigations revealed that
they would certainly like to have more location information
(requiring more complex shapes) for dispatch purposes.
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?
Would be great if everything would be just that simple.
Ciao
Hannes
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
