On 20 Apr 2021, at 11:22, Kevin Smith <[email protected]> wrote:
>
> 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' <xmpp:mam:2'> and
> 'urn:xmpp:mam:2#extended' <xmpp:mam:2#extended'> features” I think it only
> advertises extended if it supports the extended queries.
>
> 9.1 - misses the extended namespace
And (lastly?) is it reasonable for an archive to have a limit on the allowed
size of the ‘ids’ field? The ‘ids’ requests are a little problematic because
the server has to find where all the messages sit in the archive before it can
construct a result page - this gets somewhat expensive if the client is allowed
to query arbitrarily many in a single request.
/K
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
