[standards-jig] JEP-0060 comments

Greg Hewgill greg at hewgill.com
Mon Dec 30 02:37:30 UTC 2002

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.

These are listed in rough order of importance, so they will jump around the
proposal document a bit.

- 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"?

  (My implementation currently uses the full JID always, but I don't think this
  is correct behaviour.)

- 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?

  (My implementation does not assume uniqueness, and when a specified item id
  is retrieved as in example 26, the single latest published item with the
  given id is returned.)

- 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).

  (My implementation currently always sends notifications to subscribers.)

- 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.

  (My implementation allows subscribers to remove themselves from the Pending

- 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.

- Speaking of <thread/> in authorization requests (example 18), is this even
  necessary? The owner approve/deny (examples 19 and 20) contain enough
  information for the pubsub component to take the appropriate action, even
  without the <thread/> value. The only reason I can think of why the <thread/>
  value might be necessary would be to distinguish between different
  subscription attempts by a given entity. The value of this seems minimal. I
  understand the <thread/> is optional in the <message/> and perhaps it was
  shown only for completeness.

- 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?

  (My implementation currently sends authorization requests to all owners. The
  first one to reply would take effect.)

- 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.

- 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?

- 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?

  (My implementation follows the examples in the proposal and echoes the
  <pubsub/> element back to the sender.)

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

  (My implementation follows the examples in the proposal wrt error numbers.)

- 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.

- Example 33 misspells configure as "confgure".

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

- 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.)

- 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

- Example 45 shows type="result" which I suppose is a typo and should read

I think that's it for right now.

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.

I will post over on jdev at jabber.org more information about my implementation.

Greg Hewgill

More information about the Standards mailing list