Re: [Standards] Multiple binds in XMPP-CORE
Dave Cridland wrote: > On Sun Mar 1 09:45:12 2009, Dirk Meyer wrote: >> I'm thinking of maybe having a proxy in the home network. All local >> devices connect to the proxy and the proxy relays everything to the >> server. In that case the proxy registers all resources from its >> clients >> to the server. Maybe it is a stupid idea, maybe not. > > Okay, so I look forward to your document explaining the security > implications of deliberately introducing a man in the middle. ;-) > > Seriously, what does such an architecture gain you? It was just an idea. But reading all the answers here, I guess I do not need it. So ignore my last mail. :) Dirk -- Warning: Dates in Calendar are closer than they appear.
Re: [Standards] Multiple binds in XMPP-CORE
On Sun Mar 1 09:45:12 2009, Dirk Meyer wrote: I'm thinking of maybe having a proxy in the home network. All local devices connect to the proxy and the proxy relays everything to the server. In that case the proxy registers all resources from its clients to the server. Maybe it is a stupid idea, maybe not. Okay, so I look forward to your document explaining the security implications of deliberately introducing a man in the middle. ;-) Seriously, what does such an architecture gain you? Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Multiple binds in XMPP-CORE
On Sun, Mar 1, 2009 at 10:45 AM, Dirk Meyer wrote: > I'm thinking of maybe having a proxy in the home network. All local > devices connect to the proxy and the proxy relays everything to the > server. In that case the proxy registers all resources from its clients > to the server. Maybe it is a stupid idea, maybe not. Besides the fact that it seems overcomplicated, I'm not sure that for an home network the approach same jid, multiple resources is the correct one. Multiple resources are sometimes confusing and cause problems in message / packet delivery, so I'd avoid any action for extending their use. The only use of resources I'm a fan of is for allowing simultaneous connections of the same user from different devices. In these cases I prefer at least three possible alternate approaches: - trivial, but effective: give a jid to any device (the TV set is not the same thing that your alarm: they have distinct roles and perhaps also authorized users and contact lists) - in you really want to put all together use different nodes for appending commands - use an home server and talk to the world with s2s connections (sooner or later we will have the challenge of handling hundreds of thousands of s2s connection, so let's face it! ;)) bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
Re: [Standards] Multiple binds in XMPP-CORE
Hello , Dirk Meyer wrote: > I'm thinking of maybe having a proxy in the home network. All local > devices connect to the proxy and the proxy relays everything to the > server. In that case the proxy registers all resources from its clients > to the server. Maybe it is a stupid idea, maybe not. The role of the proxy would be to open the needed connection as well. There is no real need to risk adding this overcomplex case in the protocol itself. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Multiple binds in XMPP-CORE
Hello, Fabio Forno wrote: >On Sun, Mar 1, 2009 at 10:39 AM, Dave Cridland wrote: >> This sounds like another reason why multiple binds are just >> overcomplicating the protocol. >> >> Additions like this to core cause unforseen issues like this. >> >> Who wants this, anyway, and why is it going into core? > > I was about to ask the same thing. Same to me. I agree with you two. I think we really do not want multiple resource bind in XMPP. It will become a burden that we will all regret forever. -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Multiple binds in XMPP-CORE
Dave Cridland wrote: > On Sat Feb 28 19:49:51 2009, Justin Karneges wrote: >> Given that you can bind multiple resources in a single XMPP-Core >> session, it >> probably makes more sense to keep the session management before >> binding. If >> you resume a session, then all resources are resumed. This also >> means that >> the session management id has a 1-to-many relationship with full >> JIDs. >> >> > This sounds like another reason why multiple binds are just > overcomplicating the protocol. > > Additions like this to core cause unforseen issues like this. > > Who wants this, anyway, and why is it going into core? /me raises his hand I'm thinking of maybe having a proxy in the home network. All local devices connect to the proxy and the proxy relays everything to the server. In that case the proxy registers all resources from its clients to the server. Maybe it is a stupid idea, maybe not. Dirk -- This signature is temporarily under construction
Re: [Standards] Multiple binds in XMPP-CORE
On Sun, Mar 1, 2009 at 10:39 AM, Dave Cridland wrote: > This sounds like another reason why multiple binds are just overcomplicating > the protocol. > > Additions like this to core cause unforseen issues like this. > > Who wants this, anyway, and why is it going into core? I was about to ask the same thing. -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
[Standards] Multiple binds in XMPP-CORE
On Sat Feb 28 19:49:51 2009, Justin Karneges wrote: Given that you can bind multiple resources in a single XMPP-Core session, it probably makes more sense to keep the session management before binding. If you resume a session, then all resources are resumed. This also means that the session management id has a 1-to-many relationship with full JIDs. This sounds like another reason why multiple binds are just overcomplicating the protocol. Additions like this to core cause unforseen issues like this. Who wants this, anyway, and why is it going into core? Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] XEP-0198 suggestion (Stream management)
On 28-Feb-09, at 11:49 AM, Justin Karneges wrote: On Saturday 28 February 2009 10:59:57 Curtis King wrote: On 28-Feb-09, at 6:10 AM, Mickael Remond wrote: I still think requiring the full JID is the best approach as it maps with how to locate a session in the server when sending a message to a client. I think that an more reasonable requirement would be session management can not be enabled until after a bind and a re-bind could cause a new sm-id to-be issued. This way servers would have all available to them to generate what ever sm-id they want. It actually make more sense to only enable session management after a bind. Given that you can bind multiple resources in a single XMPP-Core session, it probably makes more sense to keep the session management before binding. If you resume a session, then all resources are resumed. This also means that the session management id has a 1-to-many relationship with full JIDs. It still can even when you require the session management after a bind. Besides session management before a bind makes no sense as you aren't saving anything. I don't know if it is written in the XEP this way yet, but the intent is that once you resume the session, you don't have to bind, request the roster, or send initial presence again. The entire state of the session is restored as it was before connection loss. I think that is obvious :-) ck
