[Standards-JIG] proto-JEP: Address lists

Michal vorner Vaner michal.vaner at kdemail.net
Thu Jun 8 07:59:57 UTC 2006


On Thu, Jun 08, 2006 at 09:31:14AM +0200, Philipp Hancke wrote:
> Michal vorner Vaner wrote:
> 
> >And yes, if we are about to build a multicast principle everyone can
> >use, then yes, everyone can misuse. But it is the same with everything.
> 
> opt-in will probably make misuse 'harder' than opt-out or just ignoring 
> any 'spim'.
> 
> >But that is not transparent. That is why it is not used. You would have
> >to modify all the clients to subscribe to MUC messages, to this kind of
> >data, and to that kind of data..
> 
> You don't need explicit subscribes for MUC or groupchat. The server 
> 'knows' that a client has joined a MUC room if there was a bidirectional 
> exchange of directed presence, e.g. romeo sends a directed presence to 
> some address and receives a directed presence from this address.
> At least sending a directed presence somewhere is currently stored on
> your server (5.1.4 #2 of rfc 3921).
> 
Ups. You want the server to read the presences and guess who to allow
and who not to allow? This looks like a stateful firewall. Besides, it
would probably be resource consuming, you loose the ability to use it to
anything you need (which the protoJEP was designed for).

And again, it seems to be a bit of guesswork. I do not like that at all.

Or do I get this wrong?

And again, in some corporation, it may be useful to allow boss to use
multicast to all people in one section, to all secretaries, whatever. I
do not like the idea of disallowing this use.

If there appears some kind of misuse in future, I would prefer some
limits, not presenting the broadcast components to remote people, or
something like this.

> >Well, what channel are you talking about? You have subscription for
> >presence, you enter and leave MUC rooms and so on. We would have to
> >modify it all, make completely new infrastructure.
> 
> You can either modify the current infrastructure (and reuse large parts
> of it) or you can build a new jep-0033 based infrastructure.
> 
Well, here I meant a completely new infrastructure for MUC, for
everything else that may use multicast.

-- 
One semi-random fortune:

Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary.  No such faith comforts the software
engineer.
                -- Fred Brooks

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060608/4210c5de/attachment.sig>


More information about the Standards mailing list