[Standards] serious bugs in XEP-0220 (Server Dialback)

Peter Saint-Andre stpeter at stpeter.im
Fri Apr 22 18:27:58 UTC 2011


On 4/22/11 7:27 AM, Philipp Hancke wrote:
> I think the bug is less serious than you think ...
> 
>> There are two basic problems:
>>
>> 1. In all of the examples of XEP-0220, the dialback key should be the
>> same key -- but the key varies across examples.
> 
> The XEP shows _two_ dialback sessions on two TCP connections.
> If you re-read it with that POV things should make more sense.

Now, why did we do that?!? ;-)

Currently the text (not the examples) says that the spec presents a
single dialback negotiation, organized as follows:

§2.1.1 = Originating Server Generates Outbound Request for Authorization
by Receiving Server

§2.1.2 = Receiving Server Generates Outbound Request for Verification of
Originating Server by Authoritative Server

§2.2.1 = Receiving Server Handles Inbound Authorization Request from
Originating Server (this is the flip side of 2.1.1)

§2.2.2 = Authoritative Server Handles Inbound Verification Request from
Receiving Server (this is the flip side of 2.1.2)

I think we wrote it this way so that a developer could read §2.1 while
writing the code that generates outbound dialback elements (whether
acting as an Originating Server or a Receiving Server) and then read
§2.2 while writing the code that handles inbound dialback elements
(whether acting as a Receiving Server or an Authoritative Server).

I don't know how helpful that really is in practice when developers sit
down to write their dialback code, but that's what we say we're doing.
However, the fact that the examples aren't aligned with what we say
we're doing doesn't help matters.

So we need to either (1) change the examples to match what we say we're
doing, or (2) change the text to match what the examples show. I lean
strongly toward (1).

/psa

[Yes, we could also document the role reversal in which the Target
Domain wants to send outbound stanzas to the Sender Domain so [step1]
the Receiving Server sends an authorization request to the Originating
Server, [step2] the Originating Server sends a verification request to
the Receiving Server's Authoritative Server (but we don't have a term
for that in XEP-0220!), [step3] the Receiving Server's Authoritative
Server returns valid or invalid to the Originating Server, and [step4]
the Originating Server returns valid or invalid to the Receiving Server.
However, that kind of thing really makes your head hurt and the
terminology gets to be quite confusing. :) This is why we usually say
something like "at this point there is a verified connection from the
Sender Domain to the Target Domain, however, if the Target Domain wants
to send outbound stanzas to the Sender Domain then the Receiving Server
needs to negotiate dialback in the other direction ... but we're not
going to document that because it's just a reversal of roles and you can
figure it out on your own".]


-------------- 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/20110422/bbe8423e/attachment.bin>


More information about the Standards mailing list