XEP-xxxx: Jingle User Location

1. Introduction¶

User Geolocation (XEP-0080) [1] defines a payload for user location in XMPP. Jingle (XEP-0166) [2] defines Jingle session negotiation, commonly used with Jingle RTP Sessions (XEP-0167) [3] and Jingle ICE-UDP Transport Method (XEP-0176) [4] 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.

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.

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.

2. Requirements¶

This specification is designed to meet the following requirements.

1. Reuse the existing XEP-0080 User Location payload instead of defining a new coordinate format.
2. Allow an initiator or responder to advertise location sharing as a Jingle content.
3. Allow a participant to send location updates during an active Jingle session.
4. Allow a participant to explicitly stop location sharing within that session.
5. Bind location updates to the Jingle sid and content name.
6. Permit session-scoped location sharing even when PEP/XEP-0080 publishing is unavailable on the server.
7. Preserve user consent, privacy and accuracy semantics from XEP-0080.
8. Support accessibility and emergency-readiness user interfaces without claiming to be an emergency-service protocol.

3. Glossary¶

4. Use Cases¶

5. Protocol Overview¶

This specification defines the namespace urn:xmpp:jingle:apps:geoloc:0. A Jingle location content uses a description element in that namespace. The description MAY include an initial XEP-0080 geoloc payload.

After the Jingle session is active, a participant sends live or one-time location updates using Jingle session-info with a location element in this namespace. The child payload is the normal XEP-0080 geoloc element.

Stopping call-scoped location sharing is represented with a location-stop session-info element.

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.

6. Discovery¶

An entity supporting this specification MUST advertise the following feature in response to Service Discovery (XEP-0030) [5] disco#info requests:

<feature var='urn:xmpp:jingle:apps:geoloc:0'/>

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.

7. Application Format¶

The Jingle application namespace is urn:xmpp:jingle:apps:geoloc:0.

The location and location-stop elements SHOULD include the Jingle creator and name attributes when the update refers to a named location content.

8. Session Initiation¶

A client MAY include a location content in a Jingle session-initiate or MAY add it later using Jingle content-add. The content name SHOULD be location unless another unique content name is required.

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

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.

9. Location Updates¶

During an active session, a participant sends location updates using Jingle session-info. The update is scoped to the Jingle sid and the optional content name.

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

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.

10. Stopping Sharing¶

A participant stops call-scoped location sharing by sending a location-stop session-info element.

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

After sending or receiving location-stop, 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.

11. Fallback And Relationship To XEP-0080¶

This specification complements XEP-0080 and does not replace it.

• Use XEP-0080 through PEP/PubSub when the user wants normal account-level or contact-visible location publication.
• Use this specification when the user wants location to belong to a specific Jingle call.
• 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.

12. Business Rules¶

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.

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.

This specification does not define emergency call routing, legal caller identification, public-safety answering point behavior or regulatory obligations.

13. Accessibility Considerations¶

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.

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.

14. Internationalization Considerations¶

This specification reuses the XEP-0080 payload. Human-readable text inside the XEP-0080 geoloc element MAY use xml:lang as specified by XEP-0080. Coordinates are serialized using the existing XEP-0080 field formats.

15. Security Considerations¶

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.

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.

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.

16. Privacy Considerations¶

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.

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.

Clients SHOULD avoid broadcasting call-scoped location through presence, MUC history or message archives unless the user explicitly chooses a broader sharing mode.

17. IANA Considerations¶

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

18. XMPP Registrar Considerations¶

The XMPP Registrar shall include the following namespace in its registry of protocol namespaces:

• urn:xmpp:jingle:apps:geoloc:0

The XMPP Registrar shall include the following feature in its registry of service discovery features:

• urn:xmpp:jingle:apps:geoloc:0

19. Design Considerations¶

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.

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.

20. XML Schema¶

<?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>

Appendices

Appendix A: Document Information¶

Series

XEP

Number

xxxx

Publisher

XMPP Standards Foundation

Status

ProtoXEP

Type

Standards Track

Version

0.0.1

Last Updated

2026-05-31

Approving Body

XMPP Council

Dependencies

XEP-0030, XEP-0080, XEP-0166, XEP-0167, XEP-0176, XEP-0353

Supersedes

None

Superseded By

None

Short Name

jingle-geoloc

This document in other formats: XML  PDF

Appendix B: Author Information¶

Edward Tie

Email

info@tiedragon.com

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) 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.

Appendix E: Discussion Venue¶

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.0.1 (2026-05-31)¶

   Initial ProtoXEP submission.

   et

Appendix I: Bib(La)TeX Entry

@report{tie2026jingle-geoloc,
  title = {Jingle User Location},
  author = {Tie, Edward},
  type = {XEP},
  number = {xxxx},
  version = {0.0.1},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2026-05-31/2026-05-31},
}

END