[Standards-JIG] Problem implementing XEP-0191 / Mapping XEP-0191 on XEP-0016

[Peter Saint-Andre]

Matthias Wimmer wrote:

<snip/>

Let's take a step back. We defined privacy lists because we wanted a way 
to perform server-side blocking of evil contacts (stalkers etc.) instead 
of leaving it up to the client. We did not go through the normal JSF 
process (lots of discussion, some experimental implementations to test 
out the functionality, etc.) because we realized that RFC 2779 had a 
requirement that you must be able to block contacts. So we took this 
protocol that was not fully baked and stuck it in RFC 3921. It turned 
out to be more complex than what we needed to meet the relatively simple 
requirement from RFC 2779. While some people found privacy lists of 
interest and maybe even a few developers implemented it, IMHO it is 
still way more complex than regular end users will ever want to deal 
with ("block my outbound presence to this user, block inbound presence 
from that user, allow only messages from another user, etc."). So do we 
really need or want privacy lists? There's all this complexity involved 
in trying to map the two because privacy lists can't be represented 
completly in block lists, the interaction between privacy list and block 
lists across multiple simultaneous sessions is messy, etc. Instead of 
going through the brain damage of trying to work all that out, why not 
deprecate privacy lists and push block lists forward? I think we shied 
away from that origially because we thought that we'd leave privacy 
lists in rfc3921bis, but now we're not doing that so we're in control of 
our own destiny.

If we decide to keep both protocol extensions, then we need to answer 
questions like this:

> I prefere to resolve our problems by adding the following definitions to
> XEP-0016 and XEP-0191:
> 
> - Define what happens, if the (active) privacy list cannot be 100%
> expressed as a blocklist. It may either be, that an error is returned in
> that case (allowing the blocklist client to reset this list by
> unblocking all) - or to return an approximation to the privacy list and
> add a marker to it, that what a server actually uses might be not
> exactly what has been returned. (Modification in XEP-0191)

It seems unfriendly to zero out the default privacy list just because 
most clients know only block lists. That sort of defeats the purpose of 
having both, no?

> - Defining an indication, that a privacy list client accepts list
> changes for active lists as well. (E.g. as a disco feature of the
> client, or an indication a client can pass with his request for the
> privacy lists to the server). This will allow blocklists to be modified
> if all sessions use block-list clients or privacy-list which support
> this feature. (Modification in XEP-0016).

More complexity. Is it *necessary* complexity?

> - Define that blocking/unblocking commands my fail because of conflicts.
> (I.e. there are sessions neither supporting the updated version of
> privacy-lists nor the block-lists.) (Modification in XEP-0191)

Yes, the blocking or unblocking may fail because there's a privacy list 
in place. So what does the blocklist client do in that case? Just wait 
for a superior privacy list client to connect?

We could cut through the Gordian knot here by deprecating privacy lists.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070105/6b200475/smime.bin