[Standards] XEP-0313 for transports

Paul Schaub vanitasvitae at fsfe.org
Wed Feb 26 17:09:49 UTC 2020


> (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 <ivan at 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-unsubscribe at xmpp.org
> _______________________________________________
> 



More information about the Standards mailing list