[Standards-JIG] JEP-163 (SPPS) comments

Joe Hildebrand jhildebrand at jabber.com
Sat Jan 28 05:33:35 UTC 2006


Section 5.2,

<blockquote>
0. If the access model is "open", the server MUST allow the entity to  
subscribe.

1. If the access model is "presence", the server MUST verify that the  
full JID of the 'from' address (or the bare JID portion of the full  
JID) has a presence subscription of type "both" or "from" in the  
account owner's roster. If so, the server MUST allow the entity to  
subscribe; if not, the server MUST disallow the subscription request.

2.  If the access model is "roster", the server MUST verify that the  
full JID of the 'from' address (or the bare JID portion of the full  
JID) has a presence subscription of type "both" or "from" in the  
account owner's roster and is in the specified roster group. If so,  
the server MUST allow the entity to subscribe; if not, the server  
MUST disallow the subscription request.
</blockquote>

For all three of these, I think the "MUST allow" should be "SHOULD  
allow", to account for other potential access controls that the  
server may know.  One example might be ethical boundaries enforced by  
a policy engine.

Can a user subscribe to his/her own information?  (assume yes, but  
it's not automatic like rosters)

Is there a way to get notified of new nodes, perhaps by calling the  
bare jid a collection node, and subscribing with subscription type  
nodes?

If that's the case, I assume that I could also subscribe to all of  
the SPPS nodes (to which I had access) by subscribing to the root  
with depth of all.

As for security considerations, the attack modes seem to be based on  
from address spoofing, which we've got handled.  It might be worth  
pointing out that ACL's SHOULD be recalculated whenever an applicable  
roster item is modified, to ensure coherency.

Other than these minor, the more I think about this, the more I like  
it.  It radically simplifies some of the pub/sub apps I've written.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1895 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060127/52aa196c/attachment.bin>


More information about the Standards mailing list