[Standards-JIG] UPDATED: JEP-0060 (Publish-Subscribe)

Ralph Meijer jabber.org at ralphm.ik.nu
Thu Jul 8 08:54:10 UTC 2004

On Wed, Jul 07, 2004 at 11:02:29PM -0500, Peter Saint-Andre wrote:
> Version 1.5 of JEP-0060 (Publish-Subscribe) is now available; the 
> changelog is as follows:
>    Fixed typos. Added more details to the section on collections. Added
>    paragraph to create node use case to allow the service to change the
>    requested node-id to something which it creates. Added text about
>    bouncing publish requests when the request does not match the
>    event-type for that node. Added disco features for the jabber
>    registrar. Changed affiliation verbiage to allow publishers to remove
>    any item. Tweaked verbiage for create node, eliminated extra example.
>    Fully defined Jabber Registrar submissions. Corrected schemas. (pgm)

Still parsing the changes, a few notes and questions:

 - Changing the node-id on creation. It would be nice if the reply only
   contains a <create/> if the node has indeed changed (or when an instant
   node is requested). Otherwise, you'd have to compare the result to your
   original request.

 - Event Types. The verbiage 8.1.3 looks ok now, but table 2 (section 5) still
   requires the empty <item/> for the persistent/notification combination.
   This is odd. How can you persist an item, send a notification without
   payload and allow users to collect the payload later using 8.1.10 when you
   don't send the payload?
   I suggest the text in table 2 for the top-left cell to be the same as the
   text in the top-right cell.

   Note: Of course the <item/> may be empty if that's desirable for the
   application in all three cases that require you to send along an item.

 - The disco features are like I imagined them. I hope this clears up some
   of the issues Boyd brought up.
   I see some of the features have abbreviated names (outcast-affil) while
   their non-abbreviated forms would be shorter than the longest feature
   (presence-notifications). Needless to say I am not a fan of abbreviations.

 - About error conditions in general. Do we standardize on the <text/>
   content? For many cases only the error type is mentioned in the verbiage.

 - Good work!



More information about the Standards mailing list