Subject: Re: [xmpp] 3921bis: subscription pre-approvals

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 09:27:48 -0600

On 8/18/10 8:00 AM, tpatnoe wrote:

<snip/>

> With this new stream feature, are we also planning on using the new ask
> states?
> 
>    ask='subscribe' (3921-safe)
>    ask='subscribed' (in 3921bis since -00, see above)
>    ask='subscribe subscribed' (new)

Yes, advertising this stream feature means that you support all three of
those values for the 'ask' attribute. I'll add a sentence to make that
clear.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 09:58:06 -0600

> those values for the 'ask' attribute. I'll add a sentence to make that

Sigh. I don't think a stream feature solves the problem.

If the server sends the stream feature, the client knows that it can
send a presence stanza of "subscribed" and the server will accept that
as a pre-approval.

However, the server doesn't know if the client will accept values of
"subscribed" and "subscribe subscribed" for the 'ask' attribute.

The only way to solve this is to use Service Discovery (XEP-0030)
because then the server can discover what the client supports.

There are two approaches to consider:

1. Specify subscription pre-approvals in 3921bis, which means that we
would need to introduce a normative dependency on XEP-0030.

2. Specify subscription pre-approvals in a XEP, which means that
everything about presence subscriptions except pre-approvals would
specified in 3921bis.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 18 Aug 2010 18:25:28 +0200

> everything about presence subscriptions except pre-approvals would
Spontaneously I'd suggested:
3. Make it a negotiateable (as opposed to informative) stream feature.
Only if the client negotiated support will the server send
ask="(subscribe )subscribed". That feature would also be strictly optional.

I'm not sure if that's really elegant though...

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 10:40:17 -0600

> ask="(subscribe )subscribed". That feature would also be strictly optional.

Yes, that is another approach. Sorry, I'm a bit under the weather so I'm
not thinking clearly today.

The benefit of a negotiable stream feature is that the client explicitly
opts in to receiving these enhanced roster items. The cost is another
round trip in the stream negotiation process.

And there is a fourth approach...

4. Include a special element or attribute in the roster get (since these
new values of the 'ask' attribute are included in roster items), such as:

   C: <iq from=[email-masked]/home'
          id='ik3bsc14'
          to=[email-masked]'
          type='get'>
        <query xmlns='jabber:iq:roster'
               preapprovals='true'
               ver='ver14'/>
      </iq>

That would still need to be combined with a stream feature.

> I'm not sure if that's really elegant though...

Elegance, shmelegance. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 14:21:36 -0600

> Elegance, shmelegance. :)

I chatted a bit more about this via IM with Tory Patnoe. Here's what we
concluded:

1. Subscription pre-approvals (via <presence type='subscribed'/>) do not
necessarily require the server to tell the client that a contact is
pre-approved. The client could just send the pre-approval and if the
server doesn't support pre-approvals then the server would send the
subscription request to the client just as it always does. It's a
relatively minor user inconvenience to receive the subscription request
even if the user thought the contact was pre-approved. (Naturally, we
could still define a stream feature that would inform the client that
subscription pre-approvals are supported on the server, so the client
can provide the appropriate user interface.)

2. If we feel that it's useful for the server to inform the client that
a contact is pre-approved whenever the client retrieves the roster, we
don't need to do that with ask='subscribed', we could do that with a new
attribute such as approved='true'. This would enable us to work around
the madness with changing the datatype of the 'ask' attribute and
defining new values for it.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Aug 2010 15:43:24 -0600

> defining new values for it.

I now have this specced out in my working copy and I think it works just
fine. I'm going to leave 24 hours for further discussion and then push
out version -12 of 3921bis so that our esteemed working group chairs can
issue a second WGLC while I'm offline for 10 days. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/