[Standards-JIG] Re: Closing idle streams (server comparison chart)
jean-louis.seguineau at laposte.net
Thu Jun 1 16:58:17 UTC 2006
Philipp Hancke wrote:
>> 2/ From your message, your log only shows the authoritative server part
>> (steps 5 to 8 of RFC3920 8.3) of a dialback handshake. You said "I tried
>>do a version request from hancke.name to im.antepo.com". So you must have
>>sent a dialback key <db:result to='im.antepo.com'
>>from='hanke.name'>98AF014EDC0...</db:result> on the first stream, right?
>Correct, though hostnames and the actual key were different from your
>example. Do you urgently need the log for that?
We certainly do, don't tell me you've lost it... Again matter of
transparency and accuracy.
>> Now from your SRV record, the authoritative server for the "asserted XMPP
>> domain" hanke.name is ve.symlynx.com, right?
>No. The problem was that the SRV record contained a CNAME.
>Looks like your resolver library chooses to ignore that record
>therefore. Not everyone does that. Should I file bug reports to
>jabberd and ejabberd for not ignoring it?
See Dave's previous post on the subject.
>For the record: yes, you're acting correct. I am going to blame my
>DNS admin for violating RFC 2782. Well... not everyone adheres to
>every RFC... some people choose to ignore RFC 1855.
I have always had a lot of fun watching a looser change the rules of the
game during the play. You are not going to blame the server for choosing to
stick to a standard, would you?
>> So it is correct that the
>> receiving server (im.antepo.com) connects back to ve.symlynx.com, right?
> If you ignore that record... yes.
I thought so, thank you for admitting it.
>> After establishing the streams, the receiving server (im.antepo.com)
>> the authoritative server (ve.symlynx.com) a request for verification of a
>> key for the seerted domain <db:verify to="hancke.name"
>> id="i6hiqapy91">6b13c3.... </db:verify>. Am I missing something?
>Well... if you were using stream:to your stream would have been rejected
>right away. hancke.name is not hosted on ve.symlynx.com.
1/ According to spec, the 'to' and 'from' attributes are OPTIONAL on the
root stream element, so your server must not rely on them.
2/ You do not seem to grasp the subtle difference between the "originating
server" and the "authoritative server". Have you ever wonder why the spec
use different names? The "authoritative server" is here to give an answer to
the assertion carried in the verification request. Full stop.
>> At this point, according to RFC3920 8.3.9 the authoritative server
>> (ve.symlynx.com) is supposed to verify the validity of the key, right?
>> that is performed by returning either a <db:verify ... type='valid' or
>> <db:verify ... type='invalid', am I reading the spec correctly?
>> Can you then explain why the authoritative server (ve.symlynx.com)
>> a <stream:error> instead?
>XMPP-Core 8.3 Step 4:
>| If the value of the 'to' address does not match a hostname recognized
>| by the Receiving Server, then the Receiving Server MUST generate a
>| <host-unknown/> stream error condition and terminate both the XML
>| stream and the underlying TCP connection.
>'ve.symlynx.com' does not recognize 'hancke.name'.
In case you did not notice, we are already at step 9. Your reference does
not apply. In this step we are validating the assertion carried in the
verification request. Not checking the dialback key on the "receiving
server". That operation was done long ago by the "receiving server"
im.antepo.com. You cannot just pick any random reference in the RFC and
pretend to use it as you whish.
>Thanks for a nice bug-fixing session! Apologies to the list for
Your most welcome, I'm glad you 1/ learned how dialback works, 2/ apologized
for the first time to the list. We're making progress.
BTW, you did not answer my previous question about which Merak server you
used in your "comparison chart"
Oh, let's not forget. The important point here is that you never managed to
connect to an OPN server. But Carlo's post says, " especially the jabber.com
and the opn antepo implementations kill incoming connections after one or
two minutes of idle time, which makes it very likely to run into racing
conditions and lose incoming messages. that's why i've put '--' there." No
connection means no possible timeout, or am I mistaking? So this statement
is untrue, right?
On another occasion Carlo also said "After a successful RFC compliant
dialback procedure..." There was never a compliant dialback procedure as we
just found out. So again the statement is untrue, right? Actually, the only
thing you are clearly demonstrating is that you made up the famous chart.
Simply because you never tested those connections. Thanks you for your
precious help... Carlo, you're so never ashamed of anything. Do you mind me
calling you liar?
More information about the Standards