[Standards] stream errors in 206

Fri May 4 03:39:31 CDT 2007

Yes, version mapping is currently a problem.
imo streamerror's happen rarely enough that it could be acceptable to 
backward compatibility on this.

Mridul

Alex Wenckus wrote:
> Ian,
> 
>> For example, only if the agreed 'ver' is 1.7 
>> or greater then the points 1 and 2 MUST be allowed.
> 
> For each subsequent version of the XEP it will get progressively more
> difficult to maintain server/connection manager code if particular
> things are added to each and every version. It gets to the point,
> depending on how the server is handling errors where you have to check
> versions throughout the code. I thought it was acceptable as a one time
> thing for the 1.6 release but it maybe better to accept that the newer
> version will break older clients then having the server distinguish
> between each version and know what it can and can't send to the client.
> 
> Thanks,
> Alex
> 
> -----Original Message-----
> From: standards-bounces at xmpp.org [mailto:standards-bounces at xmpp.org] On
> Behalf Of Ian Paterson
> Sent: Thursday, May 03, 2007 1:57 PM
> To: XMPP Extension Discussion List
> Subject: Re: [Standards] stream errors in 206
> 
> 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
> 