[Summit] Tigase and version attribute on stream element..

[Kevin Smith]

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