The largest issue is that the XEP says a server MUST include <start> and <end> elements in the archive's <metadata>. However, if the archive is empty, this is clearly impossible. We checked Prosody's implementation, and it sends an empty <metadata> element in this case. I think this is the sensible solution (the only other one that came up is returning an error).
This adds a MUST to a draft spec, which I don't do lightly - however I think it is reasonable given that implementations didn't really have many other options, and it benefits interoperability to be consistent about this case.
The second change is just a clarification of what was hopefully already the common interpretation of the current spec. Namely, if no messages match a query, it should return successfully with no results (rather than, for example, returning an 'item-not-found' error).
Note that this does not override the 'item-not-found' error that was already specified if a non-existent id is provided to one of the filters that accepts an id. That error is necessary to preserve a client's ability to detect gaps in their archive synchronization (e.g. if the id they are querying from is no longer present in the archive).
iNPUTmice
commented
1 year ago
These were initially reported by @truenicoco.
Corresponding mailing list thread here.
The largest issue is that the XEP says a server MUST include
<start>and<end>elements in the archive's<metadata>. However, if the archive is empty, this is clearly impossible. We checked Prosody's implementation, and it sends an empty<metadata>element in this case. I think this is the sensible solution (the only other one that came up is returning an error).This adds a MUST to a draft spec, which I don't do lightly - however I think it is reasonable given that implementations didn't really have many other options, and it benefits interoperability to be consistent about this case.
The second change is just a clarification of what was hopefully already the common interpretation of the current spec. Namely, if no messages match a query, it should return successfully with no results (rather than, for example, returning an 'item-not-found' error).
Note that this does not override the 'item-not-found' error that was already specified if a non-existent id is provided to one of the filters that accepts an id. That error is necessary to preserve a client's ability to detect gaps in their archive synchronization (e.g. if the id they are querying from is no longer present in the archive).