[standards-jig] JEP-0060 comments

Peter Millard me at pgmillard.com
Thu Jan 2 20:36:46 UTC 2003

Greg Hewgill wrote:
> I've been working on an implementation of the publish-subscribe
> protocol as proposed in JEP-0060. I've got most of an implementation
> working, with the exception of some owner use cases. While working on
> this, I came across many things in JEP-0060 that probably need
> clarification.

Excellent!! Its great to see that someone has started an implementation to
help work these issues out. My comments are inline below. Note that I'm
currently working on the JEP again as things at work have slowed a little
over the holidays, I'm hoping to get this ship-shape soon. If others have
issues/comments please make them!

> - The use of a full JID versus the base JID is unclear. Example 13/14
> shows   sub1 at foo.com/home subscribing to a node, and the server
> replies with   jid="sub1 at foo.com". When items are published to this
> node, do the <message/>   elements go to "sub1 at foo.com" or
> sub1 at foo.com/home?

Yes, this is an issue that I'm trying to address. A few things I'm putting
into the next draft:
* Added a jid attribute to the subscription element when subscribing:
<iq type="set" from="sub1 at foo.com/home" to="pubsub.jabber.org" id="sub1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <subscribe node="generic/pgm-mp3-player" jid="sub1 at foo.com"/>
Note that for iq transactions, the server must send back TO the full jid,
since JSM will not route iq packets which do not have a resource.

* Adding notes relating to the server may choose to validate that the
requesting jid is "allowed" to subscribe on behalf of the requested jid. IE,
I may have another component (proxy.foo.com) which is allowed to subscribe
any JID.. Otherwise, the jid in the <subscribe> element must match the bare
jid in the "from" attribute

> - What are the semantics of item id attributes? Should they be unique
> within a   node? The examples show id="current" being used, but does
> this mean the new   item replaces the existing item with id
> 'current', or does it create a new   items with that id?

I would think the ID's should be unique for a given node. If someone
publishes with the same node, and implementation may over-write the old
item, or give an error?

> - Should entity presence control whether publish notifications are
> sent? This   is mentioned in JEP-0024 section 3.4 (Delivery
> Sensitivity), and seems like a   good idea (as long as it's optional).

This should be an optional configuration piece. I've added this option to
the config example. If an implementation wishes to use presence to base
deliver, then the pubsub component MUST subscribe to that users presence. I
may put an example into the JEP about this, since I'd like to see <x> tags
being used in these subscription requests so that clients can "auto-allow"

> - Should entities be permitted to unsubscribe themselves while still
> in the   Pending state? Table 2 shows that the only way out of the
> Pending state is by   Owner action.

Yes, absolutely, this was an over-sight in the current draft. I will fix up
the state chart. This should work just like normal presence susbcriptions.
If I'm currently pending, then an unsubscribe should make my new affiliation
be none, and remove me from the pending list.

> - There needs to be some way for a node owner to retrieve Pending
> subscribers.   Right now the only thing the owner can do, if a
> subscription request is   missed, is to check the complete node-
> entity affiliation list (example 43)   and look for those in state
> Pending. Even so, there is no way to retrieve the   <thread/> value
> from this.

I've added this to the latest draft. Basically, the node-owner would send
<message from="node-owner" to="pubsub.jabber.org">
    <x xmlns="http://jabber.org/protocol/pubsub#owner"
The component would respond by sending all of the messages again to the

[Stuff about <thread/> munched]
Yes, the <thread> element was old and can safely be removed. I've done so
from the current draft. The subscriber and owner should ge the appropriate
packets back, and have sufficient information to get context. Typically the
<thread> would be used in x-data message exchanges to give the user some
context, but this is not required in this application.

> - If there is more than one entity with an Owner affiliation to a
> node, who   gets the subscription authorization requests. The node
> creator? A designated   approver? All owners?

I think this should be up to the implementation. I need to add some notes
about this. All of these are options, maybe the component subscribes to the
owners presence (but not subscribers) and can send them to all online
owners, etc.. Maybe it round-robins them.. Maybe one of the configuration
options is a "current approver" which is the JID of the person to get these
(they must be an owner).

> - The node discovery (examples 28 and 29) imply that the node
> organization is   hierarchical with the '/' character being the level
> separator. Is this   desired? Clearly it has benefits for discovery,
> but it's not mentioned   elsewhere in the proposal.

This is a possible way to implement it. I'll add some more notes. Currently,
sect 5.1.1 specifies that node identifiers MAY have semantic meaning, but
this needs have further clarification.

> - Example 28 shows a 'name' attribute for nodes, but no other
> discussion of   this node name appears. Should nodes have descriptive
> names in addition to   their unique identifier?

Again, descriptive names could be configured in the x-data form. The example
shows a hierarchial system, and it's possible that the first level nodes are
defined by the sys-admin. This type of stuff will be added to the impl.

> - Examples 3 and 4 contain the original <pubsub/> element in addition
> to the   <error/> element in the response. No other error response
> examples in this   document contain a copy of the original request.
> Is it desireable to echo the   original request back to the sender in
> this case? Why not for the other   example cases?

Echoing the entire packet is not mandatory. Usually this is a by-product of
the implementation just switching the to, from attributes and sending back
an altered form of the original packet. I'm removing the <pubsub> elements
from Example 3 & 4 to be more consistent, but I'll also add a note. I don't
want clients to expect the <pubsub/> element to be there.. they should be
tracking responses on the id attribute of the iq packet itself.

> - There seems to be little useful distinction between the error code
> 401 (Not   Authorized) and 405 (Not Allowed). This could use some
> clarification.

I'm adding a full error code table to the new draft.

> - Examples 11 and 12 have an id= attribute on <message/> elements. I
> understand   that while this is allowed by the Jabber protocol, it
> does not have any   particular meaning and servers should not be
> relied upon to maintain the id=   attribute when passing messages.

Correct, I've removed the id attributes in messages for simplicity. However,
any implementation may add ids when it desires to do so.

> - Example 33 misspells configure as "confgure".

Fixed :)

