Clarify Jingle geoloc call binding

Author: edwtie

inbox/jingle-geoloc.xml

@@ -37,6 +37,12 @@
       <surname>Tie</surname>
       <email>info@tiedragon.com</email>
     </author>
+    <revision>
+      <version>0.0.2</version>
+      <date>2026-07-01</date>
+      <initials>et</initials>
+      <remark><p>Clarify that this proposal is a call-scoped Jingle binding for XEP-0080, not a replacement for XEP-0080 or an emergency-service protocol.</p></remark>
+    </revision>
     <revision>
       <version>0.0.1</version>
       <date>2026-05-31</date>
@@ -47,8 +53,25 @@
 
   <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>&xep0080; is therefore necessary but not sufficient for this use case. It answers "what is the user's location?", but it does not by itself answer "which active call is this location for?". PEP and PubSub publication are useful for account-level or contact-visible location sharing, but they do not explicitly bind a location update to a Jingle <tt>sid</tt>, a content name, active call participants, a call-specific consent action, or call end/stop-sharing semantics.</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>
+    <p>SIP emergency calling has a similar layering distinction. PIDF-LO describes a location object, while SIP location conveyance describes how location is conveyed in SIP session signaling. This proposal follows the same architectural idea for XMPP/Jingle: reuse the existing location payload, but define how it is scoped to an active call. It does not define emergency routing, PSAP behavior or national 112/911 compliance.</p>
+  </section1>
+
+  <section1 topic='Why XEP-0080/PEP Alone Is Not Enough' anchor='why-not-pep-only'>
+    <p>XEP-0080 over PEP/PubSub remains the right tool for general user-location publication. It is not enough for call-scoped location because a receiving client or gateway cannot safely infer call intent from the latest published location item.</p>
+    <p>For an active accessibility, relay or emergency-readiness call, the protocol needs to distinguish the following cases:</p>
+    <ol>
+      <li>a general presence/profile location from a location deliberately shared into one call;</li>
+      <li>a fresh call location from a stale PEP item;</li>
+      <li>a location meant for one Jingle <tt>sid</tt> from another simultaneous call or device session;</li>
+      <li>a one-time call location from live location sharing;</li>
+      <li>a stopped or expired call location from a still-live location;</li>
+      <li>a location shared with call participants from a broader contact-visible publication.</li>
+    </ol>
+    <p>Without a Jingle binding, a future relay, accessibility assistant or emergency gateway has to guess whether an XEP-0080 item belongs to the active call. That guessing is unsafe for 112/911-readiness, especially when a user may be deaf, speech-impaired, using real-time text, using video signing, or depending on a relay service.</p>
+    <p>This specification narrows the problem to call binding. It does not create a new coordinate format, a new presence format or a replacement for PEP.</p>
   </section1>
 
   <section1 topic='Requirements' anchor='reqs'>
@@ -227,6 +250,8 @@
       <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>
+    <p>When a client falls back to normal XEP-0080 sharing, it MUST NOT assume that the latest published location item is the location for the active call. The user interface SHOULD show that the location is general location sharing, not call-bound location.</p>
+    <p>This distinction is important for gateway designs. A gateway that bridges an XMPP/Jingle Total Conversation call to SIP or NG112-style infrastructure needs to know which location belongs to the call it is bridging. A general PEP item can be absent, stale, intended for another audience, or replaced by another device. A Jingle-scoped location update gives the gateway a session identifier, sender, content name, timestamp and stop/expiry semantics that are tied to the call state.</p>
   </section1>
 
   <section1 topic='Business Rules' anchor='rules'>
@@ -273,6 +298,8 @@
 
   <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 put XEP-0080 geoloc payloads in ordinary chat messages. That can be useful for one-off location sharing, but it still lacks a standard call binding unless every message carries a Jingle <tt>sid</tt> reference and clients agree on stop/expiry behavior. This specification keeps the binding in the Jingle session where the call already lives.</p>
+    <p>Another alternative is to use only a gateway-local convention. That may work in one deployment, but it does not help two independent XMPP clients or services understand that a location belongs to the same call. A small Jingle binding is intended to make that meaning explicit and interoperable.</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>