[Standards] comments on XEP-0289

Curtis King cking at mumbo.ca
Wed Feb 8 05:56:58 UTC 2012


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):
> 
> source at home.near.tld (the source room)
> source\40home.near.tld at 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 suppose
> others might consider it ugly

It is ugly :-)

ck





More information about the Standards mailing list