> (Also, random thought: seeing XEP-0313 lapse into 'Deferred' is concerning...)
The deferred state doesn't really have any meaning, only that there was no input on the XEP for over a year. Paul 26.02.2020 16:41:06 Ivan Vučica <i...@vucica.net>: > Hi, > > Sometimes, protocols backing transports may support querying for an > archive similar to how it's done with XEP-0313. > > tl;dr Can querying archives on non-own, non-MUC, non-pubsub JID for > 1:1 chats be standardized? Can it be standardized that server > implementations don't have to support date-based queries? > > > > 1. XEP-0313 is specified for archives maintained by the user's own > server. Section 3.3 doesn't specify that a client can query a remote > JID for the archive, which would be useful for transports. It does > specify it for MUC and pubsub, but not for 1:1. > > Here I'm mainly interested: Are there clients that would query a > remote JID for the archive today, despite XEP-0313 not requiring > servers nor clients to support this? Under which conditions would they > do this? > > 2. XEP-0313 is very adamant about filtering being defined based on > start date, end date and communication partner, and requires > server-side support for all three arguments. However, the very first > open(ish) protocol that I decided to check -- Telegram through its > library tdlib -- exposes an API that uses (message ID, offset, limit) > triplet when querying the archive. > > https://core.telegram.org/tdlib/docs/classtd_1_1td__api_1_1get_chat_history.html > > It seems like tdlib might already be supported if the clients didn't > specify start nor end, and only specified RSM set with <after/> > argument. > > I have not looked at what any other open(ish) protocol supports for > server-side archive retrieval, but I'd guess that either > timestamp+offset (0313 style) or messageid+offset (tdlib-style) will > be pretty standard. > > Some questions arise, though, particularly for client authors: > > - How ignorable are 'start' and 'end' on the server side? XEP defines > that support for them is required -- do the implementing clients > require 'start' and 'end' not to be ignored by the server? What would > happen if the server implementation ignored it and returned empty set? > - Do clients do something like recording the existence of 'archive > holes' based on time, and then use timestamps instead of IDs to fill > the local archive's holes from remote data? Would they do the wrong > thing if the response was a dummy message, <first>+<last> specifying > this message > - Would it make sense to have a revision of MAM which *requires* > clients are able to make requests *without* specifying the time? > Perhaps one that responds with some semantic information telling the > client 'I'm returning an empty set because I cannot query the archive > using a timestamp; please omit the time, but feel free to include a > message ID'? > > Does this fit in XEP-0313 or would new XEP be in order? > > (Also, random thought: seeing XEP-0313 lapse into 'Deferred' is concerning...) > _______________________________________________ > 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 _______________________________________________
