Re: [Standards] XEP-0313 for transports
4 Mar 2020 4:36:08 pm Kevin Smith : > On 26 Feb 2020, at 17:24, Jonas Schäfer < jo...@wielicki.name > [mailto:jo...@wielicki.name] > wrote: > > > > > On Mittwoch, 26. Februar 2020 16:40:06 CET Ivan Vučica wrote: > > > > > 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? > > > > > > > Ugh. No, I don’t think any client would query a remote JID for 1:1 archives. > > > > Why not? MAM’s just a mechanism for querying archives for messages, surely it > shouldn’t matter where the archive is? I meant "right now as it stands". -- Jonas Schäfer This was sent from mobile, and I'm not good with those. Sorry for brevity and such. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0313 for transports
On 26 Feb 2020, at 17:24, Jonas Schäfer wrote: > > On Mittwoch, 26. Februar 2020 16:40:06 CET Ivan Vučica wrote: >> 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? > > Ugh. No, I don’t think any client would query a remote JID for 1:1 archives. Why not? MAM’s just a mechanism for querying archives for messages, surely it shouldn’t matter where the archive is? As concrete examples of when it might make sense to query non-MUC, non-private archives: * An appropriately privileged user querying the archives of other organisation members (e.g. HR in case of harassment cases) * A system that presents a single outgoing JID that is controlled by several users (e.g. shift workers handling a support address) While it might not be a standard personal IM-client feature, I don’t think that means it’s not valid, or that we need to disallow it. /K___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0313 for transports
On Mittwoch, 26. Februar 2020 16:40:06 CET Ivan Vučica wrote: > 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? Ugh. No, I don’t think any client would query a remote JID for 1:1 archives. They only do that for XEP-0045 group chat archives. I see where you’re coming from with the transport perspective, but this one is really tricky: the user’s server will *also* have archived the transport messages because they’re 1:1 (while user servers generally do not archive type='groupchat', unless for XEP-0369). The problem with this is that archive queries and merging archives isn’t easy or cheap. It takes I/O and network bandwidth and logic for merging and deduplicating the messages isn’t trivial either. So clients would generally want to avoid remote archives sources where possible, I guess. However, even though your local server has (the recent parts of) your transport history archived, s2s failures and other things (like the transport losing the session and requiring an active client / password entry to resume the session) may lead to loss which can only be recovered with active s2s-archive-syncing (which we don’t have). So this is a fun can of worms, which should probably *not* go into '313; While it can re-use the protocol from '313, the interaction of transport archives and the user server archives should be specified in a separate document. > 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. I’m not going to get into this and how much of an mis-use of RSM this is again now. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0313 for transports
On Mittwoch, 26. Februar 2020 16:40:06 CET Ivan Vučica wrote: > (Also, random thought: seeing XEP-0313 lapse into 'Deferred' is > concerning...) Actually, XEP-0313 is on the Council’s Short List for Last Call issuing (the step which leads to advancement to Draft). And as Paul says, indeed, Deferred just means that nobody has provided a substantial change to '313 in the past 12 months. Since we do not want to overwhelm the Community with too many LCs and CFEs going on at the same time, we only work through the short list rather slowly. The CFEs and LCs of the past few weeks all came from that list. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0313 for transports
> (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 : > 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 > 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, + 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 ___
[Standards] XEP-0313 for transports
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 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, + 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 ___
