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 error
slave - fail to join.
- I don't mind the JID\20Escaping stuff for room names, but I
