On Thu, Jul 22, 2010 at 6:06 PM, Steffen Larsen <[email protected]> wrote: > Hi All!, > During our summit here monday and tuesday, we came across some obstacles > with Tigase and its way to make S2S stream headers. It was missing the > version attribute on the stream element (see > http://wiki.xmpp.org/web/XMPP_Summit_Interop). > Joe and me took up the challenge and made a small patch for the given source > code. It compiled fine but we did not try it, because we were missing out > the key man that was doing the XCP connections to it.. :-) > Because it was apparently XCP that was enforcing the version attribute > (correct me if I am wrong). > So yesterday I wanted submit the patch to Artur, this guy that is working on > Tigase. But before I submitted it, I just took a quick glaze at the CORE doc > of xmpp (http://xmpp.org/rfcs/rfc3920.html). > It seem like that the version attribute is only a optional attribute > according to our XSD (see appendix > C, http://xmpp.org/rfcs/rfc3920.html#def). But in section 4.4 (Stream > Attributes), it more or less states that the field is mandatory, even though > it says nothing like SHOULD, MUST or anything. So am I missing out > something, or is the core specification misleading in this situation? > Most people at the summit thought that the attribute was mandatory, but it > seems not. > Can any body enlighten me? :-)
This isn't really the right list for this, copying to standards. from http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-10#page-35: """ The following rules apply to the generation and handling of the 'version' attribute within stream headers: 1. The initiating entity MUST set the value of the 'version' attribute in the initial stream header to the highest version number it supports (e.g., if the highest version number it supports is that defined in this specification, it MUST set the value to "1.0"). 2. The receiving entity MUST set the value of the 'version' attribute in the response stream header to either the value supplied by the initiating entity or the highest version number supported by the receiving entity, whichever is lower. The receiving entity MUST perform a numeric comparison on the major and minor version numbers, not a string match on "<major>.<minor>". 3. If the version number included in the response stream header is at least one major version lower than the version number included in the initial stream header and newer version entities cannot interoperate with older version entities as described, the initiating entity SHOULD generate an <unsupported-version/> stream error. 4. If either entity receives a stream header with no 'version' attribute, the entity MUST consider the version supported by the other entity to be "0.9" and SHOULD NOT include a 'version' attribute in the response stream header. """ and """ The inclusion of the version attribute set to a value of at least "1.0" signals support for the stream-related protocols defined in this specification, including TLS negotiation (Section 5), SASL negotiation (Section 6), stream features (Section 4.2.2), and stream errors (Section 4.7). """ So to paraphrase - legacy (pre-XMPP standardisation) might not send you a version, and if they don't you mustn't send them stream features, allow them to starttls, or perform SASL. If you do support XMPP 1.0 (rather than the pre-standardisation XMPP 0.9/Jabber) then you must send 1.0. i.e. Yes, it's mandatory. /K
