[jdev] Re: s2s doubts

[Justin Karneges]

On Wednesday 18 May 2005 11:54 am, Peter Saint-Andre wrote:
> On Wed, May 18, 2005 at 11:18:58AM -0700, Justin Karneges wrote:
> > On Wednesday 18 May 2005 09:42 am, Stephen Marquard wrote:
> > > Justin Karneges wrote:
> > > > If this was meant to be possible, it certainly isn't clear in RFC
> > > > 3920. Is this an extension documented somewhere?
> > >
> > > You do TLS as documented for streams (if advertised as a stream
> > > feature), and then dialback as documented. TLS doesn't add much
> > > additional complexity - the only subtlety is to wait for TLS to
> > > complete once it's started before sending any dialback packets.
> >
> > The spec does not discuss dialback with TLS, or even <stream:features>
> > for that matter.  My problem with what you describe is that it would
> > probably cause breakage between jabberd and my own server implementation
> > which was created according to the spec.  Please don't make stuff up.  If
> > we really want dialback + TLS, this _needs_ to be documented in the RFC.
>
> I fail to see what anyone is making up here. TLS is documented in
> Section 5 of RFC 3920. Server dialback is documented in Section 8
> of RFC 3920. Stream features are documented in Section 4.6 of RFC
> 3920. Nowhere in RFC 3920 is it set forth that two servers MUST
> NOT or SHOULD NOT complete dialback if they have completed TLS
> (although RFC 3920 does say that two servers SHOULD NOT complete
> dialback if they have completed SASL). If you are suggesting that
> rfc3920bis be changed to so specify the relationship between TLS
> and dialback, that is one thing. But the spec as written does not
> forbid this behavior in any way.

The problem is that Section 8 describes itself in an essentially 
self-contained way, with its own order of events (8.2) and different rules on 
the opening stream element (8.3, part 2 & 3).  There is no mention about how 
it would relate to the "1.0" order of events as described in Section 4.

I don't know who decided to implement Dialback + TLS first, but it's not 
enough to just scan the RFC and conclude "it doesn't say you can't!"  I'm 
sure there's a lot of things the RFC doesn't forbid.  However, it's important 
to work with the spirit and intent of the spec.  Looking for tiny openings 
will only cause interoperability problems.

Yes, it needs to be in rfc3920bis.  More than just Dialback + TLS, I'd like to 
see a Dialback + 1.0, which seems to be what is really going on here.

-Justin