On Thu, 2010-01-28 at 02:17 -0800, Liam wrote: > Perhaps I'm missing something here... > > That presence-based delivery is an optional service feature implies > that items published are normally queued to node subscribers when they > are offline, and later delivered when they sign on. However I can't > find this explicitly stated in the spec.
In general the publish-subscribe specification is based on XMPP Core only, with certain — optional — features having addition requirements like XMPP IM and/or presence. This means that the default case is that a pubsub service sends notifications as messages to the subscribed JID whenever a new or item becomes available. For IM accounts, the perceived behavior is as follows: If the subscribed JID is the bare JID of the account, the receiving server makes an educated guess to which resource the message should be send. The mechanics of this are described in XMPP IM, and are implementation dependent. Examples include looking at presence and priority, but Google Talk will happily send it to all of your resources. If there is no available resource, the notification might be kept in offline storage for later delivery. However, there is no requirement to implement this behavior in servers. If the subscribed JID is a full JID, and the JID is available, the receiving server will deliver it directly to the resource (regardless of priority). If it is not available, then offline storage might kick in. In both cases of offline storage, if supported, or if the subscribed JID is a full JID and that resource is not available, the notification could end up with a resource that does not have support for pubsub notifications and/or the particular payload. It has been suggested that a specification like AMP (Advanced Message Processing, XEP-0079), but this has not gained any foothold, unfortunately. > Also, the impact of persist_items on delivery to offline subscribers > is not discussed. Is a non-persisting node inherently presence-based > delivery? (Intuitively, I'd say not. The pubsub#persist-items determines the storage behavior of the node with regard to new or updated items, for later retrieval or automatic delivery upon subscription. Its subscriptions are not a factor here. The only observable difference in notification is around item identifiers, as explained in section 4.3 (Event Types). (I started typing this this morning, so there's some overlap with Kael's response). ralphm
