[Standards] XEP-0255 (Location Query)

kael ka-el at laposte.net
Sun Dec 14 18:40:41 UTC 2008


Helge Timenes wrote, On 11/26/2008 10:43 PM:
> Some comments to the XEP-0255 / "Location Query" draft (http://xmpp.org/extensions/xep-0255.html):
> 
> 1) Beacon signal strength seems to have been forgotten in the draft specification. This is a mistake and I will correct it. 
> 
> 2) In the development project from which XEP-0255 was born (Buddycloud), we never considered using Timing Advance (http://en.wikipedia.org/wiki/Timing_advance) for triangulation between cell towers, simply because it was too troublesome getting the deep API access required on Symbian, our main client platform.
> 
> However I assume this is something other implementers may want to use, so i think it should be covered by the XEP.
> 
> The specification currently uses a generic data type for all radio beacons (cell towers, wifi access points, bluetooth devices). However timing advance would only apply to cell towers. In order to keep this symmetry, and as timing advance translate directly to distance (scaled by a factor of 550m per unit), i am pondering whether to add the somewhat more generic field 'distance' rather than 'timing advance'. I am not sure how a client would derive distance to, say a wifi access point, but I think that is more likely than a timing advance value...
> 
> Any thoughts?

This specification looks nice. I'd have some comments and suggestions.


1. The XEP uses an <locationquery xmlns='urn:xmpp:locationquery:0'> 
element for queries, but doesn't for replies.

Shouldn't the <locationquery/> element be part of replies ?


2. The XEP allows to decide if the query result should be published by
the location server on behalf of the user with a <publish/> element. But 
I'm not sure the <publish/> element is correctly located. It is not
very elegant and perhaps that :

- the location query could contain the geoloc namespace ;

- the <publish/> element value could be part of the Pubsub 
<publish-options/> with for example a (better named) 'pubsub#on_behalf' 
attribute value :

<iq from='hamlet at shakespeare.lit/phone'>
   <locationquery xmlns='urn:xmpp:locationquery:0'>
     <geoloc xmlns='http://jabber.org/protocol/geoloc'>
       <timestamp>1599-10-23T01:55:21Z</timestamp>
       <latitude>57.0501862</latitude>
       <longitude>9.918874</longitude>
       <accuracy>33.56</accuracy>
     </geoloc>
     <publish-options>
       <x xmlns='jabber:x:data' type='submit'>
         <field var='FORM_TYPE' type='hidden'>
         <value>http://jabber.org/protocol/pubsub#publish-options</value>
         </field>
         <field var='pubsub#on_behalf'>
           <value>true</value>
         </field>
         <field var='pubsub#access_model'>
           <value>whitelist</value>
         </field>
       </x>
     </publish-options>
   </locationquery>
<iq>


3. The XEP allows to query the location server to resolve cellID, and 
WiFi, WiMax and Bluetooth SSIDs. It uses a <beacon/> element which 
doesn't look very cohesive compared to the geolocation ones.

So perhaps it would be possible to extend XEP-0080 to include two or
three new namespaces for cellID, Bluetooth, WiFi, and WiMax SSID (I
don't know the terminology for Bluetooth and WiMax) or perhaps to add 
the following new namespaces to this XEP :

<iq from='hamlet at shakespeare.lit/phone'>
   <locationquery xmlns='urn:xmpp:locationquery:0'>
     <geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
       <timestamp>1599-10-23T01:55:21Z</timestamp>
       <latitude>57.0501862</latitude>
       <longitude>9.918874</longitude>
       <accuracy>33.56</accuracy>
     </geoloc>
     <cell xmlns='urn:3gpp:cell'>
       <cgi>238:02:34775:50880</cgi>
       <signalstrength>1</signalstrength>
     </cell>
     <!-- or xmlns='http://jabber.org/protocol/cell', etc. -->
     <wifi xmlns='urn:ieee:802.11'>
       <ssid>00:19:CB:45:50:4A</ssid>
     </wifi>
     <bluetooth xmlns='urn:ieee:802.15'>
       <ssid>00:19:CB:45:50:4A</ssid>
     </bluetooth>
     <wimax xmlns='urn:ieee:802.16'>
       <ssid>00:19:CB:45:50:4A</ssid>
     </wimax>
     <publish-options>
       <x xmlns='jabber:x:data' type='submit'>
         <field var='FORM_TYPE' type='hidden'>
         <value>http://jabber.org/protocol/pubsub#publish-options</value>
         </field>
         <field var='pubsub#on_behalf'>
           <value>true</value>
         </field>
         <field var='pubsub#access_model'>
           <value>whitelist</value>
         </field>
       </x>
     </publish-options>
   </locationquery>
<iq>


It looks more cohesive with new namespaces than with the <beacon/>
element and perhaps slightly easier for parsing, although a bit more 
verbose.

But if XEP-0080 was extended, then will there be any PEP CellID with for 
example clients advertising <http://jabber.org/protocol/cell+notify> in 
their capabilities ?

I'd suggest also to add some references for the definitions of Cell 
Global Identity (CGI), SSID, etc, like the "3GPP TS 03.03 - Numbering, 
Addressing and Identification" specification 
<http://www.3gpp.org/ftp/Specs/html-info/0303.htm> which defines CGI for 
2G mobile networks in Section 4.3.1.

And in example 7 of the XEP, the from attribute should be the JID of the 
location server, I think.

-- 
kael




More information about the Standards mailing list