[Standards-JIG] Why is S2S on 5269 and not 5222?

[Matthias Wimmer]

Hi Ralph!

For reference I repeate my XML code:
>>>>>>>>>>
<foo:stream xmlns:foo='http://etherx.jabber.org/streams'
xmlns='jabber:iq:auth' to='example.com' version='1.0'>...(authentication
and such)....<js:message xmlns:js='jabber:server'
to='juliet at example.net' from='romeo at example.com'>...
>>>>>>>>>>

> Absolutely not.
> 
> That section explicitely states:
> 
>   A default namespace declaration is REQUIRED [..]
> 
> and
> 
>   An implementation MUST NOT generate namespace prefixes for elements in
>   the default namespace.

I have fulfilled both requirements in my XML code. I have declared a
default namespace (it's bound to 'jabber:iq:auth'), and I have not used
any namespace prefixes for elements in this 'jabber:iq:auth' namespace.

What you are implying is, that the default namespace always has to be
'jabber:client' or 'jabber:server', but that is not required in RFC 3920.

Read section 11.2.2 again:

>>>>>>
A server implementation MUST support the following two default
namespaces (for historical reasons, some implementations MAY support
only these two default namespaces):
- jabber:client [...]
- jabber:server [...]
>>>>>>

For me this implies, that other default namespaces are allowed as well,
but a server is not required (but allowed) to support them.

And:

>>>>>>
A client implementation MUST support the 'jabber:client' default
namespace, and for historical reasons MAY support only that default
namespace.
>>>>>>

Same for a client.

> The first means you MUST have xmlns='jabber:client' or
> xmlns='jabber:server' in the stream header. The second then implies that
> you cannot use prefixes for elements in the jabber:client namespace if
> that is the default namespace for the stream. Same for jabber:server.

No it only means, that I have to have a xmlns attribute in the stream
header.

> This is a backward compatibility thing with pre-XMPP implementations.
> The fact that in pure XML you can have different representations is not
> relevant. XML Streams have a number of restrictions placed on them with
> respect to pure XML.

I know that, that is why I said you should not generate that, but you
should accept it on incoming streams.


Tot kijk
    Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/