[Standards] dialback refactoring

Philipp Hancke fippo at goodadvice.pages.de
Tue May 5 06:39:24 UTC 2009


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



More information about the Standards mailing list