On 21-Oct-08, at 6:47 AM, Peter Saint-Andre wrote:
Curtis King wrote:
On 20-Oct-08, at 7:37 PM, Peter Saint-Andre wrote:
Please understand that even if we use MUST instead of SHOULD with
respect to namespace-awareness, the existing servers are not
going to
be left behind. Newer servers and server versions are still going
to
continue to support their legacy counterparts. The benefit of
course
would be that eventually we will have a sterilized network, where
clients wouldn't need to worry about rolling out their own
(non-conforming) namespace handling. In my opinion this is a better
long term direction.
I too think that is a worthy goal. The question is: how can we get
there
in a reasonable fashion?
Why not limit the scope of XML-NAMES ?
I think xml like this should be prohibited by the xmpp spec.
<snip/>
Er yes, that *is* ugly. :)
It's not only ugly, but the root of the problem. No?
If we are going to make a change to the spec which will break most if
not all server implementations. Why not do the correct fix, by
changing the text to "MUST not use prefixes as described in XML-
NAMES". We are using XML to frame and encode an over the wire protocol
not store a 500 page document. Let's be smart and not use the parts
which will cause us pain like prefixes.
One the of the big strength of the xmpp model is that servers can
route and do all the heavy lifting for the business rules, etc by just
parse the outer parts of the xml stanza. If the server needs to
validate the xml-names then this will be no longer be true and the
price will be very high. There will be increased latency and limited
scalability.
Pushing the validation to the clients won't work because it's most
likely the servers breaking the prefixes as it routes the stanzas ;-)
I don't see this limitation as a big cost or loss, as I have only seen
one client produce xml with prefixes. We can add a SHOULD saying
servers and clients should accept prefixes where possible for
historical reasons, but I don't know if it would be needed.
ck
