[Standards-JIG] Re: UPDATED: JEP-0060 (Publish-Subscribe)
stpeter at jabber.org
Tue Jul 13 20:31:54 UTC 2004
Replying on behalf of pgm -- one Peter is as good as another. ;-)
On Thu, 08 Jul 2004 10:54:10 +0200, Ralph Meijer wrote:
> 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.
So unless there is substantive information in the IQ-result, the service
would return an empty IQ and the requesting entity would track that based
on the stanza 'id', right? That makes sense to me. In fact, I think it's
something of a best practice for Jabber protocol design.
> - Event Types. The verbiage 8.1.3 looks ok now, but table 2 (section 5)
> 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.
Hmm, I don't think that is quite right. It is certainly possible to have
a node that sends pure notifications (a payload is neither sent nor can
it be retrieved after the event), but that persists the events (so that
the history can be reconstructed, say). So it seems better in the top left
cell (persistent notifications) to say that the publish request MUST
contain an <item/> element, which may or may not contain a payload
(depending on the needs of the publisher or nature of the node).
> 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
> - The disco features are like I imagined them. I hope this clears up
> 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
I agree. Any objections to changing '*-affil' to '*-affiliation'?
> - About error conditions in general. Do we standardize on the <text/>
> content? For many cases only the error type is mentioned in the
I think it is best not to rely on textual content (i18n issues etc.).
Better for us to define pubsub-specific error conditions, such as:
<error code="401" type="auth">
More information about the Standards