[Standards-JIG] JEP-0060 PubSub support for disco#info (service, topic, and subscription)
jabber.org at ralphm.ik.nu
Thu Jul 1 13:49:11 UTC 2004
On Wed, Jun 16, 2004 at 11:37:36PM -0400, Bob Wyman wrote:
> Assuming that something like the proposed changes that I described in
> yesterday's mail are accepted, we need to flesh out disco support for the
> pubsub service itself as well as for the two kinds of nodes that are
> supported. (I.e. topic and subscription) Your comments on the following
> would be very welcome.
> First, we should support a disco#info request that returns information about
> our server. (Support for this request is mentioned, but not shown, in the
> current draft of JEP-0060...)
> Example 1: Client Requests Info on the service
> <iq type='get'
> from='bobwyman_at_pubsub_dot_com at pubsub.com'
> <query xmlns='http://jabber.org/protocol/disco#info'/>
> Example 2: Server returns requested info
> <iq type='result'
> to='bobwyman_at_pubsub_dot_com at pubsub.com'
> <query xmlns='http://jabber.org/protocol/disco#info'>
> name='PubSub Concepts PubSub Server'/>
> <feature var='http://jabber.org/protocol/disco#info'/>
> <feature var='http://jabber.org/protocol/disco#items'/>
> <feature var='http://jabber.org/protocol/pubsub/'>
> * Is the feature list correct for a server that *only* supports JEP-0060?
Well, I contacted pgmillard on this, and returning pubsub/generic would mean
the entity supports the following basic MUSTs from JEP-0060.
- A Jabber entity MUST be able to publish events to a service such that all
subscribers receive notification of the event.
- Entities MUST be allowed to be affiliated with a node. Allowable
affiliations are owner, publisher, none, and outcast. Implementations
MUST support affiliations of owner and none, and MAY support affiliations
of outcast and publisher.
- Pubsub services MUST respond to feature queries using the Service
Discovery protocol and scoped by the
http://jabber.org/protocol/disco#info namespace. The result to a
disco#info MUST indicate support for the features by using a feature
element with the appropriate var attribute.
So, for the minimal implementation of a pubsub service, nodes magically exist
and there are entities magically affiliated with it. You can publish to nodes
and magically subscribed subscribers get notifications as a result. Last, but
not least, the service must support disco#info.
So I think the last <feature/> in your example can go, unless you would want
to be able to later define other non-JEP-0060 pubsub services and have them
fall under pubsub/generic.
The disco#items support would only be returned if you can indeed disco
the nodes. So in the minimal case, this can go as well.
Also, I am puzzled by the text in JEP-0030. MUST an entity always report
back disco#info as a feature? I notice that some of the examples in JEP-0030
don't do this, and many implementations don't return it. IMHO, it is also a bit
redundant that it returns that it supports disco#info in the result of a
On the rest of the optional features, we should probably define the matching
feature vars, like pubsub#subscribe, pubsub#create, etc. Or something
to that effect.
More information about the Standards