New ProtoXEP: No-reply JIDs

Author: mwild1

inbox/no-reply-jids.xml

@@ -0,0 +1,94 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE xep SYSTEM 'xep.dtd' [
+  <!ENTITY % ents SYSTEM 'xep.ent'>%ents;
+]>
+<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
+<xep><header>
+<title>No-reply JIDs</title>
+<abstract>This specification defines a way for JIDs to advertise that they don’t accept incoming chat messages.</abstract>
+&LEGALNOTICE;
+<number>xxxx</number>
+<status>proposed</status>
+<type>Standards Track</type>
+<sig>Standards</sig>
+<approver>
+Council
+</approver>
+<dependencies>
+<spec>XMPP Core</spec>
+</dependencies>
+<dependencies>
+<spec>XEP-0030</spec>
+</dependencies>
+<dependencies>
+<spec>XEP-0115</spec>
+</dependencies>
+<supersedes/>
+<supersededby/>
+<shortname>no-reply</shortname>
+<author>Matthew Wild</author>
+<revision>
+<version>0.0.1</version>
+<date>2025-10-08</date>
+<initials>mw</initials>
+<remark>
+<p>Initial submission.</p>
+</remark>
+</revision>
+</header>
+<section1 topic="Introduction" anchor="intro">
+
+<p>This protocol defines a way for a JID to advertise that it does not accept incoming chat messages. For example, automated services which broadcast messages.</p>
+
+<p>Such an indication allows clients to adapt their user interface accordingly (for example, hiding message input controls), instead of allowing the user to send a message and receive errors. This can improve the user experience and avoid confusion.</p>
+
+</section1><section1 topic="Requirements" anchor="reqs">
+
+<ul>
+<li>The protocol should not require clients to perform additional queries.</li>
+</ul>
+
+</section1><section1 topic="Use Cases" anchor="usecases">
+
+<p>One example use case for this protocol, would be a server which sends welcome messages or other announcements (maintenance, etc.) to its users.</p>
+
+<p>As the users should not reply to these automated messages from the server’s JID, the server advertises 'urn:xmpp:noreply:0' in its &xep0030; features.</p>
+
+<p>In most cases it is expected that the recipient will learn of the feature using &xep0115; rather than performing service discovery just to learn of the no-reply feature. In the case of a server’s JID, the entity capabilities are typically communicated to the client in the initial stream features.</p>
+
+</section1><section1 topic="Accessibility Considerations" anchor="access">
+
+<p>There are no known special accessibility considerations for this protocol.</p>
+
+<p>It is expected that it may improve accessibility by simplifying interfaces where possible.</p>
+
+</section1><section1 topic="Security Considerations" anchor="security">
+
+<p>There are no known security considerations for this protocol, beyond those existing in normal service discovery flows.</p>
+
+</section1><section1 topic="Privacy Considerations" anchor="privacy">
+
+<p>There are no known privacy considerations for this protocol.</p>
+
+</section1><section1 topic="IANA Considerations" anchor="iana">
+
+<p>This protocol does not require any interaction with IANA.</p>
+
+</section1><section1 topic="XMPP Registrar Considerations" anchor="registrar">
+
+<p>This document registers the following service discovery feature:</p>
+
+<ul>
+<li><tt>urn:xmpp:noreply:0</tt></li>
+</ul>
+
+</section1><section1 topic="Design Considerations" anchor="design">
+
+<p>It was debated whether to include the no-reply indication on a per JID, presence or message basis. As most chat clients show an interface featuring an input control per remote JID, and due to the potential optimization afforded by XEP-0115, it was decided to use service discovery.</p>
+
+</section1><section1 topic="XML Schema" anchor="schema">
+
+<p>This document defines no new XML elements or attributes.</p>
+</section1>
+</xep>
+