[Standards] stream errors in 206

Thu May 3 15:57:12 CDT 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 
these years.

> 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 
its content.

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 
this list).

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.

Thoughts?

- Ian