[standards-jig] JEP-0060 comments
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
(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
(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.
More information about the Standards