[Standards-JIG] PEP and Pubsub Questions
stpeter at jabber.org
Wed Apr 5 18:49:34 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Matt Tucker wrote:
> PEP questions:
I'm skipping these for now. I have a bunch of PEP stuff to incorporate
but I'm waiting until JEP-0060 is settled.
> Pubsub questions:
> 1) Should at least one item element be present in the retract element?
When attempting to retract an item, yes. I've added an error case about
that (bad-request + item-required).
Also I changed the error condition in example 90 to be forbidden, since
not-authorized is not consistent with the other examples.
> And if no item is included then return an "item-required" error? The
> schema currently allows 0-unbound items elements.
The schema is correct so that we can handle notification of item
deletion, see the very last example at
> As an aside, what
> about adding a comment to the "7.2 Delete an Item from a Node" saying
> that it's possible to include many items and in that case the
> notification of deletion should include many retract elements.
Hrm. Is it advisable for us to support batch deletion? I think not.
> 2) If a retract element includes many items, but one or more items are
> invalid, should the retract operation be ignored and not delete any of
> the requested items?
See above, I'm not a big fan of batch deletion. I'd prefer to make that
operation atomic. We don't allow batch publishing, why allow batch
deletion? I've provisionally changed the scheme to reflect that.
> 3) Since nodes that don't persist their items may have one cached item
> and that item may have an ID, why is it that "7.2 Delete an Item from a
> Node" defines the following failure reason "The node does not support
> persistent items"? I would expect to return a failure error if the node
> is transient and payloads are not being included in event notifications,
> since nodeIDs are not being used in that case.
> 4) Should we add the failure reason "Request did not specify a node" to
> "7.2 Delete an Item from a Node" and return a "nodeid-required" error?
> Same comment applies to "7.1. Publish an Item to a Node".
> 5) What error should the pubsub service return when a retart element
> contains an item element with no id attribute? Should we create the
> pubsub error "itemid-required" and return that error? It's an edge case,
> but id is an optional item attribute so this case may potentially
> happen. :)
That's another form of "did not specify an item" but I will make that
clear in the error case.
> 6) What error should the pubsub service return when a retract operation
> is attempted on a collection node? Does this case fall into the "The
> node does not support persistent items" or should we use a specific
Yes, that was the idea behind "does not support persistent items".
> 7) Example 94 is including a retract element inside the items element.
> The schema does not define this case.
The namespace is 'http://jabber.org/protocol/pubsub#event' for those
notifications and the schema for that namespace includes the following:
<xs:element name='retract' type='empty'/>
<xs:attribute name='id' type='xs:string' use='optional'/>
> 8) When a subscriber is subscribed to a collection node using
> pubsub#subscription_type of type "items", should the subscriber be
> notified of items being deleted? Currently the JEP only mentions
> notifications of new published items.
That's determined by the nature of the originating node. If the
originating node sends notifications, the collection node should pass
them on through. I've modified the text about collection nodes
accordingly (pass through notifications, whether generated by publishing
an item or deleting an item).
> 9) Should SHIMs (Stanza Headers and Internet Metadata) be included in
> "Example 94. Subscribers are notified of deletion" if the node supports
> multiple subscriptions?
Ah, I think so. We still need to specify when SHIMs are to be included.
I'll look at your previous mail about that and post a separate message.
The CVS diff resulting from the changes described above is:
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