Hi Kev, many thanks for updating XEP-0289. I'll need to take some time to review it completely, and will reply after I've done that.
On 5/30/12 6:42 AM, Kevin Smith wrote: > 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 <stpe...@stpeter.im> 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
