[Summit] Tigase and version attribute on stream element..
kevin at kismith.co.uk
Thu Jul 22 18:00:05 CST 2010
On Thu, Jul 22, 2010 at 6:06 PM, Steffen Larsen <zooldk at gmail.com> 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
> 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.
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
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/>
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.
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.
More information about the Summit