An extension of XEP-0080 or a new, enhanced super-set XEP is very necessary. Regulators are slowly recognising that they must provide Emergency Service access using the forms of communication that many people use on a daily basis. XMPP is a classic case.
Joe, Emergency Services people NEED public specifications of protocols before they will specify their use in their Requirements. Casual enhancements will not 'fly' with them. Cheers, /Barry Barry Dingle Fixed - +61(0)3-9725-3937 Mob - +61(0)41-911-7578 Fellow of University of Melbourne, Electrical and Electronic Eng., Australia > Apple + Linux + Open Source software On Tue, Apr 3, 2012 at 8:29 AM, Joe Hildebrand <[email protected]> wrote: > Just use PIDF-LO in the same way as XEP-80. You don't *have* to write a > XEP > if you don't want to. > > If you want there to be a XEP, write a XEP; the bar to entry for that is > really low. > > > On 4/2/12 11:55 PM, "Corey Wysong" <[email protected]> wrote: > > > Hello, > > > > I am very interested in this discussion. I would also like to see > XEP-0080 > > be extended or a new "Advanced GEOLocation" XEP be written. It is very > > important that location is correct when using a 911 application on any > > device using XMPP. > > > > Thanks, > > > > Corey Wysong > > > > On Mon, Apr 2, 2012 at 5:40 PM, Mark Rejhon <[email protected]> wrote: > > > >> Hello, > >> > >> I think we need to make an extension to XEP-0080 to be sufficiently > >> complete enough for use with Emergency Service (9-1-1), which often > require > >> handling of non-circular-shaped estimated location data. (So this is > more > >> advanced than the "circle estimate" you see on map apps on > >> smartphones). > >> > >> According to this IETF draft > >> Emergency Services Functionality with the Extensible Messaging > >> and Presence Protocol (XMPP) > >> http://tools.ietf.org/html/draft-tschofenig-ecrit-xmpp-es-00 > >> -------- > >> Location Conveyance: > >> > >> The ability to convey a PIDF-LO and a location by reference in > >> SIP had been defined by [RFC6442]. For a single call there may be more > >> than one location object in a call. > >> > >> While there is a location extensions available in XMPP with XEP-0080 > it > >> is not equivalent to the functionality listed above. XEP-0080 offers a > >> different civic location format and geodetic location based on a reduced > >> set of loation shapes. It uses an XML encoding and allows this > information > >> to be conveyed in XMPP. *A table with a mapping to the PIDF-LO semantic > >> is provided in XEP-0080 but unfortunately since the functionality is not > >> equivalent to the list presented above there will be a loss of > >> informationduring the lifecyle of location handling in most of the > scenarios. > >> * > >> -------- > >> > >> Notice the phrase "a loss of information" -- unacceptable in the name of > >> public safety (i.e. lost in the forest or lost at sea) > >> > >> And it will be getting much more complex, with i3 having much more > complex > >> geolocation requirements. My contacts are starting to ask me about an > XMPP > >> specification they can use. Because of the migration to Next Generation > >> 9-1-1 and Texting-to-9-1-1 (some of which is already being trialled over > >> XMPP), there is potentially a lot of companies that are going to demand > >> this in the next few years, including one that I work with. (Note, > some > >> of it is done over SIP, but other trials go over XMPP as shown in the > >> diagrams in the IETF draft. > >> > >> It would thus, be pertinent to extend XEP-0080 in the name of public > >> safety. > >> Alternatively, if this is overkill and makes XEP-0080 too complex, then > a > >> separate "XEP-0XXX: Advanced Geolocation" should be made, which could > be a > >> superset of XEP-0080 general purpose geolocation. > >> > >> This is actual demand for an actual need. > >> > >> Sincerely, > >> Mark Rejhon > >> > > -- > Joe Hildebrand > >
