[Standards] Fwd: [TechReview] Review of XEP-0234, 0260 and 0261.

Peter Saint-Andre stpeter at stpeter.im
Tue Aug 17 04:21:52 UTC 2010

I'm forwarding this old message to the Standards list for further
discussion. Expect follow-ups soon.


-------- Original Message --------
Subject: [TechReview] Review of XEP-0234, 0260 and 0261.
Date: Fri, 28 May 2010 14:53:14 +0200
From: Steffen Larsen <zooldk at gmail.com>
Reply-To: XSF Technical Review Team <techreview at xmpp.org>
To: XSF Technical Review Team <techreview at xmpp.org>
CC: XMPP Extension Discussion List <standards at xmpp.org>

Hi All,

Me, Joe and Ali have spend some time last week to review the XEPs
described in the subject.

Here is our summary of XEP-0234 (which I also mailed earlier to the tech

Hash transfer in section 3. has a poor wording: "At any time, the
hosting entity can communicate the hash of the file to the receiving
We believe that it should be changed to "At any time (during the session
life-time or before the session terminates)".
That will make it more unambiguous that it can only be done in the right
state (that is in a session that is not terminated yet).

The <file> tag has a size attribute, but the unit is not explained
anywhere. Its only in XEP-0096 chapter 3 it is explained that the unit
is bytes. It is the same with the hash attribute. In XEP-0234, it is not
visible that it is the MD5 checksum that is used as algorithm.

In XEP-0234 it does not look like that we can do resumable downloads of
files. In XEP-0096 it looks like that there is defined an optional
<range> element. If ranged queries are to be implemented, we could do
that as a transport options/transport features (XEP-0260/0261). But it
seems like that this feature is left out at present time.

In the XEP-0234 XSD schema (chapter 9) we import from the XEP-0096
schema. We find it a bit problematic to refer to another schema that
might be deprecated. So we would propose to make changes to the XSD so
that it reflect the content more explicitly.

In general for XEP-0260/261:

What is the process for eliminating the older XEP-0096 and XEP-0065?  Or
will 96 go on since 234 is specific to Jingle?. It seems like 96 will be
deprecate due to the section 1. in XEP-0234: "SI File Transfer [1] was
the original XMPP protocol extension for file transfer negotiation..".

A summary for XEP-0260:

In section 2. The protocol is described fine but it is not clear what
the '<====>' stream in the flow is. We can see that it is a bytestream,
But not that it is established over TCP sockets (this is only described
later on and in XEP-0065).
But I would say that it is needed to be explicit in the start of aXEP

The section 2.2: "ExchangingCandidates", the sentence is a bit too long.
Maybe this should be split to two or three paragraphs.

In section 2.3: "After receiving its peer’s candidates, a client start
to connect to them in order of the priority. The protocol is described
in XEP-0065 in detail."
It is unclear which peer it is. I assume that the term "peer" is used
because it a TCP connection p2p outside the XMPP connection. But still
its a bit unclear if your a n00b implementing BS5 and do not know
nothing about XMPP.  But still CLIENT and PEER is used interchangeable.
We should clarify this a bit.

In example 3: "The initiator acknowledges receipt and tries to connect
to the offered candidates.. ". Here we should write "The initiator
acknowledges receipt and tries to connect to ALL the offered candidates.. "

In section 6.1 (second bullet) and other places, he RFC3921 is not
linked. Its written as a normal text. It should be made as a citation to
cite9. This is done in the first bullet in section 6.1.

A summary for XEP-0261:

Why are <message> stanzas allowed for IBB?  This seems like it could
confuse a legacy client.

In general:

We are a bit concerned about the number of XEPs a developer would have
to consult to implement...95, 96, 261, 234, 166 and more.  We know that
this is the standard of how we are organizing the XEPs, but from
outsiders it seems cumbersome to work through and come out with an
interoperable piece of software with that in hand.

We were thinking about if we could insert a new section in all the XEPs
that would describe the related XEPs, so a developer would have a better
overview. Could that be an idea? We know that there are made links
inside the XEP documents to the other related documents, but it could be
nice to have an overview. I saw that Tobias made a dependency graph on
http://ayena.de/files/depxepimg.pdf . How is this made?. Is it static or
automatically generated from our XEPs?

Thats all from now. I really hope that it was not too much information
and that our review can be used
BTW why is tracker.xmpp.org still down?. I (Steffen) need to make a new
Jira issue.

-Cheers and have a nice weekend!

Steffen Larsen
xmpp:zooldk at gmail.com

More information about the Standards mailing list