XEP-0255: Location Query

This specification defines an XMPP protocol extension for querying a compliant server for information about the geographical or physical location of an entity."

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

Document Information

Author Information

Legal Notices

Copyright

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Discussion Venue

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

1. Introduction
2. Requirements
3. How It Works
4. Data Format
5. Recommended Transport
6. Implementation Notes
    6.1. Server Implementation Notes
    6.2. Client Implementation Notes
7. Internationalization Considerations
8. Security Considerations
9. IANA Considerations
10. XMPP Registrar Considerations
    10.1. Protocol Namespaces
    10.2. Protocol Versioning
11. XML Schema
Notes
Revision History

1. Introduction

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 list of identifiable radio transmitters (from here on called 'beacons') observable from this location. Typical beacons include cellular telephone towers, wireless network access points and bluetooth devices. In this case the location server must match the supplied characteristics with stored knowledge about the beacons 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 User Geolocation [1], ensuring compatibility with systems using this standard for location information publishing.

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.

2. Requirements

3. How It Works

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 locationquery 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.

<iq from='hamlet@shakespeare.lit/phone' 
    id='q01' 
    to='location.shakespear.lit' 
    type='get' 
    xml:lang='en-US'>
  <locationquery xmlns='urn:xmpp:locationquery:0'>
    <latitude>57.0501862</latitude>
    <longitude>9.9188746</longitude>
    <accuracy>35.6</accuracy>
  </locationquery>
<iq>

<iq from='location.shakespeare.lit' 
    id='q01' 
    to='hamlet@shakespeare.lit/phone' 
    type='result' 
    xml:lang='en-US'>
  <geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
    <timestamp>1599-10-23T01:55:21Z</timestamp>
    <lat>57.0501862</lat>
    <lon>9.9188746</lon>
    <accuracy>35.6</accuracy>
    <street>Jomfru Ane Gade 13</street>
    <locality>Aalborg</locality>
    <country>Denmark</country>
    <uri>http://shakespeare.lit/places/kings_head_pub_aalborg</uri>
    <text>Near King's Head Pub</text>
  </geoloc>
<iq>

<iq from='hamlet@shakespeare.lit/phone' 
    id='q02' 
    to='location.shakespear.lit' 
    type='get' 
    xml:lang='en-US'>
  <locationquery xmlns='urn:xmpp:locationquery:0'>
    <beacon>
      <id>238:02:34775:50880</id>
      <type>cell</type>
    </beacon>
    <beacon>
      <id>00:0F:3D:42:92:2A</id>
      <type>wifi</type>
    </beacon>
    <beacon>
      <id>00:19:CB:45:50:4A</id>
      <type>wifi</type>
    </beacon>
  </locationquery>
<iq>

<iq from='location.shakespeare.lit' 
    id='q02' 
    to='hamlet@shakespeare.lit/phone' 
    type='result' 
    xml:lang='en-US'>
  <geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
    <timestamp>1599-10-23T01:55:21Z</timestamp>
    <lat>57.050122</lat>
    <lon>9.918833</lon>
    <locality>Aalborg</locality>
    <street>Jomfru Ane Gade 13</street>
    <country>Denmark</country>
    <accuracy>20</accuracy>
    <uri>http://shakespeare.lit/places/kings_head_pub_aalborg</uri>
    <text>King's Head Pub</text>
  </geoloc>
<iq>

<iq from='hamlet@shakespeare.lit/phone' 
    id='q03' 
    to='location.shakespear.lit' 
    type='get' 
    xml:lang='en-US'>
  <locationquery xmlns='urn:xmpp:locationquery:0'>
    <timestamp>1599-10-23T01:55:21Z</timestamp>
    <lat>57.0501862</lat>
    <lon>9.918874</lon>
    <accuracy>33.56</accuracy>
    <publish>true</publish>
    <beacon>
      <id>238:02:34775:50880</id>
      <type>cell</type>
      <signalstrength>-88</signalstrength>
    </beacon>
    <beacon>
      <id>00:0F:3D:42:92:2A</id>
      <type>wifi</type>
      <signalstrength>-64</signalstrength>
    </beacon>
    <beacon>
      <id>00:19:CB:45:50:4A</id>
      <type>wifi</type>
      <signalstrength>-82</signalstrength>
    </beacon>
    <beacon>
      <id>00:18:42:E6:71:51</id>
      <type>bluetooth</type>
    </beacon>
  </locationquery>
<iq>

