Hi,
yesterday I was discussing with Peter about how namespace requirements
were presented in RFC 3920bis, and we both agreed that it is wrong.
The RFC is clearly trying to make an excuse for badly programmed XML
parsers, not able to expand prefixes into namespaces (or keep track of
declared prefix in parent elements). So you MUST absolutely have a
default namespace in the root <stream>, and this one MUST be the one
for the stanza ("jabber:client" or "jabber:server", most typically) +
you MUST have a prefix declared, for the stream related first level
elements, and this prefix MUST be "stream".
So for instance, the current RFC asks me to reject and consider this
stream start as an error, though it is perfectly valid XML and
conforming to XMPP:
<toto:stream
from='juliet at im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:toto='http://etherx.jabber.org/streams'>
And many other examples: for instance, if I prefer to use a declared
namespace for "jabber:client" instead of a default namespace, why
couldn't I? This is good XML, and what only matters is the final
expanded name (however we got to it). This is all for historical
reasons, for backward compatibility with jabberd 1.0 in "old" times,
as Peter explained me, but we agreed that nowayday, such a stuff
should not be in an RFC, presented as "the good way to do". Probably
it should just become a note of "For historical reasons, some
implementations may require...", so that we still aknowledge this old
issue, but without asking softwares to refuse the other good ways.
There are several parts to change about this. In particular in 12.2
-------------------
12.2.1. Streams Namespace
A streams namespace declaration is REQUIRED in all XML stream headers
and the name of the streams namespace MUST be
'http://etherx.jabber.org/streams'. If this rule is violated, the
entity that receives the offending stream header MUST return a stream
error to the sending entity, which SHOULD be <invalid-namespace/> but
MAY be <bad-format/>.
The element names of the <stream/> element and its <features/> and
<error/> children MUST be qualified by the streams namespace prefix
in all instances. If this rule is violated, the entity that receives
the offending element MUST return a stream error to the sending
entity, which SHOULD be <bad-format/>.
An implementation SHOULD generate only the 'stream:' prefix for these
elements, and for historical reasons MAY accept only the 'stream:'
prefix. If an entity receives a stream header with a streams
namespace prefix it does not accept, it MUST return a stream error to
the sending entity, which SHOULD be <bad-namespace-prefix/> but MAY
be <bad-format/>.
-------------------
should probably become something like:
-----------------
12.2.1. Streams Namespace
The element names of the <stream/> element and its <features/> and
<error/> children MUST be qualified in all instances by the streams
namespace,
whose value is "http://etherx.jabber.org/streams";. If this rule is
violated, the entity that receives
the offending element MUST return a stream error to the sending
entity, which SHOULD be <bad-format/>.
For historical reasons, some older implementations may accept only a
stream element qualification through a prefix named "stream" (and not
for instance through a default namespace, nor a prefix named other
than "stream"), declared in the initial <stream/> element. For
backwards compatibility, it may therefore be a good idea, though not
mandatory, to declare a prefix named "stream" and with value
"http://etherx.jabber.org/streams"; in the <stream/> header. However an
implementation MUST NOT send any error, hence reject a stream doing
differently, as long as the qualified names for the <stream/>,
<features/> and <error/> element are correct with this alternative
method.
-----------------------------
Then I would change the next section:
-----------------------------
12.2.2. Default Namespace
A default namespace declaration is REQUIRED and defines the allowable
first-level children of the root stream element. This namespace
declaration MUST be the same for the initial stream and the response
stream so that both streams are qualified consistently. The default
namespace declaration applies to the stream and all first-level child
element sent within a stream unless explicitly qualified by the
streams namespace or another namespace.
A server implementation MUST support the following two default
namespaces:
o jabber:client -- this default namespace is declared when the
stream is used for communication between a client and a server
o jabber:server -- this default namespace is declared when the
stream is used for communication between two servers
A client implementation MUST support the 'jabber:client' default
namespace.
If an implementation accepts a stream that is qualified by the
'jabber:client' or 'jabber:server' namespace, it MUST support the
common attributes (Section 9.1) and basic semantics (Section 9.2) of
all three core stanza types (message, presence, and IQ).
For historical reasons, an implementation MAY refuse to support any
other default namespaces. If an entity receives a stream header with
a default namespace it does not support, it MUST return an <invalid-
namespace/> stream error.
An implementation MUST NOT generate namespace prefixes for elements
qualified by the default namespace if the default namespace is
'jabber:client' or 'jabber:server'.
Note: The 'jabber:client' and 'jabber:server' namespaces are
nearly identical but are used in different contexts (client-to-
server communication for 'jabber:client' and server-to-server
communication for 'jabber:server'). The only difference between
the two is that the 'to' and 'from' attributes are OPTIONAL on
stanzas sent over XML streams qualified by the 'jabber:client'
namespace, whereas they are REQUIRED on stanzas sent over XML
streams qualified by the 'jabber:server' namespace.
An implementation MAY support a default namespace other than "jabber:
client" or "jabber:server". However, because such namespaces would
define applications other than XMPP, they are to be defined in
separate specifications.
-------------------
As follow:
------------
12.2.2. First Level Namespaces
On first level, an implementation MUST understand the children element
<features/> and <error/>, qualified by the stream namespace
"http://etherx.jabber.org/streams"; (see previous section) as well as
other first-level children defined by implementation choice.
These allowable first level children, other than the ones qualified by
the stream namespace, must be qualified by specific namespaces
grouping them into a common semantic applications. Such first level
children are called the stanzas.
A server implementation MUST support the following two default
namespaces:
o jabber:client -- this namespace qualifies core stanzas when the
stream is used for communication between a client and a server
o jabber:server -- this namespace qualifies core stanzas when the
stream is used for communication between two servers
A client implementation MUST support the 'jabber:client' default
namespace.
If an implementation accepts a stream that is qualified by the
'jabber:client' or 'jabber:server' namespace, it MUST support the
common attributes (Section 9.1) and basic semantics (Section 9.2) of
all three core stanza types (message, presence, and IQ).
For historical reasons, an implementation MAY refuse to support any
other stanza namespace. If an entity receives a first level
element qualified
by a namespace it does not support, it MUST return an <invalid-
namespace/> stream error. In an entity receives a first level
element qualified by
a namespace it supports, but whose local name is not defined in this namespace,
it MUST return an <unsupported-stanza-type/> stream error.
Note: The 'jabber:client' and 'jabber:server' namespaces are
nearly identical but are used in different contexts (client-to-
server communication for 'jabber:client' and server-to-server
communication for 'jabber:server'). The only difference between
the two is that the 'to' and 'from' attributes are OPTIONAL on
stanzas sent over XML streams qualified by the 'jabber:client'
namespace, whereas they are REQUIRED on stanzas sent over XML
streams qualified by the 'jabber:server' namespace.
An implementation MAY support stanzas qualified by namespaces other
than "jabber:
client" or "jabber:server". However, because such namespaces would
define applications other than XMPP, they are to be defined in
separate specifications.
--------------
There are other stuffs to change in the RFC related to this
problematic. But for now let's launch the discussion from this point.
:-)
Bye.
Jehan
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.