[Standards] dialback refactoring

Peter Saint-Andre stpeter at stpeter.im
Tue May 5 14:54:06 UTC 2009


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




More information about the Standards mailing list