On 06/05/2008 9:17 AM, Justin Karneges wrote: > 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>
It seems that Justin and I are in agreement. :) Dirk, since you are working on this, perhaps you could send me an updated XML file and I could check it / clean it up a bit for XSF conformance / style issues? Then we can ping the XMPP Council about approving this as a real XEP so that we can have it in source control etc. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
