[standards-jig] Publish/Subscribe, merge of JEPs 0021 and 0024

Ralph Meijer jabber.org at ralphm.ik.nu
Sat May 25 16:01:36 UTC 2002


Hi all!

On Fri, May 24, 2002 at 10:18:24AM +1000, Robert Norris wrote:
> Ralph, all,
> 
> 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 ).

Hehe, yes. Authors tend to be that way ;-)

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

I am not sure which, if any, is the best. Just like you I think we
should have more discussion on this, if only to get at least one
of the two approved. My reasons for writing this piece was to possibly
get some concensus and fill in possibly missing stuff.

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

Hmm, yes. Well, in theory, completely unrelated payload could be carried
by JEP-0024, too. You could give the elements inside the <publish/>
element other namespace declarations. So I see now that the two JEPs are
not that different at this point.

> > 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/>
> > element.
> 
> Because of the seperation of the event and the payload in JEP-0021, its not
> appropriate to qualify the event within the namespace.

Hmm, as I said, this is possible in JEP-0024 as well. Maybe it's that I'd
like to separate the qualification and the actual publisher. For example,
when you want to send an avatar, in JEP-0021 you'd have to send it with
always the same resource part in the JID, whereas in JEP-0024 you could send
it without specifing any 'from' attribute at all and the pubsub component
would still know (by the namespace qualifier) what kind of event we are
dealing with.

Where an event or published item comes from doesn't have to be relevant
IMHO, but you always need a qualifier, and separation of the two seems
reasonable, then.

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

I am not familiar with this work, so a pointer to that information would
be great. In any case, I shortly talked with DJ if it were possible for
embedding something like a hypothetical <x xmlns='jabber:x:auth'/> inside
the <subscribe/> element, but his initial answer was 'no', and we agreed
we should let that discussion take place here in stead of privately.

And not only authentication is relevant here. I think there are more
things imaginable that you could send along with <subscribe/> element.
One thing that comes to mind is the possibility to say: I am interested in
this information between 09:00h and 17:00h. I'm sure there are plenty
others. How do I convey this to the pubsub component? As I see it, such
information would be directly tied to the subscription, but I don't know
whether it actually belongs in the jabber:iq:pubsub namespace.

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

I might be wrong here, but I would say that they ARE distinguishable because
of the 'type' attribute. When you mean: that subscription is ok, you have
a <iq type='result'/>, when you get a subscription request you have a
<iq type='set'/>.

> > <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
> > core.
> 
> I tend to agree. See JEP-0021, section 6.2.

I read that, of course, but wanted to state my opinion on this point.

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

Yes, that would be no problem. A component has more freedom in this.

On the subject of using <iq/>s and the longevity of subscriptions, my attention
was drawn to the last sentence in section 3.5 of JEP-0021 that states:

  "If the subscriber responds to the notification with an error, the subscriber
  will be automatically unsubscribed from the event by the ENS."

Such an error response also occurs when a <iq type='set'/> is sent to a
non-connected subscriber. This effectively means that a not so frequently
connected subscriber will probably get unsubscribed very soon.

> Thank you for your thoughts on this, Ralph.

No problem, I hope that more people chime in on this.

> Rob.

Ralphm



More information about the Standards mailing list