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. 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 definition. 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 http://www.zool.dk xmpp:[email protected]
