On Mon Dec 15 20:18:48 2008, Dirk Meyer wrote:
Jingle XML Streams do not only use Jingle, they also use a normal
stream
setup similar to client/server communication: one roundtrip Jingle,
at
least one for the transport (IBB) to open the stream. These are
two. After that we have stream setup, STARTTLS feature negotiation,
TLS itself (2 rt), and a stream restart. Sums up to 7. XTLS needs
one rt
for itself + 2 for TLS.
Okay, with you now, I'd forgotten about the actual stream startup.
No, if we would use TLS directly on Jingle it would be less.
Right, indeed.
Not suitable for e2e XML streams. For other use cases incl. TLS over
Jingle without the stream stuff it is simpler. BTW, adding TLS for
any
Jingle stream would be also nice to have.
Okay, so humour me for a second.
In practical terms, then, we move XEP-0250 negotiation inside Jingle
as a transport, and strip down IBB to remove the initial open
business (we can essentially compound that into the session-initiate).
Furthermore, we can assume that SASL EXTERNAL is simply not required
here - because it's not, really, for many cases.
Now, the exchange becomes:
--> session-initiate
<-- result
<-> TLS negotiate over IBB-a-like
<-- session-accept
--> result
<-> XMPP stuff overTLS-protected IBB-a-like.
I see this as being one RTT longer than "classic" XTLS - the
session-accept - but in practise I'm not clear that we really need to
wait for that before sending "media" in this case, since both ends
know if it's working at a fundamental level.
However, it does give us a place to indicate why a TLS negotiation
failed, or was rejected, by stating <connectivity-error/>. Moreover,
we can define useful [D]TLS extension reasons which give us the
reason why things failed.
The only thing I see as potentially being problematic then for
implementors is that whilst a Jingle session is active, the session
can potentially be renegotiated - is this something that's a
candidate for being made optional? (Maybe it's really needed for VOIP
applications, but it doesn't seem a requirement for this, or file
transfer.)
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
