Re: [Standards] XEP-0047 (IBB streams) and acknowledgment
On Wed, Jun 11, 2008 at 7:54 PM, Justin Karneges [EMAIL PROTECTED] wrote: My plan has always been to use XEP-198 for this. If your server wants you to back off, it'll just not ack back to you over the c2s (or s2s) link. Similarly, a mobile client that is dying would just not ack back to the server. This way you can do flow control per-hop rather than end-to-end. Sorry fo the delay. Yep, agree xep-198 solves the saturation problem of the I/O buffers of clients, which, I think, is most painful for usability. Imho xep-47 should recommend acks with a SHOULD. It just remains open the case when the receiving server has more restrictive policies about IBB than the sending one or the receiving client is too slow, forcing to buffer a large number of packets. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] XEP-0047 (IBB streams) and acknowledgment
On Wed, Jun 11, 2008 at 5:24 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: I don't know if existing clients and servers are that smart, but it They will be if people discover that IBB is so good in passing through firewalls. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
On 06/09/2008 11:09 AM, Peter Saint-Andre wrote: On 06/09/2008 9:50 AM, Dave Cridland wrote: However, I got talking to Rob McQueen - there's a certain amount of sense in, instead of describing this in terms of IBB, describing it in terms of Jingle. It's possible - and reasonable - to consider an XMPP stream as content, in which case the TLS becomes a transport (or possibly attribute of the transport). Part of the idea behind XTLS is that you might want to use the XTLS tunnel for all e2e communications with another party. In particular, you might want to use that tunnel so that you don't expose your IP addresses during a Jingle negotiation (e.g., if you did XTLS over ICE-TCP or SOCKS5). So forcing XTLS to depend on Jingle might defeat the purpose. What transport would be used if we described XTLS in terms of Jingle, and might you expose personally identifying information in that way? I just had a chat with Justin Karneges about XTLS. I'm now convinced that it's best to follow the approach outlined above -- use Jingle to negotiate an e2e stream that is transported via a reliable transport mechanism such as SOCKS5 Bytestreams, IBB, reliable UDP, or whatever else people come up with. I am currently revising the proposal along those lines and will post to the list when I'm finished with the edits. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Peter Saint-Andre wrote: 1. We modify XEP-0174 so it just defines _presence._tcp as a discovery mechanism, as a result of which you have an IP address and port that you can use for a direct TCP connection that functions as a transport for an e2e XML stream. 2. We split the e2e XML streams stuff out from XEP-0174 into a new e2e-streams spec, which defines how you use whatever reliable transport is close to hand (direct TCP connection, IBB, SOCKS5, ice-tcp, etc.) as the transport for an e2e XML stream (this can be unencrypted as all XEP-0174 implementations do now, or upgraded to encrypted using STARTTLS, which is what we'd recommend -- but this way it is backwards-compatible and enables code reuse). It should get a note about clientCert requests. 3. The current XTLS spec morphs into a new Jingle-xmpp spec that defines a Jingle application type for an XMPP session (as defined in XEP-streams), where that application type can use IBB, SOCKS5, ice-tcp, or any other reliable transport. Sounds ok to me. Funny thing is that XTLS gets closer again to my first idea (except that I did not used jingle). If you need some help writing 2. or 3. give me a call. I will be away for the weekend but could help you out on sunday evening (which will be the whole sunday in your timezone). Dirk P.S.: Too bad I implemented the current XTLS today for testing -- [X] -- nail here for new monitor
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
On 06/13/2008 3:12 PM, Dirk Meyer wrote: Peter Saint-Andre wrote: 1. We modify XEP-0174 so it just defines _presence._tcp as a discovery mechanism, as a result of which you have an IP address and port that you can use for a direct TCP connection that functions as a transport for an e2e XML stream. 2. We split the e2e XML streams stuff out from XEP-0174 into a new e2e-streams spec, which defines how you use whatever reliable transport is close to hand (direct TCP connection, IBB, SOCKS5, ice-tcp, etc.) as the transport for an e2e XML stream (this can be unencrypted as all XEP-0174 implementations do now, or upgraded to encrypted using STARTTLS, which is what we'd recommend -- but this way it is backwards-compatible and enables code reuse). It should get a note about clientCert requests. Correct. 3. The current XTLS spec morphs into a new Jingle-xmpp spec that defines a Jingle application type for an XMPP session (as defined in XEP-streams), where that application type can use IBB, SOCKS5, ice-tcp, or any other reliable transport. Sounds ok to me. Funny thing is that XTLS gets closer again to my first idea (except that I did not used jingle). If you need some help writing 2. or 3. give me a call. I will be away for the weekend but could help you out on sunday evening (which will be the whole sunday in your timezone). I hope to finish the work today, but we'll see if I'm successful... P.S.: Too bad I implemented the current XTLS today for testing Ouch. You are too fast. :( If we can get this spec'd out soon, perhaps we'll even be able to hold a bit of an interop event + hackfest at the XMPP Summit July 21 and 22: http://www.xmpp.org/summit/summit5.shtml Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
On 06/13/2008 3:33 PM, Peter Saint-Andre wrote: On 06/13/2008 3:12 PM, Dirk Meyer wrote: Peter Saint-Andre wrote: 1. We modify XEP-0174 so it just defines _presence._tcp as a discovery mechanism, as a result of which you have an IP address and port that you can use for a direct TCP connection that functions as a transport for an e2e XML stream. 2. We split the e2e XML streams stuff out from XEP-0174 into a new e2e-streams spec, which defines how you use whatever reliable transport is close to hand (direct TCP connection, IBB, SOCKS5, ice-tcp, etc.) as the transport for an e2e XML stream (this can be unencrypted as all XEP-0174 implementations do now, or upgraded to encrypted using STARTTLS, which is what we'd recommend -- but this way it is backwards-compatible and enables code reuse). It should get a note about clientCert requests. Correct. 3. The current XTLS spec morphs into a new Jingle-xmpp spec that defines a Jingle application type for an XMPP session (as defined in XEP-streams), where that application type can use IBB, SOCKS5, ice-tcp, or any other reliable transport. Sounds ok to me. Funny thing is that XTLS gets closer again to my first idea (except that I did not used jingle). If you need some help writing 2. or 3. give me a call. I will be away for the weekend but could help you out on sunday evening (which will be the whole sunday in your timezone). I hope to finish the work today, but we'll see if I'm successful... Here is an early version of the Jingle-streams spec: http://www.xmpp.org/extensions/inbox/jingle-streams.html Next I'll copy the e2e-streams stuff from XEP-0174 into a new spec. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
On 06/13/2008 3:45 PM, Peter Saint-Andre wrote: Here is an early version of the Jingle-streams spec: http://www.xmpp.org/extensions/inbox/jingle-streams.html Next I'll copy the e2e-streams stuff from XEP-0174 into a new spec. http://www.xmpp.org/extensions/inbox/e2e-streams.html Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
