On 17 August 2010 05:21, Peter Saint-Andre <[email protected]> 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 <[email protected]> > Reply-To: XSF Technical Review Team <[email protected]> > To: XSF Technical Review Team <[email protected]> > CC: XMPP Extension Discussion List <[email protected]> > > 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
