Skip to content

ProtoXEP for Jingle user location #1542

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
iNPUTmice merged 1 commit into from
Jun 2, 2026
Merged

ProtoXEP for Jingle user location #1542

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
318 changes: 318 additions & 0 deletions inbox/jingle-geoloc.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,318 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jingle User Location</title>
<abstract>This specification defines a Jingle application extension for negotiating and updating user location inside an active Jingle session using the XEP-0080 User Location payload.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XEP-0030</spec>
<spec>XEP-0080</spec>
<spec>XEP-0166</spec>
<spec>XEP-0167</spec>
<spec>XEP-0176</spec>
<spec>XEP-0353</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>jingle-geoloc</shortname>
<tags>
<tag>jingle</tag>
<tag>location</tag>
<tag>geolocation</tag>
<tag>accessibility</tag>
<tag>emergency</tag>
</tags>
<author>
<firstname>Edward</firstname>
<surname>Tie</surname>
<email>info@tiedragon.com</email>
</author>
<revision>
<version>0.0.1</version>
<date>2026-05-31</date>
<initials>et</initials>
<remark><p>Initial ProtoXEP submission.</p></remark>
</revision>
</header>

<section1 topic='Introduction' anchor='intro'>
<p>&xep0080; defines a payload for user location in XMPP. &xep0166; defines Jingle session negotiation, commonly used with &xep0167; and &xep0176; for audio and video calls. However, when location is shared during a call, using only an out-of-session PEP event can make the user experience appear call-scoped while the protocol state is not actually bound to that Jingle session.</p>
<p>This specification defines a Jingle application extension for carrying XEP-0080 location information inside the same Jingle session as audio, video or other real-time media. This allows a client to express that a location update belongs to a specific call, and to stop sharing that call-scoped location when the call or sharing action ends.</p>
<p>The motivating use cases include accessibility assistance, captioned or interpreted calls, emergency-readiness experiments and Total Conversation systems where text, audio, video and location may need to be shown as one deliberate conversational context.</p>
</section1>

<section1 topic='Requirements' anchor='reqs'>
<p>This specification is designed to meet the following requirements.</p>
<ol>
<li>Reuse the existing XEP-0080 User Location payload instead of defining a new coordinate format.</li>
<li>Allow an initiator or responder to advertise location sharing as a Jingle content.</li>
<li>Allow a participant to send location updates during an active Jingle session.</li>
<li>Allow a participant to explicitly stop location sharing within that session.</li>
<li>Bind location updates to the Jingle <tt>sid</tt> and content name.</li>
<li>Permit session-scoped location sharing even when PEP/XEP-0080 publishing is unavailable on the server.</li>
<li>Preserve user consent, privacy and accuracy semantics from XEP-0080.</li>
<li>Support accessibility and emergency-readiness user interfaces without claiming to be an emergency-service protocol.</li>
</ol>
</section1>

<section1 topic='Glossary' anchor='glossary'>
<dl>
<di>
<dt>Call-scoped location</dt>
<dd>A location update that is explicitly associated with one Jingle session.</dd>
</di>
<di>
<dt>Location content</dt>
<dd>A named Jingle content whose description uses the namespace defined by this specification.</dd>
</di>
<di>
<dt>Live location</dt>
<dd>A sequence of user-consented location updates during an active session.</dd>
</di>
</dl>
</section1>

<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Location in an accessibility call' anchor='uc-accessibility'>
<p>A user starts a video call with an accessibility assistant or relay service. The user explicitly chooses to share the current location with the call. The location is negotiated as part of the Jingle session and later updated with session-info.</p>
</section2>
<section2 topic='Location update during a Total Conversation session' anchor='uc-total-conversation'>
<p>A Total Conversation session contains audio, video and real-time text. During the session, the user shares a location update so the remote party can understand where the user is, without treating the location as a global presence update for all contacts.</p>
</section2>
<section2 topic='Server without PEP support' anchor='uc-no-pep'>
<p>A server supports ordinary Jingle IQ routing but does not support PEP or XEP-0080 publication. The client can still exchange call-scoped location with the peer using this extension, provided the peer supports it and the user consents.</p>
</section2>
<section2 topic='Stopping location sharing' anchor='uc-stop'>
<p>A user shares live location during a call and then presses a stop-sharing control. The client sends a Jingle session-info marker that tells the peer that this call-scoped sharing has stopped.</p>
</section2>
</section1>

<section1 topic='Protocol Overview' anchor='overview'>
<p>This specification defines the namespace <tt>urn:xmpp:jingle:apps:geoloc:0</tt>. A Jingle location content uses a <tt>description</tt> element in that namespace. The description MAY include an initial XEP-0080 <tt>geoloc</tt> payload.</p>
<p>After the Jingle session is active, a participant sends live or one-time location updates using Jingle <tt>session-info</tt> with a <tt>location</tt> element in this namespace. The child payload is the normal XEP-0080 <tt>geoloc</tt> element.</p>
<p>Stopping call-scoped location sharing is represented with a <tt>location-stop</tt> session-info element.</p>
<p>All location data remains subject to the semantics and validation rules of XEP-0080. This specification only defines how that payload is scoped to a Jingle session.</p>
</section1>

