Re: [Sip-implementors] [Sip] SIPit 20 survey summary
"Jeroen van Bemmel" <jbemmel@zonnet.nl> Sun, 29 April 2007 19:49 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiFOL-0005Nf-3k; Sun, 29 Apr 2007 15:49:05 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HiFOK-0005Na-00 for sip-confirm+ok@megatron.ietf.org; Sun, 29 Apr 2007 15:49:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiFOJ-0005NS-Mj for sip@ietf.org; Sun, 29 Apr 2007 15:49:03 -0400
Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiFOI-00061A-11 for sip@ietf.org; Sun, 29 Apr 2007 15:49:03 -0400
Received: (qmail 14784 invoked by uid 0); 29 Apr 2007 19:48:57 -0000
Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender <jbemmel@zonnet.nl>) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 29 Apr 2007 19:48:57 -0000
Message-ID: <01af01c78a97$3d8723f0$0601a8c0@BEMBUSTER>
From: Jeroen van Bemmel <jbemmel@zonnet.nl>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, hgs@cs.columbia.edu
References: <20070429143911.77880@gmx.net> <4DC0BA1A-8F26-4218-B3E6-D5BB752DA832@cs.columbia.edu> <010201c78a74$16d3fee0$0601a8c0@BEMBUSTER> <20070429163343.77910@gmx.net>
Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary
Date: Sun, 29 Apr 2007 21:47:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: sip@ietf.org, sip-implementors@cs.columbia.edu, jh@tutpro.com, discussion@sipforum.org, rjsparks@estacado.net
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
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.priv.at/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 >>> Sip-implementors@cs.columbia.edu >>> 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- Re: [Sip] SIPit 20 survey summary Frank W. Miller
- [Sip] SIPit 20 survey summary Robert Sparks
- [Sip] Which sip.instance to use (GRUU and Outboun… Jerry Yin
- Re: [Sip] SIPit 20 survey summary Jeroen van Bemmel
- Re: [Sip] SIPit 20 survey summary Juha Heinanen
- RE: [Sip] SIPit 20 survey summary Brian Rosen
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Mark R. Lindsey
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Juha Heinanen
- Re: [Sip] SIPit 20 survey summary Cullen Jennings
- Re: [Sip] SIPit 20 survey summary Frank W. Miller
- Re: [Sip] SIPit 20 survey summary Cullen Jennings
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Mark R. Lindsey
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Juha Heinanen
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip] SIPit 20 survey summary Jeroen van Bemmel
- Re: [Sip] SIPit 20 survey summary Henning Schulzrinne
- Re: [Sip] SIPit 20 survey summary Juha Heinanen
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Scott Lawrence
- Re: [Sip] SIPit 20 survey summary Frank W. Miller
- Re: [Sip] SIPit 20 survey summary Juha Heinanen
- Re: [Sip] SIPit 20 survey summary Henning Schulzrinne
- Re: [Sip] SIPit 20 survey summary Henning Schulzrinne
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip] SIPit 20 survey summary Hannes Tschofenig
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Jeroen van Bemmel
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Hannes Tschofenig
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Jeroen van Bemmel
- [Sip] geoloc implementation (Was: SIPit 20 survey… Dale.Worley
- Re: [Sip] geoloc implementation (Was: SIPit 20 su… Paul Kyzivat
- [Sip] Support for Multipart/MIME Cullen Jennings
- Re: [Sip] geoloc implementation (Was: SIPit 20 su… Juha Heinanen
- RE: [Sip] geoloc implementation (Was: SIPit 20 su… Brian Rosen
- Re: [Sip] Support for Multipart/MIME Dale.Worley
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- Re: [Sip] Support for Multipart/MIME Frank W. Miller
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME James M. Polk
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME James M. Polk
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Ted Hardie
- Re: [Sip] Support for Multipart/MIME Dean Willis
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Ted Hardie
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME Dean Willis
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Ted Hardie
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Francois Audet
- Re: [Sip] Support for Multipart/MIME Cullen Jennings
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Klaus Darilion
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Hannes Tschofenig
- Re: [Sip-implementors] [Sip] SIPit 20 survey summ… Dale.Worley
- RE: [Sip] Support for Multipart/MIME Francois Audet
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Francois Audet
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Francois Audet
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Francois Audet
- RE: [Sip] Support for Multipart/MIME Elwell, John
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME - order of b… Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME - order of b… Francois Audet
- RE: [Sip] Support for Multipart/MIME - order of b… Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME - S/MIME Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME - support of… Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME - support of… Gonzalo Camarillo
- RE: [Sip] Support for Multipart/MIME - support of… Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME - support of… Paul Kyzivat
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME Dan Wing
- RE: [Sip] Support for Multipart/MIME - when is it… Christer Holmberg (JO/LMF)
- RE: [Sip] Support for Multipart/MIME - support of… Christer Holmberg (JO/LMF)
- Re: [Sip] Support for Multipart/MIME Gonzalo Camarillo
- RE: [Sip] Support for Multipart/MIME Dan Wing
- Re: [Sip] Support for Multipart/MIME Paul Kyzivat
- Re: [Sip] Support for Multipart/MIME Cullen Jennings