[Standards] dialback refactoring

Matthew Wild mwild1 at gmail.com
Tue May 5 11:34:57 UTC 2009

On Tue, May 5, 2009 at 7:39 AM, Philipp Hancke
<fippo at goodadvice.pages.de> wrote:
> Peter Saint-Andre schrieb:
>> http://xmpp.org/extensions/tmp/xep-0220-refactored.html seems OK to me.
> It lacks a when-to-piggyback section and a stream feature for the
> type=error extension. There are some issues with long-term connections -
>  mostly how to handle errors on piggyback connections.
> As you have to solve the same problems for the secure s2s multiplexing
> stuff it makes sense to solve them in a similar fashion.
>> I like the use of dialback errors rather than stream errors. Do we want
> Things Matthias proposes make sense usually ;-)
> The good thing is that adding type=error is not a real backward compat
> problem, because the old behaviour was to terminate the stream.
>> to define a way to specify particular error conditions, instead of only
>> an empty element with no details about the cause of the error?
> In particular this applies to the <db:result type=error/>. This packet
> might mean
> a) remote side does not recognize hostname
> b) verify connection could not be established by remote side
> c) key verification by remote side failed with type=error
> Knowing why this failed would be useful for debugging, but I dont
> see a real value in knowing why there was an error - that can/should
> be in the logs.

Hmm, I had the (mis?)understanding that you were able to put an error
element within the type=error. On a second look it seems this is not
the case. I would be strongly in favour of allowing an error tag.
Without this I'm not sure what real advantage type=error has over
type=invalid. You'd know the connection failed, but not for which

Also regarding errors, I just noticed the XEP states: "Queued stanzas
MUST be bounced back to the respective senders with a
<remote-server-timeout/> stanza error". Wouldn't
remote-server-not-found make more sense?


Would remote-server-not-found be more appropriate?

More information about the Standards mailing list