[jdev] presence subsription rejection notifications while offline.

[Justin Karneges]

On Wednesday 12 May 2010 08:54:14 Peter Saint-Andre wrote:
> On 5/12/10 9:12 AM, Philipp Hancke wrote:
> > Daniel V. Grillo wrote:
> >> Hi Folks,
> >>
> >> I've built a minimal xmpp client to keep track of contacts presence
> >> status.  In previous versions, if a user asked a contact for a
> >> subscription to presence, my client automatically granted it.  Now I
> >> want to notify a
> >> contact of such a request and let them grant or reject it. I have it
> >> working according to rfc 3921 section 8.
> >>
> >> I do have one question/issue though.  If a users presence request is
> >> denied by the contact while the user is online, he gets notified of the
> >> rejection as defined in section 8.2.1 (using the ejabberd server).  I
> >> can then pop up a notification stating "so and so rejected your
> >> request". But if the user is offline when the rejection happens, and
> >> then logs in, he gets no such notification.   He just gets his roster
> >> with that contact in the "none" state with the "ask" flag stripped and
> >> no indication of how that contact got that way. Since  a contact can end
> >> up in the none state in various ways, I can't use that fact to pop up a
> >> notification. So my question is, how can I give a user notification that
> >> his subscription requests were rejected while he was offline?  I see
> >> that psi has the same issue and so does Exodus. They give rejection
> >> notifications while the user is online, but not when he got the
> >> rejection while logged off and then logs on. Any way to implement such a
> >> feature?
> >
> > This might be possible by storing the unsubscribed stanza on the server
> > when the user is offline, ie. adding a rule similar to the fifth rule of
> > section 3.1.3 in section 3.2.3 in 3921bis-06, and then sending this when
> > the roster is fetched.
>
> Yes, I suppose we could add a note about this to rfc3921bis (currently
> we assume that the unsubscribed is merely an FYI and not something that
> the receiving server needs to continually poke the client about).

I wondered if servers lately were not relaying unsubscribed events, at least 
in the case of breaking an active subscription, because many people find the 
event to be rude.  I know that breaking an active subscription isn't the same 
as denying a subscription request, but I'm sure there's overlap in the code 
so I just wanted to throw that out there.

-Justin