[standards-jig] Publish/Subscribe, merge of JEPs 0021 and 0024
rob at cataclysm.cx
Fri May 24 00:18:24 UTC 2002
First, note that I'm note happy with JEP-0021 in its current
incarnation. I wrote it in an attempt to get something out there for
discussion, (a role which it filled wonderfully, judging by the size of
the thread that followed :P ).
Since then, however, I've learnt quite a bit about pub/sub, and I'm not
sure that the ENS is the best solution for Jabber, even though it is an
excellent choice for certain applications (pure event-based systems).
Still, I've added some clarifications about JEP-0021 below, as needed:
> The fact that JEP-0021 uses JIDs for qualifying the events being published
> (and expects the publisher to publish these events from that JID) divides the
> information so that it is to be found in several places: somewhere in the
> origination JID (user part, hostname (sub-)part and resource) and in the
> optional payload of the notification. Also, when using a simple JSM client as
> publisher, you are limited somewhat in using those places for putting
> information. Furthermore, you'd have to add a namespace declaration on
> possible payload to adhere to the XML standard. This means that when you want
> to send information in the payload of the notification you have somewhat
> redundant data (information is never redundant): the qualification of the
> event and the namespace(s) of the payload.
The payload is optional, so the only way to know for sure which event is
being published is from the JID (attached to the <publish/> tag). Also,
the payload can, in theory, be completely unrelated to the published
event, so long as the subscriber knows what to do with it. Of course, it
would be qualified by a namespace declaration.
JEP-0021 publishers don't publish data, not exactly. They inform the ENS
(and thus the subscribers) that a certain event has occured. There may
be data associated with the event, but there doesn't have to be.
> In JEP-0024 one entity can publish information with different qualifications.
> These qualifications are in one place (the namespace) and all data is in
> the payload. By whom the information has been published is clearly separated
> from the qualification by use of a 'from' attribute to the <publish/>
Because of the seperation of the event and the payload in JEP-0021, its not
appropriate to qualify the event within the namespace.
> <auth-info/> is for authorising subscriptions. The example given is not
> correct as far as I can tell, but that is besides the point. The idea is that
> you can send some credentials along with the subscription to be allowed to
> subscribe to a certain event. JEP-0024 lacks this unfortunately. We should
> think about how to do this, because you could possibly need to communicate
> with the publisher(s) about the authorisation.
This should tie in with the recent working being done on authentication
and authorisation (ie my AAF work, and the SASL work being discussed by
the jabberd 1.5 group).
> As response to a succesful subscription you get back the <subscribed/>
> element. An unsuccesful subscription returns a <subscribe> element. My opinion
> here is that it is not really useful to define a different element for this
> and that a <subscribe/> would do just fine in both cases.
Actually, you need both. Since they both come from the ENS, there's no
way for the receiving entity to know whether the <subscribe/> element is
in response to the request I just sent out, or if the other entity is
trying to subscribe to me. In the case where the entity is both a
publisher and a subscriber, this could be problematic.
> <reliable/> is to 'ensure' that all subscribers get the notification
> eventually (by resending it upon failure). JEP-0024 also lacks this, but I
> think QoS is outside of the scope of pubsub and should be solved in the jabber
I tend to agree. See JEP-0021, section 6.2.
> Both JEPs use <iq/>s to publish information. I have been playing a bit with
> a pre-JEP-0024 pubsub implementation by DJ and have noticed the following
> about routing of <iq/> packets. First, if a <iq/> is sent with a 'from'
> attribute that has no resource part, the JSM rewrites this to a JID with
> the resource part of your current connection added. This makes it unpossible
> to subscribe without supplying a resource, although JEP-0024 suggests it is.
A non-JSM-based subscriber could, presumably, subscribe without a
resource, if it desires.
Thank you for your thoughts on this, Ralph.
Robert Norris GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards