[Standards] dialback refactoring

Matthew Wild mwild1 at gmail.com
Tue May 5 13:31:05 UTC 2009

On Tue, May 5, 2009 at 1:54 PM, Philipp Hancke
<fippo at goodadvice.pages.de> wrote:
> Matthew Wild wrote:
> [snip]
>>> 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?

Seems fine.

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

Good point.

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

and saying you got a timeout is better? :)

I view "remote-server-not-found" above TCP. If the remote server gave
"host-unknown" for example then I wouldn't consider that a timeout,
rather I really wasn't able to find the correct server to receive a
particular stanza - the remote server was not found (despite
successful TCP connection).


More information about the Standards mailing list