The new version is much improved. Some points are still a bit nebulous, but the general direction is clear. Looking forward to v0.3.
On 5/30/12 11:03 AM, Peter Saint-Andre wrote: > 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
