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