<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-frindell-moq-chat-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.4 -->
  <front>
    <title abbrev="moq-chat">MoQ Chat</title>
    <seriesInfo name="Internet-Draft" value="draft-frindell-moq-chat-00"/>
    <author fullname="Alan Frindell">
      <organization>Meta</organization>
      <address>
        <email>afrind@meta.com</email>
      </address>
    </author>
    <date year="2024" month="October" day="21"/>
    <area>Applications and Real-Time</area>
    <workgroup>Media Over QUIC</workgroup>
    <keyword>media over quic</keyword>
    <abstract>
      <?line 36?>

<t>MoQ Chat (moq-chat) is a simple text based protocol for exercising MoQ
Transport.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://afrind.github.io/draft-frindell-moq-chat/draft-frindell-moq-chat.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-frindell-moq-chat/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Media Over QUIC Working Group mailing list (<eref target="mailto:moq@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/moq/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/moq/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/afrind/draft-frindell-moq-chat"/>.</t>
    </note>
  </front>
  <middle>
    <?line 42?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>MoQ Chat (moq-chat) is a simple text based protocol for exercising MoQ
Transport <xref target="MOQT"/>.  The protocol allows many
participants to join a virtual chat room, publish messages to the room and
receive messages published by others.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

<t>Commonly used terms in this document are described below.</t>
    </section>
    <section anchor="chat-operation">
      <name>Chat Operation</name>
      <section anchor="moq-relay">
        <name>MoQ Relay</name>
        <t>The protocol requires a MoQ relay to act as a chat server.  The relay maintains
the set of connected clients that have announced a chat track.</t>
      </section>
      <section anchor="chat-id">
        <name>Chat ID</name>
        <t>Every chat has a unique ID.  The ID is a string of arbitrary length and uniquely
identifies the chat.  The creation of chat IDs and discovery of the relay is
out of the scope of this document.</t>
      </section>
      <section anchor="track-names">
        <name>Track Names</name>
        <t>Each chat participant has a chat track.  The namespace of the track is
("moq-chat", &lt;id&gt;, &lt;user-id&gt;, &lt;device-id&gt;, &lt;timestamp&gt;) and the name
track is "chat".</t>
        <ul spacing="normal">
          <li>id - the ID of the chatroom</li>
          <li>user-id - the user ID</li>
          <li>device-id - a unique identifier for each device for the user.  This allows
            the same user to join the chat from multiple devices</li>
          <li>timestamp - the timestamp in seconds when the track started, encoded as a
            string.  This allows a stateless client to start publishing
            without accidentally overwriting a previously sent group and
            object.
            Note: the protocol will still function so long as each chat
            client selects a monotonically increasing number for this field.
            Using the common format described here could support future
            functionality like pulling chat history.</li>
        </ul>
      </section>
      <section anchor="joining-the-chat">
        <name>Joining the Chat</name>
        <t>To join the chat a participant sends a SUBSCRIBE_NAMESPACE message to the relay
with a namespace prefix ("moq-chat", &lt;id&gt;).  MoQ Relays track the current
state of all announced namespaces and namespace subscriptions, and forward any
matching ANNOUNCE or UNANNOUNCE messages to interested endpoints.</t>
        <t>The participant also sends an ANNOUNCE message for their chat track namespace.</t>
      </section>
      <section anchor="subscribing-to-chat-messages">
        <name>Subscribing to Chat Messages</name>
        <t>When receiving an ANNOUNCE that matches the chat prefix, the client extracts the
client's user-id, device-id and timestamp from the third, fourth and fifth tuple
elements, respectively.  The client <bcp14>SHOULD</bcp14> subscribe to the latest timestamp
track for each (user-id, device-id) pair.</t>
        <t>Upon receiving an UNANNOUNCE, a client <bcp14>SHOULD</bcp14> UNSUBSCRIBE from that
matching track if it had previously subscribed.</t>
      </section>
      <section anchor="chat-messages">
        <name>Chat Messages</name>
        <t>Each chat message is sent in a new Group and new Object.  The format of a chat
chat message this draft is UTF-8 Encoded text.  There is no limit to
the length of a chat message beyond those imposed on QUIC streams.  Chat clients
<bcp14>MUST</bcp14> send an END_OF_GROUP message for each Group.</t>
        <t>The starting Group ID for each track starts at 0 and increments by 1.  The
Object ID for each chat message starts at 0 and increments by 1.</t>
      </section>
      <section anchor="leaving-the-chat">
        <name>Leaving the Chat</name>
        <t>When a user leaves the chat, they <bcp14>SHOULD</bcp14> send an UNANNOUNCE message for their
