[Standards-JIG] Problem implementing XEP-0191 / Mapping XEP-0191 on XEP-0016
mridul at sun.com
Sun Jan 7 10:03:31 UTC 2007
Peter Saint-Andre wrote:
> 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?
It is more about - if you need to use the extra complexity : do so, else
stick to what you need - just cos privacy list has all that extra
complexity does not mean client has to use all of it.
For example multiple lists - different privacy lists while at work, at
home, on mobile, etc : this is something which is not in blocking list.
Similarly, we use privacy list for invisibility - which does not map
into the current blocking list definition.
> 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?
If client does not know privacy list - the default list is going to be
applicable anyway : so it logically makes sense to modify the default
list for block lists.
What would be interesting is what happens when client supports both and
tries to make blocking list changes after setting non default privacy
list as active, etc.
>> - 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?
How else will blocking lists interop with privacy lists ?
If they are to use the same backend we will need something like this.
Another option is - split both entirely : remove the necessity for
blocking lists to be mapped to privacy lists.
And make blocking list an extra layer to be applied just like roster,
privacy list and other custom server config.
>> - 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.
The amount of functionality not provided by blocking list is not trivial.
Though all functionality of privacy lists are not required as per 2779,
it does allow a lot of serverside filtering : which will otherwise be
pushed to the client for handling.
It could definitely be better (like for example : push list changes when
modified - not just the name, similar to roster), but kicking it out
would not be a good direction imo.
More information about the Standards