[Standards] serious bugs in XEP-0220 (Server Dialback)
stpeter at stpeter.im
Mon Apr 25 17:09:24 UTC 2011
On 4/22/11 12:27 PM, Peter Saint-Andre wrote:
> 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).
I've made these changes and will publish version 0.9 soon. Naturally,
further review would be appreciated.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards