0.6

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3034 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0255.xml

@@ -7,7 +7,7 @@
 <xep>
 <header>
   <title>Location Query</title>
-  <abstract>This specification defines an XMPP protocol extension for querying a compliant server for information about the geographical or physical location of an entity."</abstract>
+  <abstract>This specification defines an XMPP protocol extension for querying a compliant server or service for information about the geographical or physical location of an entity.</abstract>
   &LEGALNOTICE;
   <number>0255</number>
   <status>Experimental</status>
@@ -38,6 +38,12 @@
     <email>ross@buddycloud.com</email>
     <jid>ross@buddycloud.com</jid>
   </author>
+  <revision>
+    <version>0.6</version>
+    <date>2009-04-09</date>
+    <initials>psa</initials>
+    <remark><p>Defined registry; added nic type from list discussion.</p></remark>
+  </revision>
   <revision>
     <version>0.5</version>
     <date>2009-03-13</date>
@@ -128,7 +134,7 @@
 </header>
 
 <section1 topic='Introduction' anchor='intro'>
-  <p>This document defines a format for querying a location server for information about an entity's geographical location.  The query must contain some location characteristics that the server can process to derive this information. These can be in the form of geodetic coordinates (from GPS receivers or other positioning equipment), in which case the server will perform "reversed geocoding" to derive the information. Alternatively, the location can be characterized by a geographically assigned IP address or a list of cellular telephone towers, wireless network access points, bluetooth devices and RFID tags observable from this location (from here on called 'location references', or just 'references'). In this case the location server must match the supplied characteristics with stored knowledge about the location references to derive the submitting entity's location.  Client implementers are encouraged to supply both kinds of characteristics when available, as this can be utilized by self-learning location servers. The location information returned by the location server is structured according to &xep0080;, ensuring compatibility with systems using this standard for location information publishing.</p>
+  <p>This document defines a format for querying a location server for information about an entity's geographical location.  The query must contain some location characteristics that the server can process to derive this information. These can be in the form of geodetic coordinates (from GPS receivers or other positioning equipment), in which case the server will perform "reversed geocoding" to derive the information. Alternatively, the location can be characterized by a geographically assigned IP address or a list of cellular telephone towers, wireless network access points, Bluetooth devices, RFID tags, network addresses, or other information observable from this location (from here on called 'location references', or just 'references'). In this case the location server must match the supplied characteristics with stored knowledge about the location references to derive the submitting entity's location.  Client implementers are encouraged to supply both kinds of characteristics when available, as this can be utilized by self-learning location servers. The location information returned by the location server is structured according to &xep0080;, ensuring compatibility with systems using this standard for location information publishing.</p>
   <p>The location query is designed to be used as a one-shot request or as a continuous query-result dialogue. The latter form will allow location servers to analyze changes with time, which in most cases yields improved fidelity and the possibility to derive motion state information.</p>
 </section1>
 
@@ -147,7 +153,7 @@
 </section1>
 
 <section1 topic='How It Works' anchor='examples'>
-  <p>The basic principle behind this XMPP extension is as follows: An XMPP clients collects characteristics about its current location that is not directly suitable for presentation to a human user, but from which human readable location information can be derived. The client sends this information to a location server that derives this information and returns it to the querying client. Here "location server" means a XMPP server application that supports the <strong>locationquery</strong> stanza defined in this document. It can either be an integral part of the XMPP server, or run as a component on the same or a different machine from the XMPP server itself.</p>
+  <p>The basic principle behind this XMPP extension is as follows: An XMPP clients collects characteristics about its current location that is not directly suitable for presentation to a human user, but from which human readable location information can be derived. The client sends this information to a location server that derives this information and returns it to the querying client. Here "location server" means a XMPP server application that supports the &lt;locationquery/&gt; payload defined in this document. It can either be an integral part of the XMPP server, or run as a component on the same or a different machine from the XMPP server itself.</p>
 
   <example caption='Entity queries server with GPS coordinates'><![CDATA[
 <iq from='hamlet@shakespeare.lit/phone' 
@@ -489,21 +495,21 @@
       <tr class="body">
          <td>id</td>
          <td>xs:string</td>
-         <td>A world-wide unique reference identifier. This SHALL be composed as follows: <br/><br/>For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code <note>Values of Mobile Country Codes (MCC) are specified by <link url="http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212A-2007-PDF-E.pdf">Annex to ITU Operational Bulletin No. 897 – 1.XII.2007</link>.</note>), MNC is the network carrier code, LAC is the area code and CID is the cell ID.<br/><br/>For wireless access points and bluetooth devices: The device MAC address.<br/><br/>For IP addresses: the IP address itself (either IPv4 or IPv6).</td>
+         <td>A world-wide unique reference identifier. This SHALL be composed as follows: <br/><br/>For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code <note>Values of Mobile Country Codes (MCC) are specified by <link url="http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212A-2007-PDF-E.pdf">Annex to ITU Operational Bulletin No. 897 – 1.XII.2007</link>.</note>), MNC is the network carrier code, LAC is the area code and CID is the cell ID.<br/><br/>For wireless access points and Bluetooth devices: The device MAC address.<br/><br/>For IP addresses: the IP address itself (either IPv4 or IPv6).</td>
          <td>207:02:12643:78596</td>
          <td>Required</td>
       </tr>
       <tr class="body">
          <td>type</td>
          <td>xs:string</td>
-         <td>Reference type. One of "cell", "wifi", "bluetooth", "wimax", "rfid" "ip", "other"</td>
+         <td>Reference type as maintained in the registry specified under <link url='#registrar-reftypes'>Reference Types Registry</link></td>
          <td>"cell"</td>
          <td>Required.</td>
       </tr>
       <tr class="body">
          <td>signalstrength</td>
          <td>xs:int</td>
-         <td>Reference signal strength in dBM. Only appliccable to actively transmitting references (cell towers, wifi access points, bluetooth devices)</td>
+         <td>Reference signal strength in dBM. Only appliccable to actively transmitting references (cell towers, wifi access points, Bluetooth devices)</td>
          <td>-64</td>
          <td>Optional.</td>
       </tr>
@@ -703,7 +709,7 @@
     <p>If no GPS coordinate and accuracy information is submitted in the query, and the server determines location coordinates from submitted reference data, a value for the returned geoloc 'accuracy' field SHOULD be returned. The magnitude of this should be derived based on the ranges of the location references used to determine the location, if known. </p>
     <p>The server should make no assumptions about how often a entity submits a query. It should support occasional manually triggered queries as well as periodic automated queries. In the latter case it should analyze changes over time, as this can greatly increase the fidelity of the result. </p>
     <p>Furthermore, no assumptions should be made about the number and types of location references being logged in each query. Some handset manufacturers limit the access programmers have to cell tower and access point information. Some may only offer the currently connected cell ID, such that even if the handset can "see" many cell towers, only the one to which the handset is connected at the moment can be read. In this case the cell tower readings may not be constant, even if the querying entity is not moving. Rather it may jump round-robin style to each visible cell with variable time spent on each.  The location server should account for this to avoid yielding results indicating that a user is running around in cell-sized circles when he is in fact stationary. Again, analysis of variation of submitted queries over time is recommended.</p>
-    <p>As no guarantees can be made that a given location reference stays at one fixed physical location throughout it's lifetime, the server should implement means to detect this. Generally it can be assumed that cell towers seldom move (could happen when a network operator changes the way it allocates cell IDs or when a tower is physically moved to a different location). Wireless access points move a bit more frequently (for instance when their owners move, or if they are installed in moving vehicles such as busses or trains). Bluetooth devices can generally be assumed to be mobile and should, unless specific knowledge to the contrary exists, not be used to locate an entity to a specific physical location. Rather, bluetooth devices (and other mobile references) can be used to co-locate entities to other entities for which a physical location is known. An example: Entity A submits query with GPS coordinates and the ID of some bluetooth device. It is located based on its submitted coordinates. Entity B submits a query with the same bluetooth device ID, but no GPS coordinates. Given this, and the fact that bluetooth transmitters have a very limited range, the server can then derive that A and B are at the same physical location (it may add 10-20 m to the accuracy of the location of B to account for the bluetooth range).</p>
+    <p>As no guarantees can be made that a given location reference stays at one fixed physical location throughout it's lifetime, the server should implement means to detect this. Generally it can be assumed that cell towers seldom move (could happen when a network operator changes the way it allocates cell IDs or when a tower is physically moved to a different location). Wireless access points move a bit more frequently (for instance when their owners move, or if they are installed in moving vehicles such as busses or trains). Bluetooth devices can generally be assumed to be mobile and should, unless specific knowledge to the contrary exists, not be used to locate an entity to a specific physical location. Rather, Bluetooth devices (and other mobile references) can be used to co-locate entities to other entities for which a physical location is known. An example: Entity A submits query with GPS coordinates and the ID of some Bluetooth device. It is located based on its submitted coordinates. Entity B submits a query with the same Bluetooth device ID, but no GPS coordinates. Given this, and the fact that Bluetooth transmitters have a very limited range, the server can then derive that A and B are at the same physical location (it may add 10-20 m to the accuracy of the location of B to account for the Bluetooth range).</p>
     <p>The "radio landscape" is by no means constant. New cells and access points are added continuously, and old ones are phased out. A location server will have to adapt to this shifting landscape, either by means of operator-supplied databases (in case of cell towers) or by means of user generated information. This standard was written with the latter in mind, and it is recommended that location servers utilize any queries with both GPS coordinates and location references to "learn" the approximate physical location of the provided references. For server implementation that rely on user generated information only, it is also recommended to supply additional means for the users to feed back location context in cases where the client does not have any GPS access, or when the server produces the wrong results. One way to do this would be to let the users define "placemarks" (a name, street, city etc) that can be associated with the references seen by this user at the time of definition. This is however beyond the scope of this XEP. </p>
   </section2>
 