namespace. They also <bcp14>SHOULD</bcp14> publish an object with status
END_OF_TRACK_AND_GROUP on their chat track, since they will start a new track if
they rejoin.  Finally, they <bcp14>SHOULD</bcp14> send an UNSUBSCRIBE message for any
tracks they subscribed to before closing their Transport Session.</t>
        <t>If all publishers of a given namespace disconnect from the relay abruptly, the
relay will send UNANNOUNCE messages matching SUBSCRIBE_NAMESPACE to interested
endpoints.</t>
      </section>
      <section anchor="stream-mapping">
        <name>Stream Mapping</name>
        <t>The <bcp14>RECOMMENDED</bcp14> forwarding preference for the chat track is Subgroup, with all
subgroup IDs set to 0, though clients <bcp14>MAY</bcp14> use other forwarding preferences at
their discretion.</t>
      </section>
      <section anchor="session-closure-by-the-server">
        <name>Session Closure by the Server</name>
        <t>If a client detects a MOQT session has been closed by the relay, it assumes
the relay has exited or crashed, and does not attempt to reconnect.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TODO Security</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="MOQT">
        <front>
          <title>Media over QUIC Transport</title>
          <author fullname="Luke Curley" initials="L." surname="Curley">
            <organization>Discord</organization>
          </author>
          <author fullname="Kirill Pugin" initials="K." surname="Pugin">
            <organization>Meta</organization>
          </author>
          <author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
            <organization>Cisco</organization>
          </author>
          <author fullname="Victor Vasiliev" initials="V." surname="Vasiliev">
            <organization>Google</organization>
          </author>
          <author fullname="Ian Swett" initials="I." surname="Swett">
            <organization>Google</organization>
          </author>
          <date day="21" month="October" year="2024"/>
          <abstract>
            <t>   This document defines the core behavior for Media over QUIC Transport
   (MOQT), a media transport protocol designed to operate over QUIC and
   WebTransport, which have similar functionality.  MOQT allows a
   producer of media to publish data and have it consumed via
   subscription by a multiplicity of endpoints.  It supports
   intermediate content distribution networks and is designed for high
   scale and low latency distribution.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-moq-transport-07"/>
      </reference>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
    </references>
    <?line 170?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAK3FFmcAA61YbW8buRH+zl/BKh+aHCw5bgNcauRyp8j2ndpYSmwJh0NT
