On Tue, May 5, 2009 at 7:39 AM, Philipp Hancke <[email protected]> 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 reason. 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? Matthew Would remote-server-not-found be more appropriate?
