moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2025-01-30 15:00:09 -05:00
Code Issues Releases Wiki Activity

Merge branches 'feature/protoxep-inbox', 'feature/protoxep-fulltext' and 'feature/xep-0363'

Browse Source
This commit is contained in:
Jonas Schäfer 2020-01-21 16:40:28 +01:00
commit 9fd9f20584
3 changed files with 256 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

81
inbox/fulltext.xml Normal file
View File

@ -0,0 +1,81 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY ns "urn:xmpp:fulltext:0">
<!ENTITY nsx "urn:example:">
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Full Text Search in MAM</title>
<abstract>This specification proposes a field in the MAM form for full text searching.</abstract>
&LEGALNOTICE;
<number>XXXX</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0313</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>fulltextmam</shortname>
&dcridland;
<revision>
<version>0.0.1</version>
<date>2020-01-21</date>
<initials>dwd</initials>
<remark>
<ul>
<li>Initial Revision</li>
</ul>
</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&xep0313; has an extensible form. This specification extends the extensible form with an extension which extends MAM to perform full text searching. A number of existing implementations of this extension exist - extending their existing extensions to confirm to the extension in this specification now it exists is intended to be trivial.</p>
</section1>
<section1 topic='Overview' anchor="overview">
<section2 topic="Discovering Support" anchor="feature">
<p>Support for this protocol is advertised by the Service Discovery protocol defined in &xep0030; using a feature
of <tt>&ns;</tt>.</p>
</section2>
<section2 topic="Searching">
<p>Searching using full text is performed by the client supplying an additional text key, which if non-empty is used as input to a full text search of some form. The precise meaning of this field is left entirely implementation-defined at this time. Future revisions of this specification might impose additional constraints.</p>
</section2>
</section1>
<section1 topic="Protocol Elements">
<section2 topic="Querying">
<p>A text input field of <tt>{&ns;}fulltext</tt> is hereby defined for the 'urn:xmpp:mam:2' FORM_TYPE, as conforming to the syntax defined in &xep0068;</p>
</section2>
<section2 topic="Results">
<p>The precise matching of the supplied text string is left implementation-defined. Servers MAY use any full-text search engine. While this might mean that certain characters are deemed "special", clients are RECOMMENDED not to attempt any support for these, as they are unlikely to be portable between implementations. A conformant implementation of this protocol could be made, therefore, by accepting any string in the text field and returning nothing (or everything). Any server developer implementing this protocol in such a way MUST buy beers for everyone.</p>
</section2>
</section1>
<section1 topic="Schema">
<p>Not sure this is needed at all.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>None?</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This XEP requires no interaction with &IANA;. </p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>Registration of the field pointing to this document.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Guus der Kinderen nudged me into doing this.</p>
</section1>
</xep>

161
inbox/inbox.xml Normal file
View File

