[Standards-JIG] JEP 60: Resource Based Subscription problem

Peter Saint-Andre stpeter at jabber.org
Mon May 23 16:09:59 UTC 2005


On Sun, May 22, 2005 at 08:31:28PM -0700, Chris Mullins wrote:
> PubSub subscriptions can be from a particular resource, and this brings
> up a question:
> 
> If user1 has a resource based subscription to a node, but is logged in
> with a different resource, what is the behavior?
> 
> What we have today would be:
> 1 - Publisher published new data to the node
> 2 - Server looks up the subscriptions and finds "user at server/One"
> 3 - Server (following standard XMPP message processing rules) checks to
> see if this resource is online. 
> 4 - The resource is not online, but the user is online with a different
> resource ("Two") that has a positive presence priority.
> 5 - Server sends PubSub notification to user at server/Two.

I don't understand Step 5. What do you mean here by "server" -- the
XMPP user's IM server or the publish-subscribe service? (I prefer the
term "service" for the pubsub service, and I think the JEP is consistent
on this point.) Do you think the JEP says that a pubsub service must
send notifications to <node at domain> rather than the subscribed JID of
<node at domain/resource>, look up a subscriber's presence, etc.? If so, 
why?

Some considerations:

1. We can't assume in the pubsub context that node at domain maps to
user at IMserver and therefore we can't assume that the matching rules
from, say, RFC 3921 apply. The JID <jdev at muc.jabber.org/ChatBot> may
look like a user who is connected to an IM server with a particular
resource, but we happen to know it is not. Lots of different kinds of
entities (bots, services, etc.) might have JIDs that are of the form
<node at domain/resource> and a pubsub service would not be justified in
assuming that they are IM users with available resources.

2. Even an IM user might want to receive pubsub notifications only at a
specialized resource. Let's say I have generalized XMPP daemon running
on my machine and I want all my pubsub notifications to be delivered to
<me at myserver.domain/aggregator> but never to my main IM client. This
seems perfectly reasonable (that's why my daemon subcribed with that 
resource in the first place!), so if the pubsub service assumes that
it's OK to send to <me at myserver.domain> then it has made a serious
mistake, IMHO.

> >From the user perspective, this doesn't seem like what was intended. If
> the user subscribed using a resource, does it make sense for the
> notifications to go to a different place? 

No.

> The case for "user is not online at all" is equally non-obvious. 
> 1 - Publisher published new data to the node
> 2 - Server looks up the subscriptions and finds "user at server/One"
> 3 - Server (following standard XMPP message processing rules) checks to
> see if this resource is online. 
> 4 - The resource is not online, and the user does not have any positive
> priority resources logged in. 
> 5 - Server queues the message for offline delivery.
> 6 - User logs in later with "Two" and has a positive presence priority,
> and gets the delayed notifications. 

Again, does server mean an IM user's IM server, or the pubsub service?

> (I sure wish we could disallow resource based subscriptions.)

We = JSF or we = Coversant? Nothing says you have to implement them in
your own code if you find them extremely distasteful...

/psa




More information about the Standards mailing list