On Wed, Oct 8, 2008 at 12:20 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Fabio Forno wrote:
>
>> (sorry for the delays, but in the last two days of many standards_ml
>> mails went into the spam folder :( )
>
> Hopefully I just put an end to that!
I think the problem comes mainly from the google talk ml, which is
full of spam, and it makes the bayesian filter learn that xmpp or
jabber may be related to spam :(
> So this is interesting. In the resource generation thread, we have
> people trying to fix something that's not broken. In this thread, we
> have people trying to prevent anyone from fixing something that *is*
> broken. Human psychology is endlessly fascinating. :)
The power of diversity ;)
> Privacy lists were unnecessary even in the very beginning to solve the
> problem we thought they needed to solve, which is essentially the
> following points from RFC 2779:
>[...]
> Given that so many developers find privacy lists so confusing (not to
> mention end users!!!), I would very much like to use XEP-0191 and
> XEP-0186 for blocking and invisibility because they are much simpler for
> everyone to grok ("block this user", "go invisible", what could be
> easier?). If people then feel they need privacy lists for some more
> advanced functionality, we have the technology ready to use. But I see
> no good reason to keep hitting these two particular nails with the big
> sledgehammer we created back in 2002 (does anyone here remember "zebra
> lists"?) when much simpler tools can do the job.
I get the point, but what will happen by adopting the "simple"
solutions? A possible scenario:
- for invisibility and blocking the simple xeps are used
- privacy lists will stay (at list I hope, since they are the only way
to do things like temporary going online for only a subset of users,
which is critical on mobiles with rosters getting bigger a bigger and
consequent flood of presence)
- use of privacy lists will remain inconsistent between clients since
they will be used only in the border case explained above, with the
risk of setting a list in a session and messing up everything when
changing client
- developers even more confused of what to use and when, also because
if the hammer is still there without safety instructions somebody will
be tempted to use it instead of the simple solutions (as we where
saying we are all different, and somebody may think "why use the
limited rules when I have a much powerful tool?": the dark side of
force is powerful! ;) )
Ok, we can't stop people from doing stupid things, but at least we
should warn by updating xep-16 better clarifying when to use it. Imho
this
"Note: The protocol specified herein MAY be used in conjunction with
Simple Communications Blocking [1]; see XEP-0191 for details." is not
enough strong, but I'd say that they shouldn't be used in the cases
covered by the simple xeps (I think MUST can't be used because it is
impossible to enforce it)
bye
--
Fabio Forno, Ph.D.
Bluendo srl http://www.bluendo.com
jabber id: [EMAIL PROTECTED]
