Peter Saint-Andre wrote:
[...]
However, if you think it is ridiculous to choose option #1 (despite the
fact that this is what RFC 3920 did), then we can continue to discuss
the topic on this list, you can appeal to the XMPP Council,
I had evaluated option #1 when writing the initial 0.4. It is much less
useful when debugging because typically dialback happens twice during a
bidirectional session and with this option it is harder to figure out
which packet belongs to which session.
Option #1 is what we had in RFC 3920. That doesn't seem to have
prevented implementation and deployment of server dialback.
Most implementations I know predate RFC 3920.
Who implemented dialback based on 3920 (or any of the draft versions)?
Who implemented dialback from 0220?
Who implemented dialback by playing with jabberd?
(I have to admit that the figure in rfc 3920 8.2 was really helpful)
I would not advise people who can not deal with the confusion perceived
by you in the (corrected) version 0.8 to attempt implementing dialback,
because what happens on the wire is even more complicated.
At one time I worked on extremely detailed server-to-server examples in
XEP-0238 (XMPP Protocol Flows for Inter-Domain Federation) but it was a
lot of work to maintain.
0238 is really great at showing why we need to get rid of EXTERNAL (-:
So I do not see why now, after 18 months, this change is necessary nor
why it has to be done over the weekend.
Because mixing the directions in the middle of the examples is extremely
confusing.
The direction changes between sub-subsections, not in the middle of the
examples. The initial 0.4 was quite explicit about the who-is-who in the
header, for 2.1 it had something along the lines of:
(still using the old 0.3 hostnames)
> This subsection describes the interaction between the Originating
> Server ('example.org') and the Receiving Server ('xmpp.example.com'),
> from the perspective of the Originating Server.
That way, the 'send' operation/direction was always using
from=example.org in section 2.1 whereas the recv was always associated
with to=example.org in 2.2.
Your way switches send/recv, e.g. in 2.1.1 and 2.2.1 sender.tld is
sending, in 2.1.2 and 2.2.2 target.tld is sending. That is less confusing?
(obviously, the suggestive hostnames are not helpful)
Now, I'd be fine with adding another *complete* set of examples showing
the negotiation in direction 2, resulting in sections like this:
I think we can get a shorter version of this by adding another figure in
section 1.3 which shows the second direction and say where the examples
plug in.
2. "Protocol Flow for Negotiating Connection From sender.tld to target.tld"
(i.e., the current Sections 2.1 and 2.2)
>
3. "Directionality"
(i.e., the current Section 2.3)
(which is currently not very explicit regarding the use of a different
tcp connection for this)
4. "Protocol Flow for Negotiating Connection From target.tld to sender.tld"
(new section similar to 2.1 and 2.2 but in the other direction, so we
don't leave direction 2 as an exercise for the reader as in RFC 3920)
Some implementations will start to negotiate this before the other
dialback process is finished. So a simplified "first this direction,
then the other direction" description is not helpful
(see e.g.
http://mail.jabber.org/pipermail/standards/2010-April/023420.html ).
If you want to document all variants then you will end up with something
that is even longer than 0238. If you go down that path you will end up
describing a session with two hostnames on each side and source/target
piggybacking. *shudder*
However, I continue to think that mixing direction 1 and direction 2 in
the current Sections 2.1 and 2.2 is way too confusing.
See above.
philipp
