[Standards] stream errors in 206

Fri May 4 03:44:40 CDT 2007

Mridul Muralidharan wrote:
> 
> Yes, version mapping is currently a problem.
> imo streamerror's happen rarely enough that it could be acceptable to 

*break*

> 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
>>
>