[Standards] UPDATED: XEP-0220 (Server Dialback)

Peter Saint-Andre stpeter at stpeter.im
Wed May 18 16:39:55 UTC 2011


My apologies for the delayed reply, I was at the IESG retreat when this
was sent and I've been catching up on email ever since.

On 5/2/11 1:55 AM, Philipp Hancke wrote:
> On Tue, 26 Apr 2011, Peter Saint-Andre wrote:
> [...]
>>>> Changelog: To reduce the possibility of confusion, harmonized the
>>>> protocol sections so that they show only the first dialback
>>>> negotiation from Originating Server to Receiving Server. (psa)
>>>
>>> Congratulations, you managed not to fix the from/to bugs, despite having
>>> a patch ( http://hancke.name/jabber/ilovelovelovebugsinexamples.patch )
>>>
>>> This is ridiculous.
>>
>> I posted to this list about two possible paths: (1) describe only the
>> unidirectional dialback negotiation from Originating Server to Receiving
>> Server, or (2) describe the bidirectional dialback negotiation (the
>> negotiation that authorizes the Originating Server to generate stanzas
>> from the Sender Domain, and the negotiation that authorizes the
>> Receiving Server to generate stanzas from the Target Domain).
>> I said that I leaned heavily toward documenting only the unidirectional
>> negotiation. Your patch assumed that we just needed to do a bit of
>> cleanup to option #2, whereas I decided to choose option #1 because it
>> is confusing to describe both directions.
>> Thus your patch did not really apply.
> 
> Example 5:
> send: <db:verify
>           from='target.tld'
>         ...
> 
> Example 6:
> recv: <db:verify
>           from='sender.tld'
>         ...
> 
> Example 7:
> recv: <db:verify
>           from='target.tld'
> 
> My patch, which changed the 'from' attribute in example 7 to
> 'sender.tld' did not apply?
> 
> Narrative version: the server that sent a <db:verify/> from target.tld
> in example 5 receives a stanza from target.tld in example 7?
> 
> Using your words this is a "serious bug".

Copy and paste error. Fixed in source control.

>> That is not ridiculous, that is a disagreement.
> 
> I have not (yet) reviewed the changes or commented on them.

You commented that it is ridiculous.

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

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

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

Now, I'd be fine with adding another *complete* set of examples showing
the negotiation in direction 2, resulting in sections like this:

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)

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)

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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110518/ef4a0ed6/attachment.bin>


More information about the Standards mailing list