[Standards-JIG] XEP-0114 - to attribute at the root element
m at tthias.eu
Mon Nov 20 01:40:53 UTC 2006
In XEP-0114, section 3 I read:
Example 1. Component sends stream header to server
Note: In the 'jabber:component:accept' namespace, the value of the 'to'
address is the component name, not the server name;  this enables the
server to determine whether it will service a component of that name
(e.g., based on server configuration or some other
implementation-specific mechanism). If so, the server MUST reply with a
Maybe I read this wrong. But if this has to be read, that the to
attribute is in the 'jabber:component:accept' namespace, I think that
this is incorrect.
According to the W3C recommendation "namespaces in XML 1.0", section 6.2:
A default namespace declaration applies to all unprefixed element names
within its scope. Default namespace declarations do not apply directly
to attribute names; the interpretation of unprefixed attributes is
determined by the element on which they appear.
Therefore only elements without a namespace prefix are in the default
namespace. The to attribute in the stream header is unprefixed,
therefore its interpretation is determined by the stream element in the
'http://etherx.jabber.org/streams' namespace. (Which makes it a bit
unlovely, that the to attribute in a component stream has another
meaning as a to attribute in a c2s or s2s stream - where it is as well a
to attribute which gets it interpretation determined by the stream
element in the http://etherx.jabber.org/streams namespace.
I think, that we should keep an eye on this, if we update the component
protocol to XMPP 1.0. Using the from attribute might be a better choice
then. For now I think XEP-0114 does not need an update because of this.
I just write you this mail, so that a second pair of eyes keeps looking
at this when a new component protocol gets defined.
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/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4263 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards