[Standards] XEP-0060: order of items
jonas at wielicki.name
Thu Nov 11 07:15:09 UTC 2021
On Mittwoch, 10. November 2021 16:40:54 CET Goffi wrote:
> Le mercredi 10 novembre 2021, 15:26:55 CET Holger Weiß a écrit :
> > * Goffi <goffi at goffi.org> [2021-11-10 10:39]:
> > > It should be spelled out clearly how items are returned (even if
> > > unordered, bug again I don't think that it's a good idea to have
> > > unordered items by default on pubsub).
> > Updating the spec won't update implementations, so unless you also add a
> > new '60 feature that servers can announce, the client still can't make
> > assumptions regarding the ordering, no?
> I saw that as something only missing from text, and spelling it out clearly
> would allow to open bug reports on pubsub implementations following a
> different order (from my interpretation, the order was clear from examples,
> but I know that examples are not specifications).
I concur with Holger on this one. The ticket you linked shows that at least
one implementation has interpreted the text differently, so this is not a
"clarification" where everyone agrees, but a thing where not everyone is in
That would make the proposed change to XEP-0060 practically (and not just
formally) a breaking change. (And as a reminder, XEP-0060 is Stable.)
As Holger points out, you cannot magically make existing implementations
adhere to that anyway. So the choice is between updating '413 to do the
absolutely minimal thing and offer a way to indicate support only for creation.
One middle ground would be to define a disco#info flag to indicate that pubsub
results on a service are always ordered by publication ascendingly (or
somesuch) to advertise the behaviour you want -- but I think a clean solution
based on '413 would be better.
> I can update XEP-0413 to make implementation of "creation" optional (with
> suitable disco#info) thus XEP-0060 would be officially unordered. I just
> hope that implemenation will follow and we won't keep the status quo for
Whether the change is in '413 or in '60 doesn't really matter --
implementations need to be fixed anyway. See it as a way to push for '413
support, I guess.
As a tangential, I'd suggest to drop the MAM part from '413 to narrow the
scope unless you specifically have a use-case for that (as MAM now properly
supports selecting a range by before-id/after-id, so you can page backwards
with RSM as needed).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards