On Thursday 05 June 2008 2:44 am, Dirk Meyer wrote: > Justin Karneges wrote: > > XTLS as currently documented is not usable, in my opinion, because it > > doesn't treat TLS like a stream. It expects each <iq> exchange to > > contain specific TLS frames, which are not things applications normally > > know about. You'd have to write a TLS parser to inspect data from your > > TLS library, chop them up at TLS frame boundaries, and then wrap them > > correctly into <iq>. You may even have some trouble determining the > > content of the frames you're sending. > > Too bad I read this now that I just updated the xtls document. :( > > So you suggest to handle xtls just like an in-band bytestream with a > tls layer on top of it? So unlike the current document you propose > that every time your tls lib sends something to a socket you put that > into a xmtls iq and send it away? Also for the handshake? I like the > way the handshake is now with all messages in one iq stanza.
The handshake could still have all messages in one iq stanza. It's just that we wouldn't enforce this behavior. If a client sends one <iq> stanza containing a 2000 byte payload, great. If a client sends 2000 <iq> stanzas each containing a one byte payload, .... not so great, but it should be perfectly legal protocol. It's worth noting that regardless of how most TLS libraries operate, the resulting TCP stream is usually optimized. I don't see why our XTLS stream can't be as optimized. I'd bet that in most cases, the stream will end up looking exactly the way XTLS currently describes it. > But you are right, for application data it would be easier to send > what we get from the tls lib used. So one <message> could result in > more than one xtls <iq>. Yes. > It would be cool to negotiate extra stream parameter for IBB. Besides > TLS stream compresion comes to my mind. > > | <iq type='set' > | from='[EMAIL PROTECTED]/orchard' > | to='[EMAIL PROTECTED]/balcony' > | id='inband_1'> > | <open sid='mySID' > | block-size='4096' > | xmlns='http://jabber.org/protocol/ibb'> > | <feature>urn:xmpp:tmp:tls</feature> > | <feature>urn:xmpp:tmp:gzip</feature> > | </open> > | </iq> > | > | <iq type='result' > | from='[EMAIL PROTECTED]/balcony' > | to='[EMAIL PROTECTED]/orchard' > | id='inband_1'> > | <feature>urn:xmpp:tmp:tls</feature> > | </iq> > > In this example Romeo wants tls and gzip compression and Julia answers > with tls (because she can't do compression). Now the implementation > knows to start the tls handshake. XTLS should define (like it does > now) to remove the routing information since we don't need it. This is an interesting idea, but maybe too far-reaching for now. > Or (to make it simpler and not support compression) XTLS could define > that the IBB sid urn:xmpp:tmp:tls means to open an IBB with TLS for > client to client stanza exchange. This is probably good enough. You can still get compression through TLS, too, so it's not so bad. I'm not sure about overloading the sid. A more-traditional namespaced-element approach should work just as well: <iq type='set' from='[EMAIL PROTECTED]/orchard' to='[EMAIL PROTECTED]/balcony' id='inband_1'> <open sid='mySID' block-size='4096' xmlns='http://jabber.org/protocol/ibb'> <xtls xmlns='xtls-ns'/> </open> </iq> -Justin