<iq from='location.shakespeare.lit' 
    id='q03' 
    to='hamlet@shakespeare.lit/phone' 
    type='result' 
    xml:lang='en-US' />

<iq from='hamlet@shakespeare.lit/phone' 
    id='q03' 
    to='hamlet@shakespeare.lit/phone' 
    type='set' 
    xml:lang='en-US'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish'>
      <node xmlns='http://jabber.org/protocol/geoloc'>
        <item'>
          <geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
            <timestamp>1599-10-23T01:55:21Z</timestamp>
            <lat>57.0501862</lat>
            <lon>9.918874</lon>
            <street>Jomfru Ane Gade 13</street>
            <locality>Aalborg</locality>
            <country>Denmark</country>
            <accuracy>20</accuracy>
            <uri>http://shakespeare.lit/places/kings_head_pub_aalborg</uri>
            <text>King's Head Pub</text>
          </geoloc>
        </item>
      </node>
    </publish>
  </pubsub>
<iq>

<message from='hamlet@shakespeare.lit' to='hamlet@shakespeare.lit/phone'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='http://jabber.org/protocol/geoloc'>
      <item id='4C940F61C13A0'>
        <geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
          <timestamp>1599-10-23T01:55:21Z</timestamp>
          <lat>57.0501862</lat>
          <lon>9.918874</lon>
          <street>Jomfru Ane Gade 13</street>
          <locality>Aalborg</locality>
          <country>Denmark</country>
          <accuracy>20</accuracy>
          <uri>http://shakespeare.lit/places/kings_head_pub_aalborg</uri>
          <text>King's Head Pub</text>
        </geoloc>
      </item>
    </items>
  </event>
</message>

<message from='hamlet@shakespeare.lit' to='horatio@shakespeare.lit/pda'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='http://jabber.org/protocol/geoloc'>
      <item id='4C940F61C13A0'>
        <geoloc xmlns='http://jabber.org/protocol/geoloc' xml:lang='en'>
          <timestamp>1599-10-23T01:55:21Z</timestamp>
          <lat>57.0501862</lat>
          <lon>9.918874</lon>
          <street>Jomfru Ane Gade 13</street>
          <locality>Aalborg</locality>
          <country>Denmark</country>
          <accuracy>20</accuracy>
          <uri>http://shakespeare.lit/places/kings_head_pub_aalborg</uri>
          <text>King's Head Pub</text>
        </geoloc>
      </item>
    </items>
  </event>
</message>

4. Data Format

Information about the radio beacons in the entity's surrounding, and its geodetic coordinates are provided by the entity and propagated on the network by the entity's associated application (usually a client). The information is structured by means of a <locationquery/> element that is qualified by the 'urn:xmpp:locationquery:0' namespace and nested with in a <iq> element with type set to get. The location result is provided by the location server and returned to the client in a <iq> element with type set to result. The location result is structured by means of a <geoloc/> element that is qualified by the 'http://jabber.org/protocol/geoloc' namespace (see XEP-0080).

Table 1: Location Query Child Elements

Element Name	Datatype	Definition	Example	Notes
timestamp	xs:datetime	UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of XMPP Date and Time Profiles [2].	2004-02-19T21:12Z	This is the only field that is required without exception.
publish	xs:boolean	A flag specifying whether or not the server should publish the location result to subscribers of the submitting user's XEP-0080 compatible geoloc pub-sub node instead of returning it directly to the submitting user.	true	Optional. If present and "true", the server shall publish the entity's location details whenever it changes (suitable for periodic queries) and respond to the query with an empty <iq> stanza with type set to "result". If not specified or "false" the server shall return the location results to the submitting user in the form of a geoloc stanza (XEP-0080) embedded in a <iq> with type set to "result". Default is "false"
lat	xs:decimal	Latitude in decimal degrees North.	39.75	Required if no radio beacon data present, otherwise optional. If present, this shall also be present in the result stanza. If not present, the location server SHOULD estimate a value based on submitted beacon data and return with result stanza. The location server is free to decide if the value of this field should be piped directly through to result, or if it should be modified based on beacon data or time history information. For instance: if the entity is indoors, the GPS signal will be inaccurate and unstable over time. If wifi beacons are submitted, the location server may decide that the entity is inside a known building, and return the latitude of this instead.
lon	xs:decimal	Longitude in decimal degrees East	-104.99	See notes for lat
alt	xs:decimal	Altitude in meters above or below sea level	1609	Optional. If present, this shall also be present in the result stanza with identical value.
bearing	xs:decimal	GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north		See notes for alt
datum	xs:string	GPS datum (See XEP-0080)		See notes for alt
accuracy	xs:decimal	Horizontal GPS accuracy in meters	10	See notes for lat
speed	xs:decimal	The speed at which the entity is moving, in meters per second	52.69	See notes for alt
beacons	locationquery:beacon	A list of identifiable radio transmitters observed by the entity		Required if no lat and lon values specified, otherwise optional. See Table 2 for type definition.

