[Standards] Reliable message delivery (XEP-0198 and XEP-0184)

Matthew Wild mwild1 at gmail.com
Wed Oct 27 15:17:36 UTC 2010

On 27 October 2010 15:38, Simon Tennant (buddycloud)
<simon at buddycloud.com> wrote:
> More XMPP clients are being built to run on mobile networks. Message
> reliability on mobile clients has never been great and a good way to detect
> message loss and recover is very important. We need good server
> implementations of these specs.


> We are at the point where we may have competing specs. XEP-0198 and
> ProcessOne's TextOne subset specification.

Are we? Is "TextOne" even published?

> I'm aware that Prosody has an implementation of this and that M-Link has
> also been working on XEP-0198 support.

Yes. I believe that the Psi and Swift clients have also been tested
against both server implementations.

> Is there a way that we can avoid multiple implementations by addressing the
> Mickaël's issues https://support.process-one.net/browse/EJAB-532 (message
> replay, mixing of concepts)?

XEP-0198 replays any lost messages upon reconnect, I'm not sure what
there is to fix there.

The mixing of concepts... this complaint I can understand. I myself
have suggested several times to split XEP-0198 into two XEPs. However
after completing the stream resumption part, I can now appreciate more
how the two apparently different issues are actually closely related.
In Prosody I implemented them as two plugins, but am now considering
merging them to make the code cleaner and more compact.

> I'm a firm believer in implementing something first and then writing a spec
> based on the learnings; could some of the existing implementers please
> comment on the perceived deficiencies of XEP-0198 and XEP-0184?

Dave Cridland and I have done so from the server side of things, see:

  * http://mail.jabber.org/pipermail/standards/2010-June/023512.html
  * http://mail.jabber.org/pipermail/standards/2010-July/023647.html
  * http://mail.jabber.org/pipermail/standards/2010-September/023769.html

> Do parts of the spec need to change?

Yes, see above, it's being worked on.

> What can we do to avoid competing XEPs?

If someone wants to go and write their own specs there's not much "we"
can do to stop them. They are free to submit a protoXEP, and the XSF
council is there precisely to accept or reject such submissions as
they see fit. If a submission were to entirely duplicate an existing
XEP with no real improvements then I would guess it would likely be
rejected. On the other hand competing XEPs are nothing new, and I
don't think anything to be frightened of - as long as we have the
discussion around them and ultimately one gets advanced to Final.

But all this is irrelevant without a specification to review.


More information about the Standards mailing list