@@ -736,10 +742,85 @@
     </ul>
     <p>Upon advancement of this specification from a status of Experimental to a status of Draft, the &REGISTRAR; shall add the foregoing namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
   </section2>
+
   <section2 topic='Protocol Versioning' anchor='registrar-versioning'>
     &NSVER;
   </section2>
 
+  <section2 topic='Reference Types Registry' anchor='registrar-reftypes'>
+    <section3 topic='Process' anchor='registrar-reftypes-process'>
+      <p>The XMPP Registrar shall maintain a registry of values for the &lt;type/&gt; child of the &lt;status/&gt; element when qualified by the 'urn:xmpp:locationquery:0' namespace.</p>
+      &REGPROCESS;
+      <code><![CDATA[
+<reftype>
+  <name>the machine-readable name for the reference type</name>
+  <description>a natural-language description of the reference type</description>
+</reftype>
+      ]]></code>
+      <p>The registrant can register more than one reference type at a time, each contained in a separate &lt;reftype/&gt; element.</p>
+    </section3>
+    <section3 topic='Initial Submission' anchor='registrar-reftypes-init'>
+      <p>As part of this document, the following reference types are registered:</p>
+      <code><![CDATA[
+<reftype>
+  <name>bluetooth</name>
+  <description>
+    The device address as determined by Bluetooth technologies as defined in
+    the IEEE 802.15.1 standards.
+  </description>
+</reftype>
+<reftype>
+  <name>cell</name>
+  <description>
+    A cell tower address, formatted as "MCC:MNC:LAC:CID" (where MCC is 
+    the mobile country code, MNC is the network carrier code, LAC is the 
+    area code, and CID is the cell ID).
+  </description>
+</reftype>
+<reftype>
+  <name>ip</name>
+  <description>
+    An Internet Protocol (IP) address possessed by or assigned to the 
+    client.
+  </description>
+</reftype>
+<reftype>
+  <name>nic</name>
+  <description>
+    The link layer (Media Access Control) address of one of the Network 
+    Interface Controllers (NICs) associated with the client sending the 
+    request. Most commonly, this will take the form of a 48-bit Ethernet 
+    address formatted in six colon-separated groups of two hexadecimal 
+    digits, in transmission order. Some location servers might be able to 
+    use this information to query network elements through which the client 
+    is connected to deduce location data.
+  </description>
+</reftype>
+<reftype>
+  <name>rfid</name>
+  <description>
+    The device address as determined by Radio Frequency Identification
+    technologies.
+  </description>
+</reftype>
+<reftype>
+  <name>wifi</name>
+  <description>
+    The device address as determined by WiFi technologies as defined in
+    the IEEE 802.11 standards.
+  </description>
+</reftype>
+<reftype>
+  <name>wimax</name>
+  <description>
+    The device address as determined by Worldwide Inter-operability for 
+    Microwave Access technologies.
+  </description>
+</reftype>
+      ]]></code>
+    </section3>
+  </section2>
+
 </section1>
 
 <section1 topic='XML Schema' anchor='schema'>
@@ -824,4 +905,3 @@
 </section1>
 
 </xep>
-