[Standards-JIG] JEP 60: Resource Based Subscription problem
stpeter at jabber.org
Mon May 23 17:39:36 UTC 2005
On Mon, May 23, 2005 at 06:21:00PM +0100, Kevin Smith wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Advanced appologies if this reply efficiently illustrates my complete
> lack of understanding of the topic. I should have referred to the jep
> first and haven't.
> On 23 May 2005, at 17:39, Peter Saint-Andre wrote:
> >>Have the message routing rules for PubSub been explicitly defined
> >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
> >make apply given the subscription options (see below).
> Does this apply in reverse? That a subscription from a node at domain
> shouldn't result in a delivery to an online node at domain/resource? If
> you cannot make assumptions one way, I assume that means you cannot
> make assumptions in reverse. The reason I ask is I'm confused as to
> what would happen, as online-ness is related to a resource, would a
> user ever receive a notification if they subscribe with their bare jid,
> and offline pushes aren't enabled?
Notification != delivery.
The pubsub service pushes out a notification with a particular "to"
address (the subscribed JID). Exactly which JID that finally gets
delivered to is another issue. The pubsub service might push a
notification to <stpeter at jabber.org> because that is the subscribed
JID. But the notification will get delivered to whatever resource my
XMPP server determines is most available, blah blah blah (all of which
is described in delightful detail in RFC 3921 for IM addresses and RFC
3920 for non-IM addresses). It is not the responsibility of a pubsub
service to second-guess or override the core server delivery logic in
any way, other than what is defined in the subscription options for the
subscribed JID. So if the subscribed JID is a <user at domain> and that JID
corresponds to a user of an RFC-3921-compliant IM server, then the
notification will be handled by the user's server in accordance with the
rules in RFC 3921 -- once the pubsub service has pushed out the
notification, it doesn't have to care about what happens to the stanza
after that (unless it receives an error in return, which it should
handle appropriately -- though we probably need to define that more
More information about the Standards