Somewhat belatedly... > On 16 Mar 2021, at 20:20, Jonas Schäfer (XSF Editor) <[email protected]> > wrote: > > This message constitutes notice of a Last Call for comments on > XEP-0313. > > Title: Message Archive Management > Abstract: > This document defines a protocol to query and control an archive of > messages stored on a server. > > URL: https://xmpp.org/extensions/xep-0313.html > > This Last Call begins today and shall end at the close of business on > 2021-03-30. > > Please consider the following questions during this Last Call and send > your feedback to the [email protected] discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol?
Yes. > 2. Does the specification solve the problem stated in the introduction > and requirements? Broadly. > 3. Do you plan to implement this specification in your code? If not, > why not? Multiple codebases (me or the the team) > 4. Do you have any security concerns related to this specification? Not that aren’t covered. > 5. Is the specification accurate and clearly written? Broadly, and I suspect all the comments below are likely in bits of thte spec that I wrote, but after reviewing it again … 4.1 - what to do with unexpected fields (this is mentioned later when talking about returning available fields, but probably bears mentioning up front). 4.1.1 jid matching rules aren’t mentioned here, bare JID matching is mentioned later but a forward reference probably wouldn’t hurt, and domain matching isn’t mentioned (because it’s not intended, but calling that out is probably sane, given matching rules in other XEPs typically include domain matching) 4.1.2 - Archives might use greater precision timestamps internally - in this case is it the start or end of the period represented by a given timestamp that’s matched? We probably need to say what happens if e.g. there are four messages within a given timestamp and a client queries with that stamps as the start, or if it queries with it as the end. 4.1.3 - "If the client already knows the UID of one or more messages it wants to fetch, it can use the 'ids' field:” - worth mentioning the type are defined later, here, I think. 4.1.4 - Clark notation is applied inconsistently. 4.3.3/4.3.4 - a quick description of the interaction between <before/> and flipping pages might be in order. Particularly when <before>…</before> is not empty. I think this is easily confused when implementing. 6.1.2 - "A MUC archives allows” typo 6.1.2 - "The archiving entity MUST strip any pre-existing <x> element from MUC messages (as MUC rooms are not required to do this)” - this probably means in the MUC namespace. 7 - "If a server or other entity hosts archives and supports MAM queries, it MUST advertise the 'urn:xmpp:mam:2' and 'urn:xmpp:mam:2#extended' features” I think it only advertises extended if it supports the extended queries. 9.1 - misses the extended namespace /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