Table 2: Beacon Child Elements

Element Name	Datatype	Definition	Example	Notes
id	xs:string	A world-wide unique beacon identifier. This SHALL be composed as follows: For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code [3]), MNC is the network carrier code, LAC is the area code and CID is the cell ID. For wireless access points and bluetooth devices: The device MAC address.	207:02:12643:78596	Required
type	xs:string	Beacon type. One of "cell", "wifi", "bluetooth", "wimax", "rfid" (?), "other"	"cell"	Required.
signalstrength	xs:int	Beacon signal strength in dBM.	-64	Optional.

Table 3: Location Result Child Elements (Copied from XEP-0080 with notes added)

Element Name	Datatype	Definition	Example	Notes
alt	xs:decimal	Altitude in meters above or below sea level	1609	Piped directly through from query alt field if set.
area	xs:string	A named area such as a campus or neighborhood	Central Park
bearing	xs:decimal	GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north		Piped directly through from query bearing field if set.
building	xs:string	A specific building on a street or in an area	The Empire State Building
country	xs:string	The nation where the user is located	USA
datum	xs:string	GPS datum (See notes for XEP-0080)		Piped directly through from query datum field if set.
description	xs:string	A natural-language name for or description of the location	Bill's house	If location is mapped to a place in a place oriented service, this should hold the place description.
accuracy	xs:decimal	Horizontal GPS accuracy in meters	10	Piped directly through from query accuracy field or estimated by location server using based on the other information in query and, if possible, differences between several queries over time.
floor	xs:string	A particular floor in a building	102
lat	xs:decimal	Latitude in decimal degrees North	39.75	Piped directly through from query lat field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.
locality	xs:string	A locality within the administrative region, such as a town or city	New York City
lon	xs:decimal	Longitude in decimal degrees East	-104.99	Piped directly through from query lon or estimated by location server based on the other information in query and, if possible, differences between several queries over time.
postalcode	xs:string	A code used for postal delivery	10027
region	xs:string	An administrative region of the nation, such as a state or province	New York
room	xs:string	A particular room in a building	Observatory
speed	The speed at which the entity is moving, in meters per second	52.69	xs:decimal	Piped directly through from query speed field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.
street	xs:string	A thoroughfare within the locality, or a crossing of two thoroughfares	34th and Broadway
text	xs:string	A catch-all element that captures any other information about the location	Northwest corner of the lobby	Best practice tip: This field can be used by the server to combine several fields in a natural language style, suitable for simple one-line location presence text. Example: "Near Bob's place" (description + accuracy), "On the road in New York" (locality + speed)
timestamp	xs:datetime	UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of XEP-0082)	2004-02-19T21:12Z	Piped directly through from query timestamp field.
uri	A URI or URL pointing to information about the location	http://beta.plazes.com/plazes/1940:jabber_inc	xs:anyURI	Only applicable to place-oriented services

5. Recommended Transport

The location results SHOULD be distributed means of Publish-Subscribe [5] or the subset thereof specified in Personal Eventing Protocol [6]. This can be done automatically by requesting the "publish" location query result format, in which case the location server will publish the results on the user's behalf. Alternatively the it can be done client side as outlined in XEP-0080.

6. Implementation Notes

6.1 Server Implementation Notes

The does not have to determine a value for all fields of the <geoloc> stanza, but it SHOULD determine values for as many as possible. At the very least a value for 'country' should be set.

If no GPS coordinate and accuracy information is submitted in the query, and the server determines location coordinates from submitted beacon 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 beacons used to determine the location.

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.

Furthermore, no assumptions should be made about the number of beacons 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.

As no guarantees can be made that a given radio beacon 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 beacons) 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).

The "radio landscape" is by no means constant. New beacons 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 combined GPS and radio beacon information to "learn" the approximate physical location of the provided beacons. 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 beacons seen by this user at the time of definition. This is however beyond the scope of this XEP.

6.2 Client Implementation Notes

