[Standards-JIG] Problem implementing XEP-0191 / Mapping XEP-0191 on XEP-0016
stpeter at jabber.org
Sat Jan 6 04:22:24 UTC 2007
Matthias Wimmer wrote:
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.
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards