[Standards] dialback refactoring

Matthew Wild mwild1 at gmail.com
Tue May 5 15:15:15 UTC 2009


On Tue, May 5, 2009 at 3:54 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 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?
>

Aren't we taking the same risk with type="error" though?

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

Me too, very much so :)

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

Acceptable, with the obvious compromise of not being able to include
text. Adding a 'text' attribute would probably be going too far :)

Matthew.



More information about the Standards mailing list