[Standards-JIG] JEP-0060: Version 1.8pre16

[Ralph Meijer]

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?

-- 
Groetjes,

ralphm