-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 5/5/09 5:34 AM, Matthew Wild wrote:
> On Tue, May 5, 2009 at 7:39 AM, Philipp Hancke
> <[email protected]> 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
> reason.
Maybe. :) The problem is that the dialback <verify/> and <result/>
elements are defined as containing XML character data of type NMTOKEN,
such as this:
<db:verify
from='example.org'
to='xmpp.example.com'>
37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
</db:verify>
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:
<db:verify
from='example.org'
to='xmpp.example.com'
type='error'>
<error type='wait'>
<internal-server-error
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</db:verify>
How will existing dialback implementations parse that? Will they fail
entirely or close the connection?
And is this kind of thing also legal?
<db:verify
from='example.org'
to='xmpp.example.com'
type='error'>
37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643
<error type='wait'>
<internal-server-error
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</db:verify>
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:
<db:verify
from='example.org'
to='xmpp.example.com'
type='error'
condition='internal-server-error'/>
Peter
- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoAUw4ACgkQNL8k5A2w/vwJQACeNMHkYRnLxiq7k6Xer1n9QXqA
1wsAn0s75rscgdgpQ2EVQgWkYYj/lA7y
=0ilV
-----END PGP SIGNATURE-----
