(As WG chair) You have already had one warning from the area director.
Now this is one from the WG chair. Get this discussion down to specific proposal to the appropriate WG. We are here to discuss chartered drafts. Make specific proposals to the chartered drafts on the table or desist. If you do not know what those are, then go and read the charters. And under no circumstances start including this list in a lot of cross postings to other groups. Regards Keith > -----Original Message----- > From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 29, 2007 4:36 PM > To: Henning Schulzrinne; Hannes Tschofenig > Cc: [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] [Sip] SIPit 20 survey summary > > 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 > _______________________________________________ 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