For the reasons mentioned above, it is recommended that the client supply both GPS coordinates as well as nearby radio beacon information when possible. Also it is recommended that the client submit queries frequently enough to allow the server to analyze changes over time (or lack thereof) to obtain a better result. When possible, the client should include wifi access points in the queries, as these yield much more precise results than cell towers alone (due to the much more limited range). This must however all be weighted against the increased power consumption resulting from keeping network sockets open, scanning for access points and driving a GPS receiver.

For optimal results, clients SHOULD post a location query any time when the set of observed beacons change (a new beacon is seen or an old one is not seen any more)

7. Internationalization Considerations

Because the character data contained in the location results is intended to be readable by humans, the location query SHOULD possess an 'xml:lang' attribute specifying the natural language of such character data RFC 4646 [7]. If so, the server SHOULD equip the <geoloc/> element, of the result stanza with an identical attribute

8. Security Considerations

It is imperative to control access to location information, at least by default. Imagine that a stalker got unauthorized access to this information, with enough accuracy and timeliness to be able to find the target person. This scenario could lead to loss of life, so please take access control checks seriously. If an error is deliberately added to a location, the error SHOULD be the same for all receivers, to minimize the likelihood of triangulation. In the case of deliberate error, the <accuracy/> element SHOULD NOT be included.

9. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [7].

10. XMPP Registrar Considerations

10.1 Protocol Namespaces

This specification defines the following XML namespace:

urn:xmpp:jingle:transfer:0

Upon advancement of this specification from a status of Experimental to a status of Draft, the XMPP Registrar [8] shall add the foregoing namespaces to the registry located at <http://xmpp.org/registrar/namespaces.html>, as described in Section 4 of XMPP Registrar Function [9].

10.2 Protocol Versioning

If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

11. XML Schema

<xs:schema 
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:locationquery:0' 
    xmlns='urn:xmpp:locationquery:0'
    elementFormDefault='qualified'>

  <xs:element name='locationquery'>
    <xs:complexType>
      <xs:sequence minOccurs='1' maxOccurs='1'>
        <xs:element name='timestamp' 
                    minOccurs='1' 
                    maxOccurs='1' 
                    type='xs:datetime'/>
        <xs:element name='publish'   
                    minOccurs='0' 
                    maxOccurs='1' 
                    type='xs:bolean'/>
        <xs:element name='lat'       
                    minOccurs='0' 
                    maxOccurs='1' 
                    type='xs:decimal'/>
        <xs:element name='lon'       
                    minOccurs='0' 
                    maxOccurs='1' 
                    type='xs:decimal'/>
        <xs:element name='alt'       
                    minOccurs='0' 
                    maxOccurs='1' 
                    type='xs:decimal'/>
        <xs:element name='bearing'   
                    minOccurs='0' 
                    maxOccurs='1' 
                    type='xs:decimal'/>
        <xs:element name='speed'     
                    minOccurs='0' 
                    maxOccurs='1' 
                    type='xs:decimal'/>
        <xs:element name='datum'     
                    minOccurs='0' 
                    maxOccurs='1' 
                    type='xs:string'/>
        <xs:element name='accuracy'     
                    minOccurs='0' 
                    maxOccurs='1' 
                    type='xs:decimal'/>
        <xs:element name='beacons'   
                    minOccurs='0' 
                    maxOccurs='unbounded'>
          <xs:complexType>
    	    <xs:sequence minOccurs='1' maxOccurs='1'>
              <xs:element name='id'   
                          minOccurs='1' 
                          maxOccurs='1' 
                          type='xs:string'/>
              <xs:element name='type' 
                          minOccurs='1' 
                          maxOccurs='1' 
                          type='xs:string'/>
              <xs:element name='signalstrength' 
                          minOccurs='0' 
                          maxOccurs='1' 
                          type='xs:int'/>
            </xs:sequence>
    	  </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>

Notes

1. XEP-0080: User Geolocation <http://xmpp.org/extensions/xep-0080.html>.

2. XEP-0082: XMPP Date and Time Profiles <http://xmpp.org/extensions/xep-0082.html>.

3. Values of Mobile Country Codes (MCC) are specified by Annex to ITU Operational Bulletin No. 897 – 1.XII.2007.

4. XML Schema Part 2: Datatypes <http://www.w3.org/TR/xmlschema-2/>.

5. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

6. XEP-0163: Personal Eventing Protocol <http://xmpp.org/extensions/xep-0163.html>.

7. RFC 4646: Tags for Identifying Languages <http://tools.ietf.org/html/rfc4646>.

8. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

9. XEP-0053: XMPP Registrar Function <http://xmpp.org/extensions/xep-0053.html>.