<section1 topic='Discovery' anchor='disco'>
<p>An entity supporting this specification MUST advertise the following feature in response to &xep0030; disco#info requests:</p>
<example caption='Discovery feature'><![CDATA[
<feature var='urn:xmpp:jingle:apps:geoloc:0'/>
]]></example>
<p>An entity SHOULD also advertise support for XEP-0080 if it supports normal PEP or PubSub location publication. Support for this specification does not imply that the entity can publish location through PEP.</p>
</section1>

<section1 topic='Application Format' anchor='format'>
<p>The Jingle application namespace is <tt>urn:xmpp:jingle:apps:geoloc:0</tt>.</p>
<table caption='Elements defined by this specification'>
<tr>
<th>Element</th>
<th>Context</th>
<th>Meaning</th>
</tr>
<tr>
<td><tt>description</tt></td>
<td>Jingle content</td>
<td>Advertises call-scoped user location support and MAY carry an initial XEP-0080 geoloc payload.</td>
</tr>
<tr>
<td><tt>location</tt></td>
<td>Jingle session-info</td>
<td>Updates the current call-scoped location with an XEP-0080 geoloc payload.</td>
</tr>
<tr>
<td><tt>location-stop</tt></td>
<td>Jingle session-info</td>
<td>Indicates that the sender has stopped sharing call-scoped location.</td>
</tr>
</table>
<p>The <tt>location</tt> and <tt>location-stop</tt> elements SHOULD include the Jingle <tt>creator</tt> and <tt>name</tt> attributes when the update refers to a named location content.</p>
</section1>

<section1 topic='Session Initiation' anchor='initiation'>
<p>A client MAY include a location content in a Jingle <tt>session-initiate</tt> or MAY add it later using Jingle <tt>content-add</tt>. The content name SHOULD be <tt>location</tt> unless another unique content name is required.</p>
<example caption='Session initiation with location content'><![CDATA[
<iq from='romeo@example.org/phone'
to='juliet@example.org/tablet'
id='loc1'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-initiate'
initiator='romeo@example.org/phone'
sid='call-123'>
<content creator='initiator' name='audio' senders='both'>
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
<payload-type id='111' name='opus' clockrate='48000' channels='2'/>
</description>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'/>
</content>
<content creator='initiator' name='location' senders='both'>
<description xmlns='urn:xmpp:jingle:apps:geoloc:0'>
<geoloc xmlns='http://jabber.org/protocol/geoloc'>
<lat>52.0907</lat>
<lon>5.1214</lon>
<accuracy>8</accuracy>
<timestamp>2026-05-31T09:15:00Z</timestamp>
<text>Utrecht</text>
</geoloc>
</description>
</content>
</jingle>
</iq>
]]></example>
<p>If a client wants to offer call-scoped location but does not yet have permission or a fresh location, it MAY send an empty location description and send the first location with session-info after the user grants consent.</p>
</section1>

<section1 topic='Location Updates' anchor='updates'>
<p>During an active session, a participant sends location updates using Jingle <tt>session-info</tt>. The update is scoped to the Jingle <tt>sid</tt> and the optional content name.</p>
<example caption='Location update'><![CDATA[
<iq from='romeo@example.org/phone'
to='juliet@example.org/tablet'
id='loc2'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-info'
sid='call-123'
initiator='romeo@example.org/phone'
responder='juliet@example.org/tablet'>
<location xmlns='urn:xmpp:jingle:apps:geoloc:0'
creator='initiator'
name='location'>
<geoloc xmlns='http://jabber.org/protocol/geoloc'>
<lat>52.0910</lat>
<lon>5.1219</lon>
<accuracy>6</accuracy>
<timestamp>2026-05-31T09:16:00Z</timestamp>
</geoloc>
</location>
</jingle>
</iq>
]]></example>
<p>A receiving client MUST validate the XEP-0080 payload before presenting or storing the update. A receiving client SHOULD show timestamp and accuracy when coordinates are displayed.</p>
</section1>

<section1 topic='Stopping Sharing' anchor='stop'>
<p>A participant stops call-scoped location sharing by sending a <tt>location-stop</tt> session-info element.</p>
<example caption='Stop sharing'><![CDATA[
<iq from='romeo@example.org/phone'
to='juliet@example.org/tablet'
id='loc3'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-info'
sid='call-123'>
<location-stop xmlns='urn:xmpp:jingle:apps:geoloc:0'
creator='initiator'
name='location'/>
</jingle>
</iq>
]]></example>
<p>After sending or receiving <tt>location-stop</tt>, a client MUST NOT continue presenting the previous call-scoped location as live. It MAY keep a historical call transcript entry if local policy and user settings permit that retention.</p>
</section1>

