[Standards] We need to extend XEP-0080. (XMPP and Next Generation 9-1-1 / i3 / geolocation)

Peter Saint-Andre stpeter at stpeter.im
Wed Apr 11 01:00:36 UTC 2012

Hash: SHA1

On 4/6/12 1:52 AM, Gunnar Hellström wrote:
> Joe Hildebrand skrev 2012-04-03 09:30:
>> On 4/3/12 4:49 AM, "Gunnar
>> Hellström"<gunnar.hellstrom at omnitor.se> wrote:
>>> I see a small possibility in XEP-0080. The last element is an
>>> URI. That could be used as a pointer to a location by reference
>>> in the RFC 4119 format.
>>> It seems that RFC 6442 prefers location by reference for the
>>> SIP case, so that may be the case for XMPP as well.
>> I like this idea.  Whether you used the URI element of XEP-80,
>> or created a new XEP for a protocol that only had this URI,
>> moving the access control and privacy outside XMPP will make this
>> easier to specify.
> Good, then I suggest to use that URI element is proposed to be able
> to be used similarly as the locationURI parameter of the
> Geolocation header specified for SIP in RFC 6442, section 4.1.
> A first assumption could be that it will be sufficient with a new 
> version of XEP-0080, that just adds this detail of usage of the
> URI element.
> Before it is decided to do it as such a simple change, without
> real change of format, a check should be done if all other
> required conditions around its usage will be satisfied, compared to
> the usage of the locationURI parameter of RFC 6442.
> At a brief glance, I notice:
> 1. RFC 6442 points to a set of specifications that need to be
> studied for getting the intended usage. It is e.g. RFC 4119, RFC
> 5491, RFC 5985, GML 3.1.1.
> 2. RFC 6442 allows any number of locationURI parameters, 
> comma-separated. XEP-0080 has just one element for one URI. Is that
> a problem for any real case?
> 3. RFC 6442 specifies a response on location conveyance for SIP,
> that can be used for indication of errors. It needs to be checked
> if a corresponding function is needed in XMPP, and how it is
> achieved.
> 4. Both RFC 6442 and XEP-0080 have ways to indicate end of
> conveyance of location information. It should be checked if they
> map sufficiently to each other.
> 5. There is a risk that a message is sent with a URI pointing to 
> something else and not intended to be used according to RFC 6442 
> locationURI, because URI is an existing element of XEP-0080, and 
> existing applications may use the element in another way. Does
> this cause any risks or conflicts?

Yes, there is existing usage. For example, in XEP-0080 you will see an
example of <uri>http://www.esbnyc.com/</uri> for the Empire State
Building. I don't know how widely this kind of thing is used, but
currently the <uri/> element is not limited to the special kind of
location-uri from RFC 6442.

> If all these checks come out positive, then it may be possible to
> just add to the usage description of the URI element in XEP-0080,
> otherwise either a new element is needed, or a new XEP.

If we really decide to go down this path, I would recommend only a new


- -- 
Peter Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Standards mailing list