BNxdSuJ5d7khuXZ0Qf5Lf0t/WZ8Z7ptsB/3SALHEt+HMMzPPDDUej4UIJuT6
VI4u7Xs526kwEipJnL7FVGE/jVOeSlXQW+v2p9KUGytEZtNSFTiWObUJ440z
ZabzfNyeGD9/LnydFMZ7Y8uwr7B1fr66kPKJVLm3EE4nKo0/ZRgdydF8+gYf
1uHb1epiJMq6SLQ7FRluPhWpLb0ufe1PZXC1FtDur0I5rSBoWlW5gYK4yEtV
ZvJKq3y8MoUeiTvrbrbO1hUZqDOj5PJWO/l+PZ+NxI3eYz07FXIsC160tPip
Nqm41WWNe6X85mkpo1mjX3GHKbfyZ9pJ84UyeUTvJ6PDZmLdlqaVS3eY3oVQ
+dPjY9pFU+ZWT9ptxzRxnDh75/Uxzh/Tua0JuzrBScUwH38DctqaAywfBpfE
I5MoYmLstw5/a36yC0U+EkLVYWcdIYVbpNzUeR79P81VKS+aY7wGM1Rp/mB/
nMpLHRRP64hKVOinAtOT1BZClNYV2HsLsAXFVj8S4/FYqsQHp9IgRBuf8mmr
3DNp4HDpTVHlWgb9OchEeZ3JytlgU5tLiJP6s3ap8eQhiBArp0pfWRcmzQ2F
ybJcC/FEzsvgbFanpPn//z755cufLpfvVz/Mx2fscAY5tMtfv06kXO10L0zl
OeIA0VTuRaVcMKmpVBm8DFb+bk0JVW6NC7XKJWknnbXFkazqJDd+h4D2Xm01
7w4QS6uUHcLpVAPgfkNzAnYke2mx1/kJwTGzJbKgT6szvTGl4bEQpCnyR1IC
eWTH+npFWUyfcrHk71fnSJSr8zP6fv3L9O3b7otodlz/sly/Peu/9Sdny8vL
88VZPIxZeTAlRpfT37BCWo2W71bz5WL6dgRqgqVwEcipLqA5Mk6T+YnGUtCu
cjrASuVFpn3qTIIBzryZvfvPv09ekH+uLmZ/OTn529evzeDlyfcvMLjb6TLe
Zst83wwB1F6oqtLKkRR4S6aqMgH0hr1e+p29KyXQ1EDzu38SMv86la+StDp5
8bqZIIMPJlvMDiYZs4czDw5HEB+ZeuSaDs2D+XtIH+o7/e1g3OI+mHz1Y25K
LccnL398jeya2aJgwGpKEjig8I/7qHdHohHzlJlPYu4tK+1UzMcnTyifQO65
2sf46zLFaXC205SctMXRFnI8eIM8oWJ+eO3A3k2WxT3gpDLgvxeUIl4HaTcS
tabUKUVKmhvNCUfHdwpJo8rS1mVKURSFEjndTFg7Vnh+JsQ5rtnH5R1fX5fm
U62x1lw+P2uYJDiiCdypXGIgCsdyXW7DjoMtHsv3wlCRNBtD2YzjTMxRUooS
SPCw3vH+mKyZ8allPbASOoONF7YO7Ry2VDoOBi6J1qzIMLkAySPbz1W6i/IH
RNQYN4Ah6kSFwVcq1e01vEhXP+07iiP54ZXJPrymT4SHG7eDTN+aVHfDgDLu
gyqqD6+fsWGhuUG0UuWIBVKSSZOhlIeIcHM5LRL3YbW5p9lCI3LXd7K7Eiud
szrMXWR1QiBu5HErgW0mZzJZc6Xr/zHG0DXe1dJ2q5XcOFByUefBUD2Jwj30
6WxuNO3HOO014hOUSyQ0QBfrDiF7JHWZ2oxZTqp76sRwO9SYoxBdQ45q0MQ7
Kcri2sqAQ/ck3aGfoDhSaco4Qdaem6c7hwKBkFZITthja48FT0K5j+ICdCjK
Jr8j2Sb3ZhcWXR+b1yX5nQHD+kB/N0hBjnpvZW7pOh8dRLDek9TY5GFhGshc
UBIklugYSWlTUgpxtY4dZ+NdAATf59l9xda8lV3I7CZjxzKgMGJ8LNZ5Jn1d
ceXf1KF2+p6k1giVm4C0NzewFW0ViY/UYXxAxx2z8e8InPZi4hkQ4P1oUge5
CcwzsvZ6/eZ6djV/c/5xMb08v343nZ23lb/rDJhRyaXY3ycvHLgxn+UjOfsM
IdRRsW8CkPWonQPYgiOKaQ3O6imzkx0pqr8KLwVCr+LeIhZawHqnHMIYzQ/w
TSkI5XSxWK4XsAAuWi+60bDV4UKPbMF1QKACQoG6GS4XA3joDdJiVMr7ktoM
N27Abr2+0SXXUemE3WIj+182mgjxK6VnbLU4HwaXcDVhmwZ83sB9FCdizKLB
pNaXN4k492ffstjRgLaYFzuSYFphZtgZh30bW7umomzMBt9CDb4RSAhie+AN
vCokB5rCfN/WlahB0z40/km6kInvjP7Ohow7onz6UMlnwN84QLeu7D1kelce
UT05uHq96CK4NQzR30VEUwQ20lA5yg5Yp1U6G5Tn3kF9SWudjpRnpuLOutR3
8UEXQxWjZSSqiE+T9RTikXQOJMVySi8qErpeXYxfyvOGl+nZEIU4vrIEhZnC
EOtyE9LU/05yJzTRe8v1z3ocLCpLTRWgpNcoUbtWhYdgNrNpXAT3mBTmBDNa
uo/Li48/Xy3X7w4inV3GxjaZwuzfPWmpmHbbBtUGqRPkc8aHWZSjid4QJ9E+
ERE7OH5g0f+Swm57q9XtIfNxaqlYU3OsDrIoduVd2DaGP6SKPsFFn9Wk8z4y
QyOgfUtBRixTXPi4YNZeNHiurqazf3ycYhCRteUD6jjCmxEMGJVr6hjV1xhm
bQwLXnaaaB0IXpiSKtS3TOrTYmgT0SXL8/FYnwTxIYQ9lNy2rWJQs3+gXmv+
tQa4zyN1ty9D52M8bkER5YC3ucnkZrknndhnqsTVVWi0F3EuGk4GPMbdXUo/
VrEOiF0MiZ2ImGNfXuItRp0KR/DgEdOWEpJNJAsp5aCJGxA8shGkzo3KUfQ0
QKCfsbZNGnh+IkCZ52SXrbe77omA1xFFZHw/P34lRbqImBNweIxGsMmEiLyc
wTPoFCj8SbdrfrFEd7S8mOENGxsZ+jEBCsWT1IsnGt4h58anfOeNI2JH5X1N
vXzvIzqiPxsqlcAidYp+A4jVN7OamAmnQtBFxTY73fiafxy41ij21LjMULLR
A8ZXGv0wsDxbdqv8kJtPF9OH2w4egaQKiJB3Ku6KfPvzTALPkJRpelPau1xn
W2YI8eU09ms6+2G0QdLq0dfmctXtRKX+L6+78+fjFAAA

-->

</rfc>
