Re: [Standards] comments on XEP-0289
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 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
Re: [Standards] comments on XEP-0289
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 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
Re: [Standards] comments on XEP-0289
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 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
Re: [Standards] comments on XEP-0289
On 2012-02-13, at 1:51 PM, Peter Saint-Andre wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2/7/12 10:56 PM, Curtis King wrote: >> >> On 2012-02-07, at 6:10 PM, Peter Saint-Andre wrote: >> >>> At the XMPP Summit, I finally had a chance to chat with Kevin >>> Smith about XEP-0289, and on the plane back from Brussels I've >>> reviewed that spec in more detail. Herewith some feedback, which >>> is terse because I'm running out of battery power and my plane >>> going to land soon. >>> >>> First, I like the XEP-0289 approach and in general I prefer it to >>> what I wrote up in XEP-0281 (especially the more natural use of >>> presence from one room to join the other room, instead of the >>> IQ-ish approach in 281). >>> >>> However, much is left unspecified in XEP-0289 and I have a lot >>> of questions. :) >> >> I have implemented a modified version of 289 which supports both >> master to master and slave to master. I was hoping we would have an >> updated XEP before the summit but that didn't happen. >> >>> >>> First, terminology. I like "MUC mirroring" instead of "federated >>> MUC" (because there's confusion with server federation -- you >>> could argue that our current model already is federated MUC). I >>> would change things as follows (you can figure out particular >>> terminology I use below from the parts of the JIDs): >>> >>> sou...@home.near.tld (the source room) >>> source\40home.near@mirror.far.tld (the mirror room) >> >> I got rid of all jid escaping to avoid any client changes. > > In one sense, I like the JID\20Escaping stuff, because it shows the > relationship between the source room and the mirror room. You can do that without escaping the JID and requiring special client or end user knowledge. The customers we have talked to, say they want zero changes to the clients, client configuration, or what the end user sees. > >>> Questions: >>> >>> - from the perspective of a far user, is the mirror room just a >>> standard MUC room? if not, why not (and exactly how)? >> >> Looks just like a standard MUC room. >> >>> >>> - do mirror rooms support all the usual MUC features (history, >>> room administration etc.)? if not, why not? >> >> All still supported. >> >>> >>> - in particular, can the mirror room be administered? if not, why >>> not? >> >> Yes - there might be some limitations for slaves to have central >> control of kicks, bans, etc. > > Right, that's what I was worried about -- synchronization of room > configurations could get messy (you'll notice that's just the point in > XEP-0281 where I left off...). Yes, this is the area which will require the most thought. > >>> - does / can the mirror room retrieve history on joining the >>> source room? >> >> Yes, a must. > > Well, that might depend on deployment scenarios, no? If this is truly > to be used in highly constrained environments, then history retrieval > might be optional. It's a must that an implementation supports it, it doesn't have to-be used. > >>> - are there distinct disco identities for source rooms and mirror >>> rooms? >> >> yes - but the client wouldn't know it. The goal is to have XEP-289 >> server only as much as possible. > > I think there might be value in knowing that a given room is a mirror. But, if it's never used if it worth adding? A simple as possible server only XEP would be very nice. > >>> - does the source room config indicate that the room is (can be) >>> mirrored? >> >> not currently. >> >>> >>> - does the mirror room config indicate what the source room is? >> >> not currently. > > Again, there might be value here. > >>> - can mirror rooms themselves be mirrored? (ick) >> >> No. A room is either a slave or master. Slaves can not have >> multiple masters nor other slaves. > > Sounds like a good idea. > >>> - do / can mirror rooms / services communicate with each other? >> >> I don't follow the question. > > Let's say that mirror1 and mirror2 lost connectivity to the source > room (perhaps the source server goes offline). There might be value in > allowing those mirror rooms to share their view of the room while the > source room is offline. Then they aren't slaves but masters. See below. > >>> - does the mirror room wait for presence fan-out from the source >>> room before sending presence to far users? >> >> Depends. Masters no, slaves yes. But all mirrors are caching >> presence, history, etc. > > I think you misunderstood my question. I understood the question, but I wasn't clear enough on the design. From customer requirements there are two distinct operational modes they want. 1) Bandwidth reduction with the current model of central administration of the room, and always the same order of messages for all users. - Really just want bandwidth reduction. - MUC's same order of messages is seen as a big XMPP advantage. - Ok, with if the master room goes down then mirrors are also offline. The idea being the master room would be
Re: [Standards] comments on XEP-0289
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/7/12 10:56 PM, Curtis King wrote: > > On 2012-02-07, at 6:10 PM, Peter Saint-Andre wrote: > >> At the XMPP Summit, I finally had a chance to chat with Kevin >> Smith about XEP-0289, and on the plane back from Brussels I've >> reviewed that spec in more detail. Herewith some feedback, which >> is terse because I'm running out of battery power and my plane >> going to land soon. >> >> First, I like the XEP-0289 approach and in general I prefer it to >> what I wrote up in XEP-0281 (especially the more natural use of >> presence from one room to join the other room, instead of the >> IQ-ish approach in 281). >> >> However, much is left unspecified in XEP-0289 and I have a lot >> of questions. :) > > I have implemented a modified version of 289 which supports both > master to master and slave to master. I was hoping we would have an > updated XEP before the summit but that didn't happen. > >> >> First, terminology. I like "MUC mirroring" instead of "federated >> MUC" (because there's confusion with server federation -- you >> could argue that our current model already is federated MUC). I >> would change things as follows (you can figure out particular >> terminology I use below from the parts of the JIDs): >> >> sou...@home.near.tld (the source room) >> source\40home.near@mirror.far.tld (the mirror room) > > I got rid of all jid escaping to avoid any client changes. In one sense, I like the JID\20Escaping stuff, because it shows the relationship between the source room and the mirror room. >> Questions: >> >> - from the perspective of a far user, is the mirror room just a >> standard MUC room? if not, why not (and exactly how)? > > Looks just like a standard MUC room. > >> >> - do mirror rooms support all the usual MUC features (history, >> room administration etc.)? if not, why not? > > All still supported. > >> >> - in particular, can the mirror room be administered? if not, why >> not? > > Yes - there might be some limitations for slaves to have central > control of kicks, bans, etc. Right, that's what I was worried about -- synchronization of room configurations could get messy (you'll notice that's just the point in XEP-0281 where I left off...). >> - does / can the mirror room retrieve history on joining the >> source room? > > Yes, a must. Well, that might depend on deployment scenarios, no? If this is truly to be used in highly constrained environments, then history retrieval might be optional. >> - are there distinct disco identities for source rooms and mirror >> rooms? > > yes - but the client wouldn't know it. The goal is to have XEP-289 > server only as much as possible. I think there might be value in knowing that a given room is a mirror. >> - does the source room config indicate that the room is (can be) >> mirrored? > > not currently. > >> >> - does the mirror room config indicate what the source room is? > > not currently. Again, there might be value here. >> - can mirror rooms themselves be mirrored? (ick) > > No. A room is either a slave or master. Slaves can not have > multiple masters nor other slaves. Sounds like a good idea. >> - do / can mirror rooms / services communicate with each other? > > I don't follow the question. Let's say that mirror1 and mirror2 lost connectivity to the source room (perhaps the source server goes offline). There might be value in allowing those mirror rooms to share their view of the room while the source room is offline. >> - does the mirror room wait for presence fan-out from the source >> room before sending presence to far users? > > Depends. Masters no, slaves yes. But all mirrors are caching > presence, history, etc. I think you misunderstood my question. Far user joins mirror room. Mirror sends presence update to source room. Does mirror room wait to send that user's presence to everyone in the mirror room (pending receipt of presence from the source room)? >> - does or should the mirror room include delayed delivery info in >> the messages that it sends to far users? > > No, it behaves as a normal MUC room. I'll have to think about that some more. >> - 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 >> >> - what happens if a near user tries to join a mirror room? is >> that user redirected from the mirror room to the source room? > > How would you know where the user is? So, no. You would know based on the domainpart of the joining user's full JID. > The updated xep will make this clearer. Great. >> - can a far user join the source room directly? > > Sure, why not? Because, based on policy, the mirror might want all of the users in its administrative domain to join the mirror instead of the source. >> can the source room redirect a far user to the mirror room (as in >> XEP-0281)? > > No. Here again, policy might dictate
Re: [Standards] comments on XEP-0289
On 2012-02-07, at 6:10 PM, Peter Saint-Andre wrote: > At the XMPP Summit, I finally had a chance to chat with Kevin Smith > about XEP-0289, and on the plane back from Brussels I've reviewed that > spec in more detail. Herewith some feedback, which is terse because I'm > running out of battery power and my plane going to land soon. > > First, I like the XEP-0289 approach and in general I prefer it to what I > wrote up in XEP-0281 (especially the more natural use of presence from > one room to join the other room, instead of the IQ-ish approach in 281). > > However, much is left unspecified in XEP-0289 and I have a lot of > questions. :) I have implemented a modified version of 289 which supports both master to master and slave to master. I was hoping we would have an updated XEP before the summit but that didn't happen. > > First, terminology. I like "MUC mirroring" instead of "federated MUC" > (because there's confusion with server federation -- you could argue > that our current model already is federated MUC). > I would change things > as follows (you can figure out particular terminology I use below from > the parts of the JIDs): > > sou...@home.near.tld (the source room) > source\40home.near@mirror.far.tld (the mirror room) I got rid of all jid escaping to avoid any client changes. > > Questions: > > - from the perspective of a far user, is the mirror room just a standard > MUC room? if not, why not (and exactly how)? Looks just like a standard MUC room. > > - do mirror rooms support all the usual MUC features (history, room > administration etc.)? if not, why not? All still supported. > > - in particular, can the mirror room be administered? if not, why not? Yes - there might be some limitations for slaves to have central control of kicks, bans, etc. > > - does / can the mirror room retrieve history on joining the source room? Yes, a must. > > - are there distinct disco identities for source rooms and mirror rooms? yes - but the client wouldn't know it. The goal is to have XEP-289 server only as much as possible. > > - does the source room config indicate that the room is (can be) mirrored? not currently. > > - does the mirror room config indicate what the source room is? not currently. > > - can mirror rooms themselves be mirrored? (ick) No. A room is either a slave or master. Slaves can not have multiple masters nor other slaves. > > - do / can mirror rooms / services communicate with each other? I don't follow the question. > > - does the mirror room wait for presence fan-out from the source room > before sending presence to far users? Depends. Masters no, slaves yes. But all mirrors are caching presence, history, etc. > > - does or should the mirror room include delayed delivery info in the > messages that it sends to far users? No, it behaves as a normal MUC room. > > - 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 > > - what happens if a near user tries to join a mirror room? is that user > redirected from the mirror room to the source room? How would you know where the user is? So, no. The updated xep will make this clearer. > > - can a far user join the source room directly? Sure, why not? > can the source room > redirect a far user to the mirror room (as in XEP-0281)? 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 > > - 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'm not really convinced about nomirror for messages, but I am open to > being convinced > > - 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! > > - must the far user's roomnick be the same in the source room and the > mirror room? > > - 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) There should be protocol to mirror rooms to set roles, master or slave. A master could decline a mirror request. This is when existing presence and history would be exchanged the two rooms. > > - 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? master - no er
[Standards] comments on XEP-0289
At the XMPP Summit, I finally had a chance to chat with Kevin Smith about XEP-0289, and on the plane back from Brussels I've reviewed that spec in more detail. Herewith some feedback, which is terse because I'm running out of battery power and my plane going to land soon. First, I like the XEP-0289 approach and in general I prefer it to what I wrote up in XEP-0281 (especially the more natural use of presence from one room to join the other room, instead of the IQ-ish approach in 281). However, much is left unspecified in XEP-0289 and I have a lot of questions. :) First, terminology. I like "MUC mirroring" instead of "federated MUC" (because there's confusion with server federation -- you could argue that our current model already is federated MUC). I would change things as follows (you can figure out particular terminology I use below from the parts of the JIDs): sou...@home.near.tld (the source room) source\40home.near@mirror.far.tld (the mirror room) Questions: - from the perspective of a far user, is the mirror room just a standard MUC room? if not, why not (and exactly how)? - do mirror rooms support all the usual MUC features (history, room administration etc.)? if not, why not? - in particular, can the mirror room be administered? if not, why not? - does / can the mirror room retrieve history on joining the source room? - are there distinct disco identities for source rooms and mirror rooms? - does the source room config indicate that the room is (can be) mirrored? - does the mirror room config indicate what the source room is? - can mirror rooms themselves be mirrored? (ick) - do / can mirror rooms / services communicate with each other? - does the mirror room wait for presence fan-out from the source room before sending presence to far users? - does or should the mirror room include delayed delivery info in the messages that it sends to far users? - 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 - what happens if a near user tries to join a mirror room? is that user redirected from the mirror room to the source room? - 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)? - 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 - 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'm not really convinced about nomirror for messages, but I am open to being convinced - 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! - must the far user's roomnick be the same in the source room and the mirror room? - 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) - 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 don't mind the JID\20Escaping stuff for room names, but I suppose others might consider it ugly Kev, I'd be happy to work with you on improving XEP-0289. Peter -- Peter Saint-Andre https://stpeter.im/