<section1 topic='Fallback And Relationship To XEP-0080' anchor='fallback'>
<p>This specification complements XEP-0080 and does not replace it.</p>
<ul>
<li>Use XEP-0080 through PEP/PubSub when the user wants normal account-level or contact-visible location publication.</li>
<li>Use this specification when the user wants location to belong to a specific Jingle call.</li>
<li>If a peer does not support this specification, a client MAY offer normal XEP-0080 sharing, but MUST NOT present that fallback as call-scoped location unless the user interface makes the difference clear.</li>
</ul>
</section1>

<section1 topic='Business Rules' anchor='rules'>
<p>A client implementing this specification MUST NOT send location automatically merely because a call has started. A client MUST obtain a user action or policy grant before sending location.</p>
<p>A client SHOULD provide separate controls for share once, share live and stop sharing. A client SHOULD also distinguish automatic GPS location from manual or stale location.</p>
<p>This specification does not define emergency call routing, legal caller identification, public-safety answering point behavior or regulatory obligations.</p>
</section1>

<section1 topic='Accessibility Considerations' anchor='access'>
<p>Call-scoped location can help users who rely on real-time text, captions, relay services, sign-language video or other assistive communication. User interfaces SHOULD make location sharing state visible without relying only on color, and SHOULD expose location sharing controls to keyboard, screen-reader and switch users.</p>
<p>When used with accessibility or emergency-readiness features, location SHOULD be shown with accuracy, timestamp and source so that both parties can understand how reliable the information is.</p>
</section1>

<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>This specification reuses the XEP-0080 payload. Human-readable text inside the XEP-0080 <tt>geoloc</tt> element MAY use <tt>xml:lang</tt> as specified by XEP-0080. Coordinates are serialized using the existing XEP-0080 field formats.</p>
</section1>

<section1 topic='Security Considerations' anchor='security'>
<p>Location is sensitive. A client MUST treat call-scoped location as sensitive user data and MUST NOT send it without consent or an explicit configured policy.</p>
<p>Jingle signaling can be protected by TLS between client and server, but ordinary XMPP stanza routing is not necessarily end-to-end encrypted. Clients that require end-to-end confidentiality need an encryption design outside the scope of this specification.</p>
<p>A malicious or compromised peer can lie about its own location. Clients MUST NOT treat received location as verified unless additional trust, identity and verification mechanisms are in place.</p>
</section1>

<section1 topic='Privacy Considerations' anchor='privacy'>
<p>Clients SHOULD minimize retention of call-scoped location. If location is stored in a call history or transcript, that retention MUST be visible to the user and controlled by user or deployment policy.</p>
<p>Clients SHOULD stop sending location when the call ends, when the user presses stop sharing, when the application loses the necessary permission, or when the location source becomes stale.</p>
<p>Clients SHOULD avoid broadcasting call-scoped location through presence, MUC history or message archives unless the user explicitly chooses a broader sharing mode.</p>
</section1>

<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with the Internet Assigned Numbers Authority (IANA).</p>
</section1>

<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>The XMPP Registrar shall include the following namespace in its registry of protocol namespaces:</p>
<ul>
<li><tt>urn:xmpp:jingle:apps:geoloc:0</tt></li>
</ul>
<p>The XMPP Registrar shall include the following feature in its registry of service discovery features:</p>
<ul>
<li><tt>urn:xmpp:jingle:apps:geoloc:0</tt></li>
</ul>
</section1>

<section1 topic='Design Considerations' anchor='design'>
<p>One alternative is to use only XEP-0080 PEP publication. That approach is appropriate for normal user location publication, but it does not bind the update to a particular Jingle session and can fail on servers without PEP support.</p>
<p>Another alternative is to define new latitude and longitude attributes inside Jingle. That would duplicate XEP-0080, lose existing fields such as accuracy and timestamp, and create unnecessary conversion work. This specification therefore reuses the complete XEP-0080 payload.</p>
</section1>

<section1 topic='XML Schema' anchor='schema'>
<code caption='XML Schema'><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:jingle:apps:geoloc:0'
xmlns='urn:xmpp:jingle:apps:geoloc:0'
xmlns:geoloc='http://jabber.org/protocol/geoloc'
elementFormDefault='qualified'>

<xs:import namespace='http://jabber.org/protocol/geoloc'/>

<xs:element name='description'>
<xs:complexType>
<xs:sequence minOccurs='0' maxOccurs='1'>
<xs:element ref='geoloc:geoloc'/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name='location'>
<xs:complexType>
<xs:sequence>
<xs:element ref='geoloc:geoloc'/>
</xs:sequence>
<xs:attribute name='creator' type='xs:string' use='optional'/>
<xs:attribute name='name' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>

<xs:element name='location-stop'>
<xs:complexType>
<xs:attribute name='creator' type='xs:string' use='optional'/>
<xs:attribute name='name' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code>
</section1>
</xep>
Loading