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

Peter Saint-Andre stpeter at stpeter.im
Wed Oct 27 15:41:25 UTC 2010


On 10/27/10 9:17 AM, Matthew Wild wrote:
> 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 have no opinion about "ProcessOne's TextOne subset specification"
because it has never been discussed on this list or any of the other XSF
lists. Anyone is free to submit a specification for discussion and
consideration by the XMPP Council, in accordance with the XSF's policies
and procedures.

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

I think it would be good to aim for interop testing of these and other
mobile-related features at the XMPP Summit in Brussels (February 2010).

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

Now that work on the XMPP RFC revisions is very close to complete, I
will have more time to help with XEPs. 198 is high on my list.

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

Agreed.

The actions of any particular project or company are outside my span of
control, so I don't tend to worry about such things. What's within my
span of control is improving XEP-0198, organizing interop testing at XSF
events, encouraging folks to implement XSF specs, etc. And I definitely
plan to work on those initiatives over the next few months.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20101027/08547f66/attachment.bin>


More information about the Standards mailing list