On Mon, 25 Mar 2019 at 14:03, Florian Schmaus <f...@geekplace.eu> wrote:
> On 25.03.19 13:52, Dave Cridland wrote: > > > > > > On Mon, 25 Mar 2019 at 12:26, Florian Schmaus <f...@geekplace.eu > > <mailto:f...@geekplace.eu>> wrote: > > > > On 25.03.19 12:48, Guus der Kinderen wrote: > > > XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359 > > > "Unique and Stable Stanza IDs" to identify content in the archive. > > > > > > MAM provides an archive on the server, which can be efficiently > > > synchronized with a client-sided archive. It does this using the > IDs > > > from XEP-0359. It's a simple query: the client provides an ID of a > > > message in the archive, the server responds with all later > messages. > > > > > > Although this is a simple, elegant solution, it breaks when the > client > > > receives messages that have XEP-0359 IDs, but are not part of the > > > (server-sided) archive. This puts quite a restrication on XEP-0359 > use > > > in other contexts than MAM. Can this be improved upon? > > > > I think some more context could be helpful. As far as I know this > come > > up yesterday (?) in the xsf@ MUC in a discussion between Guus and > MattJ > > (and waqas). > > > > As far as I understood it, prior MAM versions used an <archived/> > > element which not only contains the ID of the message stanza in the > > archive but also carries the semantic that the message was actually > > archived. > > > > Now Guus wants for some reason to slap a <stanza-id/> on every > message, > > irregardless if it was archived or not. MattJ argued that this would > > break client's assumption that messages with a <stanza-id/> are > actually > > archived. This assumes that clients simply remember the last > stanza-id > > of the message they received and perform a resync of the archive when > > they come online again. > > > > Keep in mind that MAM archives may not archive every message stanza, > > think of IBB messages and the like. > > > > I do not claim to understand every statement and argument in this > > discussion, so please correct me if I am wrong. I am also not sure if > > the problem is an actual problem: There was a interesting discussion > > between MattJ and waqas regarding the guarantees client developers > can > > expect from a MAM archive. > > > > But what I understood is when XEP-MAM switched from <archived/> to > > <stanza-id/> there possibly, depending on the guarantees you expect > from > > MAM, was a loss of semantic. > > > > I see multiple potential solutions: > > > > 1. Introduce an archived flag > > 2. Use <stanza-id/>'s 'by' attribute to carry the archived or not > > semantic > > 3. Potential others > > > > I lean towards 2. Which could mean that > > > > <message from='f...@bar.com <mailto:f...@bar.com>' > > to='u...@example.com <mailto:u...@example.com>'> > > <stanza-id by='example.com <http://example.com>' …/> > > </message> > > > > does not indicate archival of the message into u...@example.com > > <mailto:u...@example.com>'s MAM > > archive, while > > > > <message from='f...@bar.com <mailto:f...@bar.com>' > > to='u...@example.com <mailto:u...@example.com>'> > > <stanza-id by='u...@example.com <mailto:u...@example.com>' …/> > > </message> > > > > does. > > > > > > Ah, so the first suggests the message is archived by the server-level > > archive? > > I'd say it depends whether "example.com" announces the MAM disco#info > feature. And I also believe that this does not automatically imply for > the receiving entity that it has access to that message in the archive > (if there is one). > > Ah, so the semantics of XEP-0359 vary depending on an unrelated specification not referenced by the document in ways that are not specified in either document? Glad that's clear then. :-) > - Florian > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
