Hello everyone,


I'm re-escalating my request for XEP-0313 update, which purpose is to bring a way to change the user's message archiving preferences (something very basic, so that we keep things simple and respect the philosophy of MAM which is to remove the burden of previous message archiving XEPs).

Plus, we have a working implementation of the updated version of MAM in Jappix. We really needed to proceed the XEP update to make it fully usable by clients, and we'd be glad to see its support being pushed in major XMPP desktop & mobile clients.


You can find the Web browser-viewable version of the updated specification there: https://demo.frenchtouch.pro/valerian.saliou/xmpp/extensions/xep-0313.html
Also, my previous update request from August on this mailing list: http://mail.jabber.org/pipermail/standards/2013-August/027873.html


Hope we can discuss those new changes actively. For your convenience, I attached the diff file for my updated version.


Cheers,

-- 

Valérian Saliou

Uno IM product lead.

More about me on my personal page.
19a20
>     <spec>XEP-0086</spec>
32a34,41
>     <uri>http://matthewwild.co.uk/</uri>
>   </author>
>   <author>
>     <firstname>Valérian</firstname>
>     <surname>Saliou</surname>
>     <email>[email protected]</email>
>     <jid>[email protected]</jid>
>     <uri>http://valeriansaliou.name/</uri>
34a44,49
>     <version>0.3</version>
>     <date>2013-08-05</date>
>     <initials>vs</initials>
>     <remark><p>Introduce the ability to purge part or all of archives. 
> Preferences more flexible: retrieval and push made possible. Starting 
> namespace versioning.</p></remark>
>   </revision>
>   <revision>
152c167
<   <query xmlns='urn:xmpp:mam:tmp' queryid='f27' />
---
>   <query xmlns='urn:xmpp:mam:0' queryid='f27' />
173c188
<   <query xmlns='urn:xmpp:mam:tmp'>
---
>   <query xmlns='urn:xmpp:mam:0'>
189,190c204,205
<       <p>If omitted, the server SHOULD assume the value of &lt;start/&gt; to 
be equal to the
<       date/time of the earliest message stored in the archive.</p>
---
>       <p>If omitted, the server SHOULD assume the value of &lt;end/&gt; to be 
> equal to the
>       date/time of the latest message stored in the archive.</p>
198c213
<   <query xmlns='urn:xmpp:mam:tmp'>
---
>   <query xmlns='urn:xmpp:mam:0'>
206c221
<   <query xmlns='urn:xmpp:mam:tmp'>
---
>   <query xmlns='urn:xmpp:mam:0'>
220c235
<   <query xmlns='urn:xmpp:mam:tmp'>
---
>   <query xmlns='urn:xmpp:mam:0'>
234c249
< <iq type='error' id='q29302'>
---
> <iq type='error' id='q29302' to='[email protected]/orchard'>
250,251c265,266
< <iq type='result' id='q29302'>
<   <query xmlns='urn:xmpp:mam:tmp'>
---
> <iq type='result' id='q29302' to='[email protected]/balcony'>
>   <query xmlns='urn:xmpp:mam:0'>
276c291
<   <query xmlns='urn:xmpp:mam:tmp'>
---
>   <query xmlns='urn:xmpp:mam:0'>
286a302,317
>     <section3 topic='Get latest messages' anchor='query-latest'>
>       <p>In the case where the client does not build a local cache by 
> fetching the whole archive in a chronological order, a reverse order logic is 
> made possible by allowing the retrieval of latest archived messages. It 
> achieves this by including a &lt;set&gt;
>       element within its request, containing an empty &lt;before/&gt;. After 
> the reply to this request is received, it can page through previous results 
> normally (as defined in &xep0059;).</p>
>       <example caption='Querying the archive for latest messages'><![CDATA[
> <iq type='get' id='q29304'>
>   <query xmlns='urn:xmpp:mam:0'>
>       <with>[email protected]</with>
>       <set xmlns='http://jabber.org/protocol/rsm'>
>          <max>10</max>
>          <before/>
>       </set>
>   </query>
> </iq>
>     ]]></example>
>     <p>Note: There is no concept of an "open query", and servers MUST be 
> prepared to receive arbitrary page requests at any time.</p>
>     </section3>
304c335
<   <result xmlns='urn:xmpp:mam:tmp' queryid='f27' id='28482-98726-73623'>
---
>   <result xmlns='urn:xmpp:mam:0' queryid='f27' id='28482-98726-73623'>
317c348
<   <result xmlns='urn:xmpp:mam:tmp' queryid='f27' id='5d398-28273-f7382'>
---
>   <result xmlns='urn:xmpp:mam:0' queryid='f27' id='5d398-28273-f7382'>
331a363,425
> <section1 topic='Purging the archive' anchor='purge'>
>   <p>When it comes that an user needs to do some cleanup in his archived 
> conversations and remove all if not part of them, its client SHOULD provide 
> him a way to remove archived messages.</p>
>   <p>In the case archiving is enforced by the server's policy, archive 
> removal MAY not be allowed, resulting in the server replying with an error 
> reply to such purge requests.</p>
>   <p>A purge query consists of an &lt;iq/&gt; stanza addressed to the account 
> or server entity hosting
>   the archive, with a 'purge' payload. On receiving the query, the server 
> purges the archived messages that match the client's given criteria, and 
> finally returns the &lt;iq/&gt; result.</p>
>   <example caption='Purging the whole archive'><![CDATA[
> <iq type='set' id='purge1'>
>   <purge xmlns='urn:xmpp:mam:0' />
> </iq>
>
> <iq type='result' id='purge1'/>
>   ]]></example>
>   <p>The server MUST reply with a result &lt;iq/&gt; (purge successful) or an 
> error &lt;iq/&gt; (purge unsuccessful).</p>
>   <section2 topic='Filtering purge' anchor='filter-purge'>
>     <p>Most of the time users will not use the whole archive purge feature. 
> Their attention will be driven toward the removal of single messages or parts 
> of conversations. Purge filtering becomes a need for them.</p>
>     <p>As this part uses exactly the same filtering elements that are defined 
> in <link url='#filter'>Filtering results</link>, please refer to this part 
> for more textual explanations on the purpose of each filter element.</p>
>     <p>A purge request can be filtered using the following subset of 
> elements: &lt;start/&gt;, &lt;end/&gt; and &lt;with/&gt;. Since the user may 
> want to remove single messages, an 'id' attribute corresponding to the 
> message UID can be added to the &lt;purge/&gt; element. Note that if the 
> client does not yet know the UID of the message it wants to remove, it'll 
> need to query the archive before doing so, extracting the UID of the remote 
> archived message matching the local one (see <link url='#query'>Querying the 
> archive</link>).</p>
>     <p>A client SHALL NOT send both a purge element with an 'id' attribute 
> and the &lt;start/&gt; or &lt;end/&gt; elements. As a result to such invalid 
> purge request, the server SHOULD ignore it and error-reply, or SHOULD only 
> consider the 'id' presence and ignore both &lt;start/&gt; and 
> &lt;end/&gt;.</p>
>     <section3 topic='Purge multiple messages' anchor='purge-multiple'>
>       <example caption='Purging last messages with Romeo'><![CDATA[
> <iq type='set' id='purge2'>
>   <purge xmlns='urn:xmpp:mam:0'>
>     <jid>[email protected]</jid>
>     <start>2010-06-07T00:00:00Z</start>
>     <end>2010-07-07T13:23:54Z</end>
>   </purge>
> </iq>
>       ]]></example>
>       <p>If Juliet is allowed to proceed archive purge, the server MUST reply 
> with a result IQ. In case the purging process was aborted by a server issue, 
> the server SHOULD reply with an 'internal-server-error'. Otherwise, the 
> server MUST reply with a 'not-allowed' error (error conditions as defined in 
> &xep0086;).</p>
>       <example caption='Purge success'><![CDATA[
> <iq type='result' id='purge2' to='[email protected]/balcony' />
>       ]]></example>
>       <example caption='Purge not allowed'><![CDATA[
> <iq type='error' id='purge2' to='[email protected]/balcony'>
>   <error type='cancel'>
>     <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
>     <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Users are not allowed 
> to purge their archives.</text>
>   </error>
> </iq>
>       ]]></example>
>     </section3>
>     <section3 topic='Purge a single message' anchor='purge-single'>
>       <example caption='Purging a given message'><![CDATA[
> <iq type='set' id='purge3'>
>   <purge xmlns='urn:xmpp:mam:0' id='11483-17790-33628' />
> </iq>
>       ]]></example>
>       <p>Given the UID of the message to be removed, the server needs to 
> search it in its archive database and then proceed the removal if it was 
> found (see the possible error replies for that case in section <link 
> url='#purge-multiple'>Purge multiple messages</link>) or error-reply if it 
> was not found.</p>
>       <example caption='Purge success'><![CDATA[
> <iq type='result' id='purge3' to='[email protected]/balcony'>
>       ]]></example>
>       <example caption='Archive message not found'><![CDATA[
> <iq type='error' id='purge3' to='[email protected]/balcony'>
>   <error type='cancel'>
>     <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
>     <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>The provided UID did 
> not match any message stored in archive.</text>
>   </error>
> </iq>
>       ]]></example>
>     </section3>
>   </section2>
> </section1>
>
336,374c430,457
<   <section2 topic='Simple configuration' anchor='config'>
<     <p>If the server supports and allows configuration then it SHOULD 
implement the protocol defined
<     in this section. This allows the user to configure the following 
preferences:</p>
<     <ul>
<       <li>A list of JIDs that should always have messages to/from archived in 
the user's store.</li>
<       <li>A list of JIDs that should never have messages to/from archived in 
the user's store.</li>
<       <li>The default archiving behaviour (for JIDs in neither of the above 
lists).</li>
<     </ul>
<     <example caption='Updating archiving preferences'><![CDATA[
<   <iq type='set' id='juliet2'>
<     <prefs xmlns='urn:xmpp:mam:tmp' default='roster'>
<       <always>
<         <jid>[email protected]</jid>
<       </always>
<       <never>
<         <jid>[email protected]</jid>
<       </never>
<     </prefs>
<   </iq>
< ]]></example>
<   <p>The server then replies with the applied preferences (note that due to 
server policies these
<   MAY be different to the preferences sent by the client):</p>
< <example caption='Server responds with updated preferences'><![CDATA[
<   <iq type='result' id='juliet1'>
<     <prefs xmlns='urn:xmpp:mam:tmp' default='roster'>
<       <always>
<         <jid>[email protected]</jid>
<       </always>
<       <never>
<         <jid>[email protected]</jid>
<       </never>
<     </prefs>
<   </iq>
<       ]]></example>
<     <section3 topic='Default behaviour' anchor='config-default'>
<       <p>If a JID is in neither the 'always archive' nor the 'never archive' 
list then whether it
<          is archived depends on this setting, the default.
<       </p>
<       <p>The 'default' attribute of the 'prefs' element MUST be one of the 
following values:</p>
---
>   <section2 topic='Retrieve configuration' anchor='config-get'>
>     <p>Before any configurational change can be done, the client SHOULD 
> request the currently active preferences. Thus making the client able to 
> display the server-stored preferences to Juliet, on the top of which she can 
> make changes.</p>
>     <p>It is recommended that such preferences are requested at client login 
> (or when client is back online after being offline). If preferences are 
> updated by another resource while the client is online, it will get pushed 
> the new preferences (as a result, the client SHOULD handle this and MAY 
> update its local database).</p>
>     <section3 topic='Manual configuration retrieval' anchor='config-retrieve'>
>       <example caption='Requesting archiving preferences'><![CDATA[
> <iq type='get' id='get1'>
>   <prefs xmlns='urn:xmpp:mam:0' />
> </iq>
>       ]]></example>
>       <p>The server replies with the currently active preferences:</p>
>       <example caption='Server responds with preferences'><![CDATA[
> <iq type='result' id='get1' to='[email protected]/balcony'>
>   <prefs xmlns='urn:xmpp:mam:0' default='roster'>
>     <always>
>       <jid>[email protected]</jid>
>     </always>
>     <never>
>       <jid>[email protected]</jid>
>     </never>
>   </prefs>
> </iq>
>       ]]></example>
>     </section3>
>   </section2>
>   <section2 topic='Change configuration' anchor='config-set'>
>     <section3 topic='Simple configuration' anchor='config'>
>       <p>If the server supports and allows configuration then it SHOULD 
> implement the protocol defined
>       in this section. This allows the user to configure the following 
> preferences:</p>
376,378c459,461
<         <li>'always' - all messages are archived by default.</li>
<         <li>'never' - messages are never archived by default.</li>
<         <li>'roster' - messages are archived only if the contact's bare JID 
is in the user's roster.</li>
---
>         <li>A list of JIDs that should always have messages to/from archived 
> in the user's store.</li>
>         <li>A list of JIDs that should never have messages to/from archived 
> in the user's store.</li>
>         <li>The default archiving behaviour (for JIDs in neither of the above 
> lists).</li>
379a463,534
>       <example caption='Updating archiving preferences'><![CDATA[
> <iq type='set' id='juliet2'>
>   <prefs xmlns='urn:xmpp:mam:0' default='roster'>
>     <always>
>       <jid>[email protected]</jid>
>     </always>
>     <never>
>       <jid>[email protected]</jid>
>     </never>
>   </prefs>
> </iq>
>       ]]></example>
>     <p>The server then replies with the applied preferences (note that due to 
> server policies these
>     MAY be different to the preferences sent by the client):</p>
>     <example caption='Server responds with updated preferences'><![CDATA[
> <iq type='result' id='juliet1' to='[email protected]/balcony'>
>   <prefs xmlns='urn:xmpp:mam:0' default='roster'>
>     <always>
>       <jid>[email protected]</jid>
>     </always>
>     <never>
>       <jid>[email protected]</jid>
>     </never>
>   </prefs>
> </iq>
>     ]]></example>
>     <p>The server pushes updated preferences to other online resources (note 
> that it SHOULD only push it to clients that have explicitly stated that they 
> support Message Archive Management).</p>
>     <example caption='Server pushes new preferences'><![CDATA[
> <iq type='set' id='push1' to='[email protected]/chamber'>
>   <prefs xmlns='urn:xmpp:mam:0' default='roster'>
>     <always>
>       <jid>[email protected]</jid>
>     </always>
>     <never>
>       <jid>[email protected]</jid>
>     </never>
>   </prefs>
> </iq>
>       ]]></example>
>       <p>Then the client acknowledges that it successfully took the push into 
> account:</p>
>       <example caption='Client acknowledges push'><![CDATA[
> <iq type='result' id='push1' />
>       ]]></example>
>       <section4 topic='Default behaviour' anchor='config-default'>
>         <p>If a JID is in neither the 'always archive' nor the 'never 
> archive' list then whether it
>            is archived depends on this setting, the default.
>         </p>
>         <p>The 'default' attribute of the 'prefs' element MUST be one of the 
> following values:</p>
>         <ul>
>           <li>'always' - all messages are archived by default.</li>
>           <li>'never' - messages are never archived by default.</li>
>           <li>'roster' - messages are archived only if the contact's bare JID 
> is in the user's roster.</li>
>         </ul>
>       </section4>
>       <section4 topic='Always archive' anchor='config-always'>
>         <p>The &lt;prefs/&gt; element MAY contain an &lt;always/&gt; child 
> element. If present, it
>            contains a list of &lt;jid/&gt; elements, each containing a single 
> JID. The server SHOULD
>            archive any messages to/from this JID (see 'JID matching').
>         </p>
>         <p>If missing from the preferences, &lt;always/&gt; SHOULD be assumed 
> by the server to be an
>            empty list.
>         </p>
>       </section4>
>       <section4 topic='Never archive' anchor='config-never'>
>         <p>The &lt;prefs/&gt; element MAY contain an &lt;never/&gt; child 
> element. If present, it
>            contains a list of &lt;jid/&gt; elements, each containing a single 
> JID. The server SHOULD
>            NOT archive any messages to/from this JID (see 'JID matching').
>         </p>
>         <p>If missing from the preferences, &lt;never/&gt; SHOULD be assumed 
> by the server to be an
>            empty list.
>         </p>
>       </section4>
381,397c536,542
<     <section3 topic='Always archive' anchor='config-always'>
<       <p>The &lt;prefs/&gt; element MAY contain an &lt;always/&gt; child 
element. If present, it
<          contains a list of &lt;jid/&gt; elements, each containing a single 
JID. The server SHOULD
<          archive any messages to/from this JID (see 'JID matching').
<       </p>
<       <p>If missing from the preferences, &lt;always/&gt; SHOULD be assumed 
by the server to be an
<          empty list.
<       </p>
<     </section3>
<     <section3 topic='Never archive' anchor='config-never'>
<       <p>The &lt;prefs/&gt; element MAY contain an &lt;never/&gt; child 
element. If present, it
<          contains a list of &lt;jid/&gt; elements, each containing a single 
JID. The server SHOULD
<          NOT archive any messages to/from this JID (see 'JID matching').
<       </p>
<       <p>If missing from the preferences, &lt;never/&gt; SHOULD be assumed by 
the server to be an
<          empty list.
<       </p>
---
>     <section3 topic='Advanced configuration' anchor='advanced-config'>
>       <p>In addition to this protocol, a server MAY offer more advanced 
> configuration to the user
>          through &xep0050;. Such an interface might, for example, allow the 
> user to configure what
>          types of messages to store, or set a limit on how long messages 
> should remain in the
>          archive.</p>
>       <p>If supported, such a configuration command SHOULD be presented on 
> the well-defined
>          command node of "urn:xmpp:mam#configure".</p>
400,407d544
<   <section2 topic='Advanced configuration' anchor='advanced-config'>
<     <p>In addition to this protocol, a server MAY offer more advanced 
configuration to the user
<        through &xep0050;. Such an interface might, for example, allow the 
user to configure what
<        types of messages to store, or set a limit on how long messages should 
remain in the
<        archive.</p>
<     <p>If supported, such a configuration command SHOULD be presented on the 
well-defined
<        command node of "urn:xmpp:mam#configure".</p>
<   </section2>
436,444c573,581
<         <p>If a server or other entity hosts archives and supports MAM 
queries, it MUST advertise
<           the 'urn:xmpp:mam:tmp' feature in response to &xep0030; requests 
made to archiving JIDs
<           (i.e. JIDs hosting an archive, such as users' bare JIDs):
<         </p>
< <example caption='Client queries for server features'><![CDATA[
<   <iq type='get' id='disco1' to='[email protected]' 
from='[email protected]/balcony'>
<       <query xmlns='http://jabber.org/protocol/disco#info'/>
<   </iq>
< ]]></example>
---
>   <p>If a server or other entity hosts archives and supports MAM queries, it 
> MUST advertise
>     the 'urn:xmpp:mam:0' feature in response to &xep0030; requests made to 
> archiving JIDs
>     (i.e. JIDs hosting an archive, such as users' bare JIDs):
>   </p>
>   <example caption='Client queries for server features'><![CDATA[
> <iq type='get' id='disco1' to='[email protected]' 
> from='[email protected]/balcony'>
>   <query xmlns='http://jabber.org/protocol/disco#info'/>
> </iq>
>   ]]></example>
446,454c583,591
< <example caption='Server responds with features'><![CDATA[
<   <iq type='result' id='disco1' from='[email protected]' 
to='[email protected]/balcony'>
<       <query xmlns='http://jabber.org/protocol/disco#info'>
<           ...
<           <feature var='urn:xmpp:mam:tmp'/>
<           ...
<       </query>
<   </iq>
< ]]></example>
---
>   <example caption='Server responds with features'><![CDATA[
> <iq type='result' id='disco1' from='[email protected]' 
> to='[email protected]/balcony'>
>   <query xmlns='http://jabber.org/protocol/disco#info'>
>     ...
>     <feature var='urn:xmpp:mam:0'/>
>     ...
>   </query>
> </iq>
>   ]]></example>

Attachment: smime.p7s
Description: S/MIME cryptographic signature



Reply via email to