[Standards] dialback refactoring

Philipp Hancke fippo at goodadvice.pages.de
Tue May 5 12:54:37 UTC 2009

Matthew Wild wrote:
>> 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.

Afaics, there are four error conditions:
- host unknown (can happen in steps 3+4)
- remote connection failed (step 4 only); there might be variants
   like 'no dns entry for remote host' or 'no tcp conn to remote host'.
- remote error (step 4 only, proxy the error condition
   that was seen in step 3 by the receiving server)
- whatever-local-error (step 4 only) - generated by the recv. server if
   something as described in the note after example 8 happens.

Anything I might have missed?

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

There is a difference between error and invalid - the latter is a
security problem. You might want to block the originating ip address if
you get an invalid from the authoritative server.

> Also regarding errors, I just noticed the XEP states: "Queued stanzas
> MUST be bounced back to the respective senders with a
> <remote-server-timeout/> stanza error". Wouldn't
> remote-server-not-found make more sense?

remote-server-not-found implies that the remote server does not exist,
i.e. a dns lookup failed. I don't think it should be used when you
successfully established a tcp connection to that host.


More information about the Standards mailing list