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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Fri Apr 6 07:52:00 UTC 2012

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?

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.


More information about the Standards mailing list