@ -0,0 +1,161 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY ns "urn:xmpp:inbox:0">
<!ENTITY nsx "urn:example:">
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Inbox</title>
<abstract>This specification proposes a mechanism by which clients can find a list of ongoing conversations and their state.</abstract>
&LEGALNOTICE;
<number>XXXX</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0313</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>inbox</shortname>
&dcridland;
<revision>
<version>0.0.1</version>
<date>2019-12-30</date>
<initials>dwd</initials>
<remark>
<ul>
<li>Initial Revision</li>
</ul>
</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>When initially run, a messaging client typically shows some list of contacts and chatrooms, and whether any new
messages are present in each.</p>
<p>The current mechanism for achieving this UX involves a complete synchronization of the server-side archive, and is both
time-consuming and bandwidth-intensive. This specification proposes a solution to directly obtain such data from
the server.</p>
<p>Moreover, the information gathered by the server to support this can be used in support of mobile push notifications.</p>
<section2 topic="Terminology">
<p>Nomenclature used for instant messages versus ancillary messages will need to be adjusted to make it consistent
with &xep0422; et al.</p>
</section2>
</section1>
<section1 topic='Overview' anchor="overview">
<section2 topic="Discovering Support" anchor="feature">
<p>Support for this protocol is advertised by the Service Discovery protocol defined in &xep0030; using a feature
of <tt>&ns;</tt>.</p>
</section2>
<section2 topic="The Inbox">
<p>The Inbox consists semantically of a list of conversations in order of last activity. Each conversation is
identified by a jid - for group chats this would be the chatroom, and for individual contacts this would be their
bare jid.</p>
<p>Each Inbox entry includes a count of messages considered new, the last MAM stanza-id relating to this conversation,
and the last MAM result for this conversation, as defined by &xep0313;. In addition, a client-controlled boolean
marker can be used to indicate a manual "set unread" state.</p>
<p>Finding more messages from this conversation can be achieved via a MAM query using <tt>with</tt> to specify the
conversation required.</p>
</section2>
</section1>
<section1 topic="Protocol Elements">
<section2 topic="Querying">
<p>An &IQ; of type "get" is used, containing a single element <tt>&lt;inbox/></tt>, containing an optional RSM
filter as specified by &xep0059;. This will typically be sent only to the user's own bare jid. The server
responds with a sequence of &MESSAGE; stanzas, each containing an <tt>&lt;entry/></tt> element qualified by the
<tt>&ns;</tt> namespace with a number of attributes:</p>
<ul>
<li><tt>jid</tt> - contains the Jid of the conversation for this entry.</li>
<li><tt>unread</tt> - contains a count of messages which are deemed to be unread by the server.</li>
<li><tt>marked</tt> - a boolean indicating that a client has explicitly marked the conversation for some reason.</li>
</ul>
<p>The <tt>&lt;entry/></tt> element contains the latest instant message, if any, which is encapsulated as a
<tt>&lt;result/></tt> element as defined by &xep0313;. This contains collated fastenings if supported by the
server.</p>
<p>After all entries required have been returned, the server then responds with an &IQ; result containing a
<tt>&lt;fin/></tt> element qualified by <tt>&ns;</tt>. This contains the RSM data, a total count of conversation
entries within the inbox, a count of conversations with unread messages, and a total count of unread messages.</p>
<p>Any counter of unread SHOULD be accurate, however client implementors please note that due to heuristics
involved and other issues these counters can be inaccurate at times.</p>
</section2>
<section2 topic="Marking">
<p>A client MAY at any time set a conversation as marked by sending an &IQ; of type "set" containing something or
other. This causes the server to set the "marked" flag on a conversation. A client SHOULD display a marked
conversation in the same way as an unread conversation, and explicitly removed the marked flag when the
conversation is considered re-read.</p>
<p>Removing a marked flag, even when the conversation is not currently marked, causes the unread counter for that
conversation to be set to zero.</p>
</section2>
</section1>
<section1 topic="Unread Messages">
<p>Servers MUST track which instant messages sent to clients remain unread.</p>
<ul>
<li>An instant message is always read if it is followed by an instant message which is read.</li>
<li>An instant message always starts unread.</li>
<li>A Chat Marker (see &xep0333;) of "displayed" or "acknowledged" causes the message to be read (and also causes
all prior messages to be read by implication).</li>
<li>A Message Receipt (see &xep0184;) does not cause messages to be considered unread. Perhaps it should?</li>
<li>Unmarking a conversation always sets the unread counter to zero, and by implication sets all messages to be
read.</li>
</ul>
</section1>
<section1 topic="Examples">
<p>Let us assume a user has only two contacts they have exchanges messages with, and a single chatroom. Asking for their inbox is simple:</p>
<example><![CDATA[
<iq type='get' id='iq_stanza_id'>
<inbox xmlns=']]>&ns;<![CDATA['/>
</iq>
]]></example>
<p>The server responds with a list of conversations:</p>
<example><![CDATA[
<message>
<entry xmlns=']]>&ns;<![CDATA[' unread='2' marked='false' jid='first_contact@example.net'>
<result xmlns='urn:xmpp:mam:2' queryid='iq_stanza_id' id='uuid-1'>
<forwarded xmlns='urn:xmpp:forward:0'>
<message xmlns='jabber:client' from='first_contact@example.net' to='user@example.org' type='chat'>
<body>Greetings from Alpha Centauri!</body>
</message>
</forwarded>
</result>
</entry>
</message>
]]></example>
<p>After the list of messages, the server completes its response with a the reply to the original IQ.</p>
<example><![CDATA[
<iq type='result' id='iq_stanza_id'>
<fin xmlns=']]>&ns;<![CDATA[' total='3' unread='1' all-unread='2'>
<!-- RSM -->
</fin>
]]></example>
</section1>
<section1 topic="Schema">
<p>TODO - Hopefully roughly given by the examples.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>TODO</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This XEP requires no interaction with &IANA;. </p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>None.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>The author notes that this protocol is heavily based on the <tt>mod_inbox</tt> system of MongooseIM. In addition, Kevin Smith provided useful feedback which has shaped this specification.</p>
</section1>
</xep>

16
xep-0363.xml
View File

@ -32,6 +32,17 @@
<email>daniel@gultsch.de</email>
<jid>daniel@gultsch.de</jid>
</author>
<revision>
<version>0.10.0</version>
<date>2020-01-20</date>
<initials>dg</initials>
<remark>
<ul>
<li>Remove statement about access control from Requirements. (Statement about long randomized file names had been moved to Security Considerations earlier.)</li>
<li>Add section about IP address leak to Security Considerations.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.9.0</version>
<date>2018-12-18</date>
@ -179,8 +190,8 @@
<section1 topic='Requirements' anchor='reqs'>
<ul>
<li>Be as easy to implement as possible. This is grounded on the idea that most programming languages already have HTTP libraries available.</li>
<li>Be agnostic toward the distribution of the actual URL. Users can choose to send the URL in the body of a message stanza, utilize &xep0066;, &xep0370;, or even use it as their avatar in &xep0084;</li>
<li>Do not provide any kind of access control or security for file retrieval beyond Transport Layer Security in form of HTTPS and long random paths that are impossible to guess. That means everyone who knows the URL SHOULD be able to access it.</li>
<li>Be agnostic toward the distribution of the actual URL. Users can choose to send the URL in the body of a message stanza, utilize &xep0066;, &xep0370;, or even use it as their avatar in &xep0084;.</li>
<li>Anyone who knows the URL SHOULD be able to access it.</li>
</ul>
</section1>
<section1 topic='Discovering Support' anchor='disco'>
@ -347,6 +358,7 @@ Content-Security-Policy: default-src 'none'; frame-ancestors 'none';
<ul>
<li>Service implementors SHOULD use long randomized parts in their URLs making it impossible to guess the location of arbitrary files.</li>
<li>Implementors should keep in mind, that without additional end-to-end-encryption, files uploaded to a service described in this document may be stored in plain text. Client implementors are advised to either use this only for semi public files (for example files shared in a public MUC or a PEP Avatar) or implement appropriate end-to-end encryption.</li>
<li>Up- and downloading files will leak the client’s IP address to the HTTP service. The HTTP service might not be the same service as the XMPP service the client is currently connected to.</li>
</ul>
</section2>
</section1>