Answering based on the recent update to 289 and the rest of the changes that are pending me having the energy to do another round.
On Wed, Feb 8, 2012 at 2:10 AM, Peter Saint-Andre <[email protected]> wrote: > - from the perspective of a far user, is the mirror room just a standard > MUC room? if not, why not (and exactly how)? Entirely standard. > - do mirror rooms support all the usual MUC features (history, room > administration etc.)? if not, why not? A subset. History will work. Kicks will work in a suitably trusted environment, as will bans. Subjects will be fine. Configuration in general won't cross over nodes - e.g. configuring a history storage of 2 messages on one node and 500 on another means that users joining a node won't be able to request more history than the node is willing to keep. > - in particular, can the mirror room be administered? if not, why not? As above. > - does / can the mirror room retrieve history on joining the source room? Yes. Using the usual MUC history control. > - are there distinct disco identities for source rooms and mirror rooms? Each node exists, as far as addressing and disco are concerned, as an isolated entity, just as if it wasn't federating with another room. > - does the source room config indicate that the room is (can be) mirrored? > - does the mirror room config indicate what the source room is? I've deliberately sidestepped the issue. I suggest these things are a matter of room configuration in the normal manner and not specified formally. > - can mirror rooms themselves be mirrored? (ick) Yes, that's fine (and not particularly ick - you just naturally end up with a tree-like structure that falls out of the wash). > - do / can mirror rooms / services communicate with each other? Only in as much as they talk to the room to which they may be joined, and any rooms that may be joined to them. One could reconfigure the graph to route around networking issues, but it's not automatic. > - does the mirror room wait for presence fan-out from the source room > before sending presence to far users? Only if run in master-slave mode. > - does or should the mirror room include delayed delivery info in the > messages that it sends to far users? I hadn't intended doing so. I can see mileage in it. > - can the source service explicitly request that the mirror service > shall mirror a particular room (as in XEP-0281)? probably not needed, > but good to make it clear No. > - what happens if a near user tries to join a mirror room? is that user > redirected from the mirror room to the source room? No. > - can a far user join the source room directly? can the source room > redirect a far user to the mirror room (as in XEP-0281)? They could - although if this is a constrained network environment 'good luck' to them. No. > - we need to show examples of room joins from far users other than the > first one -- in particular, I would assume that the source room sends > only one presence notification to the mirror room, which is then fanned > out to all of the far users I think I've now covered this. > - can / should the mirror room assume the equivalent of "nomirror" for > the presence of near and far users? that would save quite a bit of bandwidth I've elided master/slave config in the newer version - I need to add it back in. > - I'm not really convinced about nomirror for messages, but I am open to > being convinced Multi-master/peer to peer/whatever (not master/slave) mode costs you consistent message ordering between nodes. Conversely it gains you the ability to work while netsplit and potentially *hugely* reduced latency in communication. I'm led to believe that there are environments where this is important. > - example 2 seems strange, because the 'from' address is the room JID of > the mirror room, not the occupant JID of the far user -- note that in > example 5 the source room seems to know the occupant JID of the far user > in the mirror room, but currently there's no way for it to know that! I've completely rewritten everything, so this may or may not still apply. > - must the far user's roomnick be the same in the source room and the > mirror room? Yes. > - what error would the source room return to the mirror room on join if > the mirroring service is not trusted? (a rogue mirroring service could > simply include the MUC namespace and thus join as a normal occupant, > instead of including the special mirroring extension -- that's something > for the security considerations) I think that a rogue mirroring service doesn't gain anything by doing so - this seems to be a security concern of -45 rather than of -289. I've got an example reserved for the error, but I've not put it in yet. 289v0.3 will have it. > - what error or status notification would the mirror room return to the > far user if s2s is down? would it return any status at all? I'd suggest using PSA for this. > - I don't mind the JID\20Escaping stuff for room names, but I suppose > others might consider it ugly I've removed it and it'll be relegated to a 'you could do this if you really wanted'. > Kev, I'd be happy to work with you on improving XEP-0289. Thanks. /K
