Part 1, about XEP-0234. See also feedback from Matthew Wild after the XMPP Council meeting the other day:
http://xmpp.org:5290/muc_log/muc.xmpp.org/council/100816/#13:19:33 On 8/16/10 10:21 PM, Peter Saint-Andre 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). Fixed. > 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. I've added a note that all attributes of the <file/> element are defined in XEP-0096, not in XEP-0234. > 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. IMHO the <range/> element in XEP-0096 is underspecified (in fact all of XEP-0096 could use an update), but I think that a session-initiate message in Jingle file transfer could include the <range/> element. Perhaps some examples would help. I'm less confident that this belongs at the transport layer. > 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. Yes, perhaps it is problematic to define the <file/> element in XEP-0096 if we are going to deprecate that spec sometime. It might be better to either (1) remove the <file/> definition from XEP-0096 or (2) define a new element in XEP-0234 that is semantically equivalent to the element from XEP-0096. I think (1) would be fine. > In general for XEP-0260/261: > > What is the process for eliminating the older XEP-0096 and XEP-0065? I think there is no reason to deprecate XEP-0065. Eventually the Council will probably deprecate XEP-0096. > 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..". Eventually, yes. But that might be several years from now. I'll reply separately about XEPs 260 and 261... Peter -- Peter Saint-Andre https://stpeter.im/
