On 28-Aug-2009, at 17:17, Fabio Forno wrote:
If the XMPP error is of type "cancel" (e.g., <item-not-found/>), or
the error condition is <gone/>, the pubsub service SHOULD terminate
the subscription of the entity to that node and MAY terminate the
subscription of that entity to all nodes hosted at the service.
This means if the subscriber is a component and that component is
temporary unavailable (e.g. we restart it or it goes down for
maintenance) it is likely that it gets unsubscribed, while the desired
behavior would rescheduling the event.
For the two examples you give, unsubscription makes sense, as they're
authoritative permanent conditions. In fact, according to RFC3920
9.3.2, any error of type "cancel" is a permanent condition, in which
case the above semantics make sense.
The problem, I think, is that <service-unavailable/>, potentially
<remote-server-not-found/>, and maybe more might not make sense as
type "cancel" since they're frequently generated for transient errors
(the service is temporarily offline, as you say). I see two options
off the top of my head (which hasn't had its coffee yet):
1) Add transient versions of at least <service-unavailable/> with an
error of type "wait." To distinguish the permanent vs. transient
conditions a server would only need to know if it's configured to
allow for that component to connect although it might not be at the
time (potentially <recipient-unavailable/> would due here), or,
2) Have the server which handles the component save the messages
until the component connects, akin to offline delivery.
Another thing: I think that the option of delivering items via <iq/>
has already been discussed many times, but I don't find any reference
I don't remember seeing this. All I remember is retrieving items by
iq, which is described in XEP-0060 s6.4.
-bjc
