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

Peter Saint-Andre stpeter at stpeter.im
Thu Aug 19 02:58:48 UTC 2010


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

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/





More information about the Standards mailing list