Today i have written my previous email als short response. 

I agree that these references should be added. The proposal is not intended to
redefine existing T.140 transport mechanisms.

My current understanding is:

- RFC 4103, updated by RFC 9071, defines RTP payload transport for T.140
  real-time text.
- RFC 8865 defines T.140 over WebRTC DataChannels.
- XEP-0343 is relevant prior XMPP work for signalling WebRTC DataChannels in
  Jingle, although it is currently Deferred.

The reason for this proposal is the application-level binding and semantics,
not generic DataChannel transport.

In a browser implementation, the live text is eventually sent as data over a
WebRTC DataChannel. However, a generic DataChannel alone is not enough for
Total Conversation or for gateway interoperability. A Jingle-to-SIP gateway
must be able to know, without guessing, that this stream is real-time text,
that it belongs to the same active Jingle session as audio/video, and whether
it is typed RTT, captions, ASR, interpreter text, translation, or fallback
text.

Without that semantic binding, a gateway can preserve bytes but still lose the
meaning of the stream. In particular, mapping to SIP/RTP T.140 using RFC
4103/RFC 9071 needs to know that the Jingle text stream is T.140-compatible
real-time text and is part of the same conversation as the audio/video media.

So I see the split as:

- RFC 4103/RFC 9071: RTP/T.140 transport.
- RFC 8865: T.140 over WebRTC DataChannels.
- XEP-0343 or a successor: Jingle signalling for WebRTC DataChannels.
- This proposal: the Jingle application semantics that bind real-time text to
  the same call/session as audio/video for Total Conversation, including
  synchronization level, source, language and visible fallback state.

I think the draft should reference RFC 8865, XEP-0343, RFC 4103 and RFC 9071,
but avoid making XEP-0343 a hard dependency while it remains Deferred. A good
wording might be that the WebRTC DataChannel profile should align with RFC
8865 and with XEP-0343 or any successor Jingle DataChannel signalling
specification.

I can prepare a small follow-up patch to add these references and clarify this
transport-vs-semantics split.

On Tue, 2 Jun 2026 at 10:57, Daniel Gultsch <daniel@gultsch.de> wrote:

Title: Jingle Synchronized Real-Time Text
Abstract:
This specification defines a Jingle application extension for
negotiating real-time text as part of the same conversational session
as audio and video.

URL: https://xmpp.org/extensions/inbox/jingle-rtt-sync.html

This generally looks reasonable, and I support publication, but I'm struggling to find the missing references.

T.140 over datachannel appears to be RFC 8865.

You'll also want XEP-0343 for WebRTC datachannel support in Jingle.

Finally, RFC 4103 updated by RFC 9071 does T.140 over RTP.

(In my view) these don't need to be in place prior to publication but I thought they'd help others review.

_______________________________________________
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org