[standards-jig] SSL/TLS and feature negotiation

Jeremie jeremie at jabber.org
Wed Mar 20 02:08:49 UTC 2002


> There's two ways to implement it, as I see it. One would be to simply
> put SSL on a different port, ala HTTPS, IMAPS, whateverelseS. In this
> case, we need to decide on a standard port to use for this, and,
> depending on how far we want to go, get that port assigned to us by
> IANA.

So far this has been the practice, using 5223 for SSL c2s, and (when
implemented) 5270 for SSL s2s.  Given the current implementations and
general usage, it's probably quite a bit easier for a client to implement
SSL support on an alternate port (those that have done this already could
probably speak to this better).

> The other option, and IMO the better one, is to let the client begin a
> SSL session over the normal client port. This is the way that the
> STARTTLS mechanism works for things like secure SMTP.

Although I agree that this is probably the better way (this is the
direction I've used with xatp), I'm not sure how feasable it is ontop of
the current xml stream transport.  For instance, the given example just
"hangs" on 1.4.2, and I'd imagine support would be difficult to code for
certian jabber client implementations.  It brings up many issues I've had
w/ xml streams in general, namespacing, framing, etc, which are my
motivations for working on xatp :)

Personally, I'm more for focusing on defining Jabber as a set of
application namespaces for routing, pub/sub, messaging, and presence,
leaving the transport work to a set of bindings similiar to soap.

Jer





More information about the Standards mailing list