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