[Standards-JIG] JEP-0060: 1.8pre13

Ralph Meijer jabber.org at ralphm.ik.nu
Wed Apr 12 14:16:44 UTC 2006

On Fri, Apr 07, 2006 at 11:08:13AM -0600, Peter Saint-Andre wrote:
> Hash: SHA1
> Based on the list messages I sent yesterday (barejid attribute, etc.)
> and IM discussions with Gaston Dombiak before he released Wildfire 2.6
> (now with pubsub support), I have upped the rev on JEP-0060 to 1.8pre13:
> http://www.jabber.org/jeps/tmp/jep-0060-1.8.html
> The CVS diff is here:
> http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/jeps/0060/jep-0060.xml?r1=1.110&r2=1.115

I think the change to line 5586, where minOccurs='1' for {..#event}items
is wrong. Using table 5, the case left-bottom (transient/notification)
requires an items element in the notification to carry the node id,
obviously without any items inside.

The text in table 5 for this case is wrong because it refers to the
wrapper in the event, not in the publish action (there is no 'items' in

The change to 'retract' seems ok, though. I don't think retracting using
the same case (transient/notification, so without any items) is useful.
It seems to me that someone using a node configured this way will want
to convey some property changed and send out a notification. I don't
think you can conceptually undo that. But I could be wrong here.

Going on with the same use-case, the 'SHOULD' for including items in publishes
seems wrong. It depends on the node's configuration. It might be useful
to have examples for the 4 different 'modes'.

A note for batch publish and deletion should be added that the action
MUST either succeed for all items /or/ fail for all items.

The note about example 85, concerning multiple namespaces is vague. If I
publish a atom entry, it most probably will contain XHTML inside. So,
the item will have more than one namespaces used. So, I suppose you
wanted to convey that there MUST NOT be more than one child element
of <item/> and leave it at that. Also, such requirements MUST NOT be in

Regarding 'barejid', I think the result of the chat between stpeter and
me [1] is that this will be removed again.

I would have loved to have no such restriction at all, to avoid a new
container element for grouping related data. This has been discussed in
the past, but I couldn't find the discussion in the archives.

[1] http://mailman.jabber.org/pipermail/standards-jig/2006-April/010605.html



More information about the Standards mailing list