[standards-jig] JEP-0016 now includes whitelisting
me at pgmillard.com
Thu Aug 1 16:49:48 UTC 2002
Jean-Louis Seguineau /EXC/TEC wrote:
> First a few comments on the latest JEP-0016
> 1/ In the section Protocol Detail, there is a mention of "To fetch
> the currently active list and the rules for each list, the client
> application performs a simple blank get request."
Check out Example #1: Client requests zebra lists. It shows a blank get
example, and the results from the server. The example that you posted allows
the client to query for JUST the currently active list. I can definitely add
an example for this.
> 2/ The same section mention that "To remove items from the list,
> simply send back the list tag with the various <item> elements
> missing." Does that mean that to be able to include or remove
> somebody in a zebra list we would have to first load the entire list
> then send back the list to the server for it to work out the
> difference ?
Yes, the reason for this is becuase order matters in these rules. If we
don't want to do it this way, we'd have to include an "order" attribute on
every rule, and work out a way of inserting new rules in a specific order.
Think firewall rules, not just a simple blocking system. Do you really think
it would be realistic to have 200+ items in a single zebra list??? This
seems totally unreasable to me. If we're concerned about spammers, it would
make sense that some other form of filtering mechanism like spam-assisin
could be integrated into Jabber. It doesn't seem unreasonable to force thin
clients to "grok" the entire list, manipulate it and send it back again.
[other related stuff munched]
> 3/ Lastly, could we have a use case for "If the <item> element
> contains a subscription attribute, it means that the rule applies to
> all jids in the current users roster which have matching subscription
> elements" ? I humbly admit not seeing what to use it for. Does it
> mean to imply that you can only apply zebra listing to objects in
> your roster ?
The subscription attribute can be used to allow you to filter packets based
on the people in your roster. If this needs more clarification in the JEP, I
can add it.. Here is a stab at it now..
By allowing a rule to be subscription based provides the user to block
people who are not subscribed to his/her presence, who are not on his/her
roster. For example, the following ruleset says to only allow people to send
me packets if I have a subscription TO their presence, or I have a presence
subscription FROM them. This basically boils down to the fact that they are
in my roster, and either I can see their presence, or they can see mine.
Everyone else is blocked.
<iq type="set"><query xmlns="jabber:iq:privacy">
<item subscription="from" type="allow"/>
<item subscription="to" type="allow"/>
> I would finaly like to make further suggestion as to extension to this
> namespace handling. [other stuff munced..]
Sure, this is fine.. I don't see any reason to exclude this from the Future
Considerations section. Using the existing packet structure is great, I'll
More information about the Standards