[Standards] Fwd: Meeting minutes 2010-02-15

Philipp Hancke fippo at goodadvice.pages.de
Mon Feb 22 19:48:24 UTC 2010


Dave Cridland wrote:
[...]

>> In http://mail.jabber.org/pipermail/muc/2010-February/000144.html you say
>>  "Another distinction between the two approaches is what the core aims
>>   are - in PSA-style, it's to provide resilience between servers,
>>   whereas in KD-style, it's largely to reduce redundant message traffic
>>   from being repeated redundantly repeated."
>>
>> So you changed your mind already and think reducing redundant redundancy
>> is no longer worth revisiting?
>>
>>
> Not for presence as a whole, no. For chatrooms, I think it's worth 
> looking at, especially if we can gain some levels of resilience out of 
> it as well. Sorry, but by trying to combine two arguments, you are 
> muddying the waters and confusing two cases which I don't think are the 
> same.
> Let me also clarify - if we could send IM presence once over a link and 
> have fan-out controlled by a foreign domain, I'd be happy with it. But I 
> don't think that's a practical option, given that it requires greater 
> trust between domains, and prevents various other forms of control.

No. IIRC this is explained in detail in draft-ietf-simple-view-sharing-02

It does require a quite challenging protocol for subgroup managment.
But this is no different from MUC actually.

[...]
>> No doubt. But those properties also mean that the traffic pattern is
>> similar to a SPIM or flood attack, making those undistinguishable.
>>
>>
> Okay, I can go along with this, but I also suspect it's again much more 
> of an issue with chatroom (and PubSub) traffic than it is with general 
> presence (and PEP), which in general terms has an established 
> relationship involved as well. Luckily, this is very similar division to 
> the trust issue - fan-out of chatrooms and pubsub nodes is, I think a 
> lot more likely to be practical without any changes to the trust model 
> we have.

Getting experience with that and postpone presence is fine with me.

>>> 4) I understand this proposal is aimed at bringing simple resilience 
>>> for chatrooms across heterogeneous XMPP networks, very much like IRC. 
>>> I'd be interested in seeing how you'd do it. I do think you're much 
>>> better
>>
>> lynX will post to muc@ about that.
>>
>>> placed to find a reasonable solution, and in this case, where trust
>>
>> Unfortunately, there is no single "reasonable solution".  The only
>> common pattern is "at most once per link".
>>
>>
> I don't think that's the only goal. I think shared state to provide 
> resilience is useful and important too, but I think we can require a 
> formalized trust relationship there.

Resilence makes sense for some use-cases, but there are some security
implications - such as people forcing your slave room to go to "split
mode" and then harassing users.

>>> relationships are explicitly configured, I'd expect the kinds of 
>>> solutions you're likely to propose to be more acceptable to us 
>>> annoying folk in the XMPP world.
>>
>> Beware, I still consider sending stanzas without a 'to' attribute the
>> most elegant approach ;-)
> 
> Sure, from some perspectives. I just think that thanks to various other 
> features of the architecture, doing this blindly will lead to problems.

Of course. Doing that is nearly impossible when there is more than one
domain pair per s2s link.

> But I'm pretty sure you understand my perspective on this - you pointed 
> out in private IM that "the moderator which uses a slave needs different 
> information from the master than the average user" - things like jid 
> disclosure, etc, may indeed mean that a simple master/slave isn't 
> suitable for all cases, and we'll need to consider that carefully.

That was actually just one of many examples why distributed MUC is every
bit as painful as presence.

philipp



More information about the Standards mailing list