[Standards-JIG] JEP-0060: Version 1.8pre16
jabber.org at ralphm.ik.nu
Wed Jun 14 13:47:06 UTC 2006
On Mon, May 08, 2006 at 02:29:43PM -0600, Peter Saint-Andre wrote:
> Agreed, we don't need that for immediate acceptance (since we have the
> IQ result related to the subscription request) but we probably need it
> for approval of pending subscriptions. I'll some text about that to
> Sections 6.1, 8.6, and 12.11.
> > And even as a result of
> > subscription/unsubscription by a non-owner (having the result of
> > <subscribe/> to be empty).
> That is not mentioned in Section 12.11 but I'll add text about it.
> > It would work mostly like
> > the roster. For that to work, it needs its own disco feature.
> I've added a disco feature for "subscription-notifications".
My general idea was that we could make subscription notification more
like how presence subscriptions work. So apart from the notification
on subscription change, that went into 1.18pre17, I could imagine
making <subscribe/> return only an empty iq result, and then sending
the current state in the same way using <subscription/>.
> > Also,
> > users should somehow be able to ask for the to be enabled.
> Is that necessary? It seems to me that a service would either support
> that or not. Does it really need to be enabled/disabled on a per-node
> basis (by the owner) or a per-subscription basis (by the subscriber)?
This was coming from the idea that subscribers might not be interested
in getting such events, or can assume subscriptions always succeed.
I was looking for a complete solution to the 'subscription roster' idea.
In any case, <subscription/> should go into the #event namespace?
More information about the Standards