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

Matthew Wild mwild1 at gmail.com
Tue Aug 17 11:37:05 UTC 2010


On 17 August 2010 05:21, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> I'm forwarding this old message to the Standards list for further
> discussion. Expect follow-ups soon.
>
> /psa
>
> -------- 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
> list):
>
> 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
> entity".
> 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.
>

Just a quick note that if we add ranges, we should make sending the
hash with the session-initiate a SHOULD. Otherwise the receiving
client has no way to judge whether it is the same file except by the
filename and size.

Also I've had bad experience (as a user) with transfer resumption thus
far... I think some clients just ignore the range, and send from 0,
causing the range-supporting recipient to receive the start of the
file twice. So either we make range support mandatory, or we need some
way for the initiator to announce it.

Matthew



More information about the Standards mailing list