On Jan 9, 2012, at 09:06, Wayne Franklin wrote: > Matthew, > > Sorry to hear that you didn't see the advantages to our approach. We respect > the decision of the council and will provide feedback to XEP-0289. Does this > mean that the other DMUC specs are out of the running? >
I personally don't have a comment regarding the other DMUC specs right now. > The biggest problem with XEP-0289 is that it does not seem to address the > requirement for having the room be able to live on if the S2S link is > disconnected. Our customer would like a 100 user chat room with 50 users on > one login server and 50 users on another login server to be able to continue > on as two 50 person chat rooms if the S2S link goes down (which is common for > their network). > > Additionally, it seems as if the user needs to know that they want to connect > to a new mirror service rather than the actual chat room. This seems as if > it will be a training issue for our users. > > Unless I mis-understand, it seems as if the client will need to know that it > is talking to this new mirror service (and not a real MUC room) so that it > can construct this escaped JID. Personally, I would rather make a change at > the server that did not require the client to create a new kind of JID. > > As I said, we will respect the decision of the council and provide feedback > to XEP-0289, but if we can't satisfy the requirement for continued operation > while S2S is down, we may have to go our own way. > XEP-0289 is still EXPERIMENTAL, and so could (in theory) be influenced by such criteria. I would strongly recommend you work with the author(s) of XEP-0289 to see if an agreement or compromise can be reached. - m&m <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
