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

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

On Mon, May 23, 2005 at 09:24:39AM -0700, Chris Mullins wrote:
> [Sending Notifications to user at resource]
> > 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.
> Ah. This clarifies things. So the messages sent by the PubSub Server
> MUST NOT use the message routing rules defined by XMPP. 

That's a bit strong. But the routing rules for IM applications (Section
11 of RFC 3921) do not necessarily apply.

> Have the message routing rules for PubSub been explicitly defined
> anywhere? 

It seems not, so we need to define them.

As a first pass, I think a pubsub service MUST send to the subscribed 
JID and not make any assumptions about sending to some other JID, even
what looks like a "bare JID" (node at domain) if the subscribed JID looks
like a "full JID" (node at domain/resource). Naturally other handling rules
make apply given the subscription options (see below).

> Should messages be stored offline if there isn't an exact match? 

Pubsub services don't have a concept of offline storage, they simply
have a concept of notification push (or not). Whether to push to an
offline resource is handled by the pubsub#show-values subscription
option, I think (if you don't think so, then we need to clarify the
definition of that field).

> Should
> messages be send to negative priority users?  

Why not? The concept of negative priority was instituted to ensure that
messages sent to <node at domain> would not be delivered to that negative
resource, but messages sent to <node at domain/negativeresource> would
still be delivered by that node's XMPP server. So I see no reason for a
pubsub service to refrain from pushing notifications to a negative
resource, unless of course there is a subscription option to that

> >> (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...
> The JEP says (as I read it) that I must implement them. 
> JEP 60, 8.1.5: "Subscription requests to a node MUST contain a 'jid'
> attribute, which enables the subscriber to specify either a bare JID or
> a specific resource which should be used as the subscribed Jabber ID.

Well, again, I think it's dangerous to assume an IM context for the JIDs
that subscribe to pubsub nodes, so I would caution against disallowing
"resource-based subscriptions" since the resource identifier of a
subscribing JID is not necessarily an IM resource. 


More information about the Standards mailing list