Hi,
2009/10/1 Peter Saint-Andre <stpeter at stpeter.im>:
> I think that some points need to be clarified, but I do not agree with
> all of your conclusions.
>
Sorry, did not want to speak in your name. My background sentence was
not well written.
>> 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) +
>
> I see no reason to relax this restriction. Among other things, it would
> break most XMPP implementations, which seems like a bad idea.
>
Hum... at this point, I will just quote Justin Karneges above:
«
At this point, I figure a good number of us are using off-the-shelf, compliant
XML parsers, and so I would like to see the XML generation rules relaxed. We
can keep all of the backwards compatibility stuff marked with SHOULDs.
»
What I want to say and already said is that we are having the
specification of a XML protocol relying on non compliant rules for no
good reason. If this would really break suddenly many implementations,
I would agree. But as I said and Justin said: it won't because it will
be "SHOULD" and no developper will break its client on purpose against
current servers. So it gives years to developers to fix this.
Then at least we don't ask to all the developers using compliant XML
parsers to make "tricks" for the only purpose of refusing perfectly
compliant XML.
>> you MUST have a prefix declared, for the stream related first level
>> elements,
>
> As Dave pointed out, that falls out from having a default namespace.
>
>> and this prefix MUST be "stream".
>
> This is SHOULD in the spec. However, I think we can relax it to say only
> that an implementation MAY accept only "stream:" as the prefix. You can
> draw your own conclusions about whether you ought to set the prefix to
> "stream:" in your implementation (e.g., to avoid interoperability problems).
>
For this point, I think I explained myself very bad. Indeed it is a
SHOULD in the spec (and a "MAY" would be even better), but just after,
the spec says:
«
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/>.
»
So saying that it is allowed to send a prefix different than "stream"
but that it is also ok for the peer entity to send you a stream error
(which is the worse case as it breaks the connection and should only
be used when you clearly break the spec!), I think there is clearly
something wrong.
It is as though there was a law telling that you have the right to do
something, but that then, if you do it, the police has the right to
arrest you.
This is the same here,hence you can write a SHOULD or a MAY or
whatever, in the end, it is just a fake SHOULD or MAY.
I think such a text would be far better:
«
For historical reasons some implementations accept only the 'stream:'
prefix and return a stream error to
a sending entity sending another prefix (usually
<bad-namespace-prefix/> or <bad-format/>).
Thus for backwards compatibility an implementation SHOULD generate
only the 'stream:' prefix for these elements.
»
Here we still advice the use of a "stream" named prefix, but for good
reasons and in a logical way (without contradiction). Then it will be
as for the other point: no developer will break its implementation on
purpose against current implementations and it will give years to
change this if needed.
Bye.
Jehan
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.