[Standards-JIG] JEP-0060: open issues
stpeter at jabber.org
Wed Jun 14 17:27:47 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
In the Jabber Council meeting held this morning , the Council
discussed  the open issues I posted about a few days ago. The
consensus of the Council is provided below...
Peter Saint-Andre wrote:
> In the interest of gaining consensus and moving JEP-0060 along, here is
> a summary of the open issues regarding version 1.8 of JEP-0060. Let me
> know if I've missed anything.
> Oh, and one "meta-issue" is whether to address these open issues in 1.8
> or in 1.9:
> 1. Data Forms
> Get rid of 'access' attribute on <configure/> element?
> Also get rid of 'type' attribute on <create/> element?
> Force use of node configuration data form in both cases or just for
> access model (create 'type' was in 1.7)?
For both -- use data forms rather than these "hardcoded" attributes.
> 2. 'node' attribute for <items/> element
> What should the value of the 'node' attribute be for <items/> elements
> in event notifications received from collection nodes? Specifically,
> should it be the NodeID of the collection node (current policy) or
> sometimes (in the case of transient, notification-only nodes as the
> generator of the notification) the NodeID of the generating node?
The value of the 'node' attribute should be the NodeID of the node that
originated the item. For a leaf node that is obviously the NodeID of the
leaf node. For a collection node that is the NodeID of the node that
generated item (*not* the NodeID of the collection node, even if the
subscriber subscribed to the collection node rather than the originating
> 3. Handling of configuration-required subscriptions
> When a subscription to a node must be configured in order to take
> effect, should we return (1) a success-with-configuration-request
> (current policy) or (2) a <not-acceptable/> error?
> Should we recommend (1) but allow (2)?
As discussed by Ralph on the list, this is mostly an implementation
issue. However, recommending (1) and allowing (2) seems unobjectionable
to me so I will add a note about it (that way, implementations that
can't do (1) will at least know which error to return).
> 4. Subscription retrieval
> Should we define a way to retrieve all subscriptions (with full
> configuration information) in one request?
No. Figure out a different way to do this. :-)
> 5. Ordered nodes
> Should we define a way to enforce order on the items published at a node?
No. The preferred method is to do this in the item itself (with a
mechanism yet to be determined) rather than at the service level, this
will allow for re-use in non-pubsub contexts (e.g., MUC).
> (And also, it seems, to enforce order on the nodes within a collection,
> though what that means is unclear to me.)
> 6. Configuration inheritance
> Should we define a way to enforce inheritance of node configuration options?
No. This can be done by setting smarter service-wide defaults, through
an admin interface, etc.
> 7. Paging through published items
> Should we define a way to set the "start item" for items retrieval?
> And further, should we get rid of 'max_items' attribute and do "paging"
> using JEP-0059?
We will probably recommend use of JEP-0059 in version 1.9 of JEP-0060
for both start_item and max_items, but need to advance JEP-0059 to Draft
first. Expect a Last Call on that soon.
Another issue, raised by Matt Tucker but not discussed in the Council
meeting, is permissions mapping:
If we address that, I think it will be in 1.9. Or naturally it could be
done with a non-standardized configuration field (not everything that
people do with pubsub needs to be standardized in the JEP).
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards