[Standards] dialback refactoring
stpeter at stpeter.im
Tue May 5 14:54:06 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 5/5/09 5:34 AM, Matthew Wild wrote:
> On Tue, May 5, 2009 at 7:39 AM, Philipp Hancke
> <fippo at goodadvice.pages.de> wrote:
>> Peter Saint-Andre schrieb:
>>> 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
Maybe. :) The problem is that the dialback <verify/> and <result/>
elements are defined as containing XML character data of type NMTOKEN,
such as this:
If we say that now these elements can also include error elements
qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace then we
could have things like this:
How will existing dialback implementations parse that? Will they fail
entirely or close the connection?
And is this kind of thing also legal?
I'd sure like to avoid mixed content models!
An alternative is to define another backward-compatible attribute that
can be included when the element is of type error, such as:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards