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

Peter Saint-Andre stpeter at jabber.org
Mon Jan 30 22:22:31 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe Hildebrand wrote:
> 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.

See other messages in this thread. That seems fine to me. Does the
phrase "MUST allow subject to local security policies" make sense, or is
SHOULD more appropriate?

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

Yes.

> 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?

I thought about that but shied away from it, since it would require the
"root" node (user's bare JID) to be a collection node, and x:data in a
subscribe-and-configure request is needed in order to subscribe to
collection nodes.

> 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.

Yes, it would be good to make that clear.

> 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.

Yeah, that was the point. :-)

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD3pGnNF1RSzyt3NURApdSAKCpkMKh+GecchNgE9uy4VqAMfIMOACgoEA1
6zgE1m+QlVsSJFU0XBP7/10=
=zhjp
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060130/f6ba85c4/attachment.bin>


More information about the Standards mailing list