[Standards-JIG] Questions regarding XEP-0016
stpeter at jabber.org
Mon Dec 11 17:35:48 UTC 2006
Matthias Wimmer wrote:
> While implementing XEP-0016 in jabberd14 I had the following questions:
> - 2.1 states that storing a privacy list should fail if it contains the
> reference to a roster group, that does not exist. A <item-not-found/>
> error should be returned in that case.
> What should happen if a roster group gets removed after a privacy list
> has been stored? Should the item be kept in the privacy list to get
> active again when the group is added again, or should this item in the
> privacy list get removed if the group is removed from the roster?
Good question. If the list item is retained, then from the user's
perspective the behavior may not be as anticipated, which means the user
must now debug the privacy list (ick). Well, I guess that's true if the
list item is removed, too. If the item is removed by the server then the
server must send a privacy list push to the connected resources, which
at least alerts the user to the change in the privacy list definition.
So that seems like a better solution than retaining the list item. What
do you think?
BTW it seems that the client should be smart here and warn the user that
moving the last roster item out of the roster group will result in a
change to the privacy list definition. (In fact that may occur even if
the roster item is not the last one in the group, so such a warning
would be good in all cases where the privacy list behavior for that
roster item would now change.)
> - Should groups be matched case-sensitive or case-insensitive? (If we
> match insensitive we would have to define a stringprep profile,
> therefore I expect we want to do it case-sensitive.) But still doing it
> case-insensitive would require such a profile to be used, as there are
> characters that can either be composed or be expressed as one unicode
> codepoint. So do we just do a byte-by-byte comparison on group names?
In section 2.4 of rfc3921bis we say the following about roster groups:
[T]he <item/> element MAY contain more than one <group/> element
but the XML character data of each <group/> element MUST specify
distinct groups (where duplicates are to be determined using the
Resourceprep profile of stringprep as defined in XMPP-CORE.
So I think we would use the Resourceprep profile here as well.
> - If an iq stanza is sent to a user's JID without a resource (e.g. a
> request for a vCard), and the user is online with exactly one session.
> Which privacy rule applies? The one of the only active session or the
> default list as the stanza is not sent to this session and has no
> relation to this session? (If we apply the privacy list of the session,
> what happens if the user has two active sessions?)
I think the default list applies.
> - If a user, that has set no special active list and that uses the
> default list, changes the default list, does this change the active list
> for this session as well?
> - 2.8 states that removing a non-existant privacy list should result in
> a <item-not-found/> error. Is this really required? Can't be deleting
> something that does not exist seen as being successful, as it results in
> what the client expects: there is no privacy list with the given name.
I don't have a strong preference between the two.
> - What happens if presence has been sent to an entity and this entity is
> now added to the active privacy list for get presence-out denied? Should
> the server send a <presence type='unavailable'/> before activating the
> privacy list? Else the blocked entity will expect the user to be online
Yes, send unavailable.
> - Same as the last thing for incoming presence: Should the server send a
> <presence type='unavailable'/> to the user that adds a contact to
> privacy list for blocking incoming presences before activating the
> privacy list?
Yes that seems like a good idea (but I don't think it's in 191 or 16
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards