[Standards] stream errors in 206
ian.paterson at clientside.co.uk
Thu May 3 20:57:12 UTC 2007
Mridul Muralidharan wrote:
> Any particular reason why stream error's cant be the usual stream
> error stanza (with a body attribute of type terminate) ?
It does seem strange. I'm not sure why the content of the error was
unwrapped. Perhaps it was due to some since-fixed namespace issue, or
just an early misjudgement (on my part) that was never fixed in all
> If there are stanza's pending on the gateway, this makes it mandatory
> to wait for all other stanza's to be pushed out before sending the
> streamerror in a subsequent response.
> It would be better to just set type=terminate, and have the xmpp
> streamerror as the last child of body xml.
I see, so you want to:
1. be able to inform the client about the server generated stream error
as soon as possible, even if other stanzas have been waiting to be
delivered to the client.
2. append to those stanzas the whole <stream:error/> element, not just
I'll cover the points separately:
1. XEP-0206 doesn't say explicitly that stanzas can't be included inside
a <body type='terminate'/> element. Although the 'remote-stream-error'
section does imply it.
The client I work on currently ignores the content <body
type='terminate'/> elements (other than reporting it in any debug
window). So it would miss the stanzas if the connection manager sends
them in the same response as the error. Some existing clients might even
break (but I really doubt that since the issue has never been raised on
In any case the issue shouldn't occur too often, and the protocol would
be improved for future implementations. So I'm inclined to change
(clarify?) XEP-0206 to allow stanzas inside a <body type='terminate'/>
element, unless people on this list object?
2. I agree it would have been nicer to include the whole <stream:error/>
element. However this change will break any existing client
implementations that care about the content. Do any clients care?
If they do then we could simply make this feature dependent on the value
of the 'ver' attribute agreed by the client and the connection manager
when creating the session. For example, only if the agreed 'ver' is 1.7
or greater then the points 1 and 2 MUST be allowed. The only
disadvantage of being safe is that connection managers will have to
support both behaviors for a few years.
More information about the Standards