[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.
>

+1.

> 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.

Regards,
Matthew



More information about the Standards mailing list