Subject: [xmpp] Not sending roster adds for subscription requests.

From: Kevin Smith <[email-masked]>
Date: Mon, 22 Mar 2010 11:29:01 +0000

I've just noticed the following in 3921-bis:
3.1.1.  Client Generation of Outbound Subscription Request
  ...
      Although many XMPP clients prompt the user for information about
      the potential contact (e.g., "handle" and desired roster group)
      when generating an outbound presence subscription request, the
      client MUST NOT send a roster set before sending the presence
      subscription request, but instead MUST wait until receiving the
      initial roster push from the server.  This enables the user's
      server to enforce any policies relevant to presence subscriptions
      (e.g., a prohibition on presence subscriptions to full JIDs).

You can work around this in clients with a bit of extra plumbing and
an extra roundtrip (and a push for every connected resource), but I'm
not sure of the merit - if the server doesn't want full jids in the
roster, can't they just reject the roster add?

Thoughts?

/K

---

From: Dave Cridland <[email-masked]>
Date: Mon, 22 Mar 2010 12:12:41 +0000

> roster, can't they just reject the roster add?

I suppose a server could allow full jids in the roster, but only with  
subscription=none.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Kevin Smith <[email-masked]>
Date: Mon, 22 Mar 2010 19:32:40 +0000

> I suppose a server could allow full jids in the roster, but only with

It could. The quoted text doesn't help one way or the other for this, though.

My reading of things as they stand is that:

* It's fine to add someone to your roster without a presence
subscription, because you don't want one.
*   It's fine for you to then change your mind and ask for a presence
subscription for them, and you've already got a sensible nickname, and
group membership set.

*  It's forbidden to add someone to your roster before sending a
presence subscription, so you've got sensible nickname and group
membership set, and then send the subscription request.

So the text seems to not solve a problem, while it's an inconvenience
(albeit not an insurmountable one) for client developers. Given that
the 'send roster, then request' is standard practice in the wilds and
is useful, it's not clear to me what benefit the above text brings.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Mar 2010 08:52:04 -0700

> is useful, it's not clear to me what benefit the above text brings.

I agree that the MUST NOT is inappropriate here. I'll take a closer look
sometime this week so that I can propose some alternate text.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Mar 2010 12:18:03 -0600

> sometime this week so that I can propose some alternate text.

I think it would be best to simply remove that note.

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Wed, 31 Mar 2010 19:20:44 +0100

> I think it would be best to simply remove that note.

Works for me, thanks.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Mar 2010 12:23:45 -0600

>> I think it would be best to simply remove that note.

I changed my mind. :)

How is this?

***

      Note: Many XMPP clients prompt the user for information about the
      potential contact (e.g., "handle" and desired roster group) when
      generating an outbound presence subscription request and therefore
      send a roster set before sending the outbound presence
      subscription request.  This behavior is OPTIONAL, because a client
      MAY instead wait until receiving the initial roster push from the
      server before uploading user-provided information about the
      contact.  A server MUST process a roster set and outbound presence
      subscription request in either order.

***

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Wed, 31 Mar 2010 19:29:32 +0100

>      subscription request in either order.

It avoids making any demands of implementations, while documenting
existing usage. Works for me too.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Mar 2010 12:31:16 -0600

> existing usage. Works for me too.

OK. I'm going to submit -06 of 3920bis and 3921bis now so that we're up
to date...

Peter

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