mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-04 15:02:19 -05:00
126 lines
4.7 KiB
XML
126 lines
4.7 KiB
XML
|
<?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>Message Replies</title>
|
||
|
|
<abstract>
|
||
|
|
This document defines a way to indicate that a message is a reply to a previous message.
|
||
|
|
</abstract>
|
||
|
|
&LEGALNOTICE;
|
||
|
|
<number>xxxx</number>
|
||
|
|
<status>ProtoXEP</status>
|
||
|
|
<type>Standards Track</type>
|
||
|
|
<sig>Standards</sig>
|
||
|
|
<dependencies/>
|
||
|
|
<supersedes/>
|
||
|
|
<supersededby/>
|
||
|
|
<shortname>reply</shortname>
|
||
|
|
<author>
|
||
|
|
<firstname>Natalie</firstname>
|
||
|
|
<surname>Wirth</surname>
|
||
|
|
<email>nataliew@laposte.net</email>
|
||
|
|
</author>
|
||
|
|
<author>
|
||
|
|
<firstname>Marvin</firstname>
|
||
|
|
<surname>Wissfeld</surname>
|
||
|
|
<email>xsf@larma.de</email>
|
||
|
|
<jid>jabber@larma.de</jid>
|
||
|
|
</author>
|
||
|
|
<revision>
|
||
|
|
<version>0.0.1</version>
|
||
|
|
<date>2022-01-01</date>
|
||
|
|
<initials>nw/mw</initials>
|
||
|
|
<remark>
|
||
|
|
<p>First draft.</p>
|
||
|
|
</remark>
|
||
|
|
</revision>
|
||
|
|
</header>
|
||
|
|
|
||
|
|
<section1 topic='Introduction' anchor='intro'>
|
||
|
|
<p>
|
||
|
|
When commenting on a previous message, it is sometimes desired to clarify which message the comment refers to.
|
||
|
|
Currently, &xep0393; quotes are commonly used for that purpose. However, this format does not allow receiving
|
||
|
|
clients to properly identify the referenced message or to adjust the user interface accordingly.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
This specification defines a way to indicate that a message is a reply to a previous message. It does not intend
|
||
|
|
to provide means to create sub-threads for a message.
|
||
|
|
</p>
|
||
|
|
</section1>
|
||
|
|
|
||
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
||
|
|
<p>
|
||
|
|
To indicate that a message is a reply, a <reply> element in the urn:xmpp:reply:0 namespace is placed in the
|
||
|
|
message stanza. The <reply> element has a 'to' attribute containing the full jid of the author of the
|
||
|
|
referenced message and an 'id' attribute containing the id of the referenced message.
|
||
|
|
</p>
|
||
|
|
<example caption="Max replies to Anna's message"><![CDATA[
|
||
|
|
<message to='max@example.com' from='anna@example.com/tablet' id='message-id1' type='chat'>
|
||
|
|
<body>We should bake a cake</body>
|
||
|
|
</message>
|
||
|
|
|
||
|
|
<message to='anna@example.com' id='message-id2' type='chat'>
|
||
|
|
<body>Great idea!</body>
|
||
|
|
<reply to='anna@example.com/tablet' id='message-id1' xmlns='urn:xmpp:reply:0' />
|
||
|
|
</message>]]></example>
|
||
|
|
|
||
|
|
<section2 topic='Compatibility Fallback' anchor='compat'>
|
||
|
|
<p>
|
||
|
|
To provide a fallback for non-supporting clients, the sending client MAY include fallback text in the body and
|
||
|
|
indicate it via Compatibility Fallback.
|
||
|
|
</p>
|
||
|
|
<example caption="Anna replies to a message and includes a fallback"><![CDATA[
|
||
|
|
<message to='anna@example.com' id='message-id3' type='chat'>
|
||
|
|
<body>
|
||
|
|
> Anna wrote:
|
||
|
|
> We should bake a cake
|
||
|
|
Great idea!
|
||
|
|
</body>
|
||
|
|
<reply to='anna@example.com/laptop' id='message-id1' xmlns='urn:xmpp:reply:0' />
|
||
|
|
<fallback xmlns='urn:xmpp:feature-fallback:0' for='urn:xmpp:reply:0'>
|
||
|
|
<body start="0" end="36" />
|
||
|
|
</fallback>
|
||
|
|
</message>]]></example>
|
||
|
|
|
||
|
|
<p>
|
||
|
|
The receiving client SHOULD NOT display the compatibility fallback if it renders the referenced message
|
||
|
|
alongside the reply in some way. However, if the receiving client does not display the referenced message, for
|
||
|
|
example because it doesn't know the referenced id, it MAY display the compatibility fallback instead.
|
||
|
|
</p>
|
||
|
|
</section2>
|
||
|
|
</section1>
|
||
|
|
|
||
|
|
<section1 topic='Business Rules' anchor='rules'>
|
||
|
|
<p>Answers MUST NOT be be assumed to relate to any other messages than the referenced one.</p>
|
||
|
|
<section2 topic='Using the correct ID' anchor='business-id'>
|
||
|
|
<p>
|
||
|
|
For messages of type 'groupchat', the stanza's 'id' attribute MUST NOT be used for replies. Instead, in group
|
||
|
|
chat situations, the ID assigned to the stanza by the group chat itself must be used. This is discovered in a
|
||
|
|
<stanza-id> element with a 'by' attribute that matches the bare JID of the group chat, as defined
|
||
|
|
in &xep0359;.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
This implies that group chat messages without a &xep0359; stanza-id cannot be replied to.
|
||
|
|
</p>
|
||
|
|
<p>
|
||
|
|
For other message types the sender should use the 'id' from a &xep0359;
|
||
|
|
<origin-id> if present, or the value of the 'id' attribute on the
|
||
|
|
<message> otherwise.
|
||
|
|
</p>
|
||
|
|
</section2>
|
||
|
|
</section1>
|
||
|
|
|
||
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
||
|
|
<p>This document requires no interaction with &IANA;.</p>
|
||
|
|
</section1>
|
||
|
|
|
||
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||
|
|
<p>This document requires no interaction with ®ISTRAR;.</p>
|
||
|
|
</section1>
|
||
|
|
|
||
|
|
</xep>
|