Initial ProtoXEP submission.
User Geolocation (XEP-0080)
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.
This specification is designed to meet the following requirements.
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.
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.
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.
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.
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.
An entity supporting this specification MUST advertise the following feature in response to Service Discovery (XEP-0030)
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.
The Jingle application namespace is urn:xmpp:jingle:apps:geoloc:0.
| Element | Context | Meaning |
|---|---|---|
| description | Jingle content | Advertises call-scoped user location support and MAY carry an initial XEP-0080 geoloc payload. |
| location | Jingle session-info | Updates the current call-scoped location with an XEP-0080 geoloc payload. |
| location-stop | Jingle session-info | Indicates that the sender has stopped sharing call-scoped location. |
The location and location-stop elements SHOULD include the Jingle creator and name attributes when the update refers to a named location content.
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.
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.
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.
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.
A participant stops call-scoped location sharing by sending a location-stop session-info element.
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.
This specification complements XEP-0080 and does not replace it.
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.
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.
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.
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.
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.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA).
The XMPP Registrar shall include the following namespace in its registry of protocol namespaces:
The XMPP Registrar shall include the following feature in its registry of service discovery features:
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.
]]>