[Standards-JIG] JEP-0060 Feedback and questions.

Ralph Meijer jabber.org at ralphm.ik.nu
Thu May 25 14:13:19 UTC 2006

On Thu, May 25, 2006 at 12:45:18AM -0400, Brian Raymond wrote:
> 1. Section 9.2: If an entity is subscribed to a collection node with type
> "items" and the server can return payload with a subscription notification
> can the server deliver the payload? The JEP states that the item if MUST be
> identified in the response however it isn't clear weather or not the payload
> can be returned as well.

I cannot really parse your question here. Are you referring to example
199 in section 9.6? (I'm referring to the 1.8pre17)

But since I'm reading this anyway: Peter, I haven't looked at this
before but it seems to me that this is wrong. If you have node that is
configured to be transient and notification only, there would be no
<item/> element in the notifications. How would this work with
collections now?

The are two possible choices for the node attribute on the <items/>
element in a notification from a collection.

 1) The original node to which the item was published.
 2) The node to which the receiver was subscribed.

Option #2 seems problematic, because you cannot use the item ids to
retrieve the item later (you have no idea which node it came from).

Option #1 has the problem that the receiver cannot immediately see which
subscription yielded that notification. For the subscription ID
use-case, example 83 shows how to use SHIM to send along the subids that
yielded the notification. We could add a similar header for collection


> 2. Section 6.4: An entity may retrieve all items associated with a node by
> requesting the node with no qualifiers. The following might be in the spec
> but I might have overlooked it, however what is the behavior if that request
> is made against a collection node?

Collection nodes do not support item retrieval as they can never persist
items themselves. The prose above example 66 makes mention of this, but
maybe we should make this more explicit in section 9. In any case, the
result should be as in example 66.

> 3. I thought I previously verified that an entity can request the entire
> subtree, including all items (with payload) and nodes from a collection node
> however I can't locate any information on that now, is this possible?

A disco#items on a collection node yields the nodes it contains.
A disco#items on a leaf       node yields the items it contains.

The latter excludes the payload. That may be retrieved using the regular
item retrieval protocol.

You could recursively do a disco#items on the comprising collection node
and all subsequent collection nodes that are contained within, to find
all leaf nodes. Subsequently you can do the item retrieval to get all
items plus payloads.

As for the reference to 'tree' I want to note again that although the
structure of a collection node and its contained nodes is a directed
graph without cycles. For example, you can have this stucture:

     / \
    B   C
     \ /

Where D is a leaf node and A, B, C are all collections. Surely, a
subscriber of A should only get 1 notification if an item is published
to D.



More information about the Standards mailing list