> - Examples 34 and 38 use the type="get" for delete and purge
> operations. Would   type="set" be more appropriate for these
> destructive operations?

Yes, agreed. New draft will use type="set" for these operations. Most of the
examples were cut-n-paste, I probably didn't even think about sets :)

> - Example 42 describes the error response as the node is not
> *configured* for   persistent items, but the example message says the
> feature is not   *implemented*. Which is it? (Section 3 allows that
> persistent item storage is   an optional feature.)

Some implementations may not allow ANY nodes to have persistent items. (IE,
they have no back-end data store). For these systems 501 is the proper error
msg. Implementations may put other CDATA into the error msg if they want to
distinguish, but from an eitities perspective, it doesn't matter if the node
wasn't configured for persistent storage, or the system doesn't. In both
cases, "Purge" is an error case.

> - Example 45 shows an owner setting the affiliation for a single
> entity. The   DTD allows that more than one entity be specified here.
> How should errors for   some, but not all, of the entity affiliation
> assignments be handled?   According to table 2, some affiliation
> state transitions are not permitted,   in particular revoking Owner
> affiliation in any way other than demotion to   Publisher.

I'm adding more examples and text for these cases.

> There are some other features in JEP-0024 (I mentioned one above,
> "Delivery Sensitivity") that would be useful. In particular, for
> scalability, a way of batching and delivering published items to a
> pubsub component on a remote server would be useful. For example, if
> you had 500 items to publish to entities all at @jabber.org, it would
> be useful to send the item once to pubsub.jabber.org and let it
> handle subsequent delivery to clients.  JEP-0024 describes "Proxy
> Subscriptions" in section 4.2.1. Some consideration should be given
> to this scenario in the proposal.

There are other possible reasons that I may NOT want batching also. For
example, my component may be a load balancer to other pub-sub
implementations, so I want to round-robin packets, I don't want to
pull-apart batches before I do this.

In the baseline specification, I think batching should not be included, as
it can always be layered on top of this or just by using something other
"wrapper" protocol.

Thanx for the exhaustive comments.. I'll be pushing out a new draft once
stpeter arrives back in town and can publish it.


More information about the Standards mailing list