[Standards-JIG] JEP-0060: 1.8pre18

Peter Saint-Andre stpeter at jabber.org
Wed Jun 14 14:26:33 UTC 2006

Hash: SHA1

Ralph Meijer wrote:
> On Fri, Jun 09, 2006 at 11:03:59AM -0400, Brian Raymond wrote:
>> In working with hierarchal nodes the idea of permission inheritance seems to
>> make sense as an addition to the spec.
>> Currently when you have a collection node with children all of the node
>> permissions need to be managed independently. If all the nodes belonging to
>> a parent need to be made available to the same users it's much more
>> convenient to manage the permissions of just the top level node and have all
>> of the children inherit those permissions. To accomplish this a
>> configuration option could be added to a node so it can be configured to
>> inherit permissions from the specified node.
>> <field var='pubsub#innherit_perms'
>>          type='test-single'
>>          label='Inherit permissions from specified node'/>
>> A boolean would be easier in this case since it could simply be set to true
>> but that leaves some ambiguity when a node has multiple parents. Maybe two
>> options make sense, one a boolean when there is a single parent and this for
>> nodes with multiple parents?
>> This is flexible enough to work with any nodes but the primary use case is
>> for managing permissions on a group of nodes that allow the same access.
> The way collections are setup currently is that the reference to the
> parent node is held in the configuration of the child node. This works
> great for notification, but not for top-to-bottom stuff like permission
> checking. In the end it is an implementation detail, of course, but I'm
> not sure if such application specific configuration options need to go
> into JEP-0060.

Why not just set up the default node configuration options to be what
you want? And what happens if you move a node from one collection to
another, or a node is associated with multiple collections (each of
which requires inheritance)? Since the need seems to be fairly
specialized, for now I think I'd rather leave these sticky issues up to
implementors. :-)

> Note that section 3.4 of JEP-0068 (Field Standardization for Data Forms)
> describes how custom options (== field names) should be named. The MUST
> always begin with 'x-'. So in your example: 'x-inherit-perms'.


> The use of 'pubsub#' as a prefix is redundant because we always have a
> FORM_TYPE field that indicates JEP-0068 semantics. We should have gotten
> rid of it long ago.
> To Peter: can we still do that?

I agree it's silly, but I see no good reason to change it now.


- --
Peter Saint-Andre
Jabber Software Foundation

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

-------------- 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/20060614/b49f8a15/attachment.bin>

More information about the Standards mailing list