Subject: Re: [xmpp] RFC 6121 - Roster and (full) JIDs with resource

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 09 Dec 2011 13:38:15 -0700

Old thread alert!

On 8/19/11 12:37 PM, Alexander Holler wrote:
> Am 19.08.2011 19:03, schrieb Peter Saint-Andre:
>> On 8/14/11 12:44 PM, Alexander Holler wrote:
>>> Hello,
>>>
>>> RFC 6121 doesn't mention what happens with JIDs in roster items with an
>>> non empty resource part.
>>>
>>> Because subscription requests should be treated with the bare JID only,
>>> such roster items doesn't seem to make much sence.
>>>
>>> So, if I don't miss something, the attribute jid of a roster item should
>>> be a bare JID (or changed by the server to such).
>>>
>>> And it might be worth to mention that the change of 'to' in
>>> (un)subscribes from full to bare JIDs by the server might lead to error
>>> stanzas where the 'from' and 'to' attributes are not only exchanged
>>> (because 'to' got modified). Verbose: a presence with type 'subscribe'
>>> to [email-masked]/nick' might result in a presence of type error from
>>> [email-masked]' and not from [email-masked]/nick' (e.g. with
>>> remote-server-not-found)
>>
>> Section 3.1.1 says:
>>
>> A user's client generates a subscription request by sending a
>> presence stanza of type "subscribe" and specifying a 'to' address of
>> the potential contact's bare JID <contact@domainpart>.
> 
> I've read that and the following sections. But I've written the above
> complain because nowhere in section 2 is something written about the
> type of JIDs in rosters. So according to RFC 6121 it is possible to add
> a JID with a resource part to the roster, even if it doesn't make sense,
> at least not in regard to subscriptions.

Yes, it is possible, but not encouraged. The reason we don't prohibit
this behavior is that we don't want to unnecessarily constrain users
from adding any JID to the roster or constrain applications regarding
the addresses they use (e.g., a bot might be located at example.com/bot
and we don't want to say that you can't add such a thing to your roster).

Peter

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

---

From: Alexander Holler <[email-masked]>
Date: Sun, 11 Dec 2011 10:56:28 +0100

Am 09.12.2011 21:38, schrieb Peter Saint-Andre:
>>> the potential contact's bare JID<contact@domainpart>.
>>

That doesn't answer what a server is supposed to do with such roster 
items (or the request to add them). Just putting them into the roster, 
ignoring them otherwise (the subscriptions state would be always none)?

Because I currently don't have the time to work on my server, I don't 
know out of my memories what I've choosen to do, but I tend to just 
forbid such requests.

Regards,

Alexander

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Dec 2011 16:56:11 -0700

> know out of my memories what I've choosen to do, but I tend to just

Postel's Law saith: "Be liberal in what you accept, conservative in what
you send."

IMHO it would be best for the server to accept such a roster item, and
for human-oriented clients to discourage their users from sending such a
roster item. I don't see it as the server's place to return an error
(e.g., malformed-jid) in this case.

Peter

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

---

From: Alexander Holler <[email-masked]>
Date: Fri, 16 Dec 2011 04:58:35 +0100

> (e.g., malformed-jid) in this case.

Hmm, I see more problems when accepting something which can't be used 
afterwards. Changing it (by the server), will end in other problems, 
e.g. what happens if an item without resource already exists?

But regardless how it is solved, I think the best solution is to add a 
sentence to the next revision or version of the RFC which remarks that 
rosters with resource parts aren't functional and should not be used. ;)

Regards,

Alexander

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Dec 2011 09:13:43 -0700

On 12/15/11 8:58 PM, Alexander Holler wrote:
> afterwards. 

In fact it can be used. I can add example.com/bot to my roster just
fine. The roster *can* be used as an address book of sorts even without
presence subscriptions. And I can have a presence subscription to that
bot but not example.com. Etc.

> Changing it (by the server), will end in other problems,

I agree that we'd have problems if the server were to change it.

> rosters with resource parts aren't functional and should not be used. ;)

But they can be functional. And RFC 6121 already has text similar to
what you want. If you don't like the current text, please propose
revised text.

Peter

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

---

From: Alexander Holler <[email-masked]>
Date: Sun, 18 Dec 2011 11:43:43 +0100

Hello,

Am 16.12.2011 17:13, schrieb Peter Saint-Andre:
> fine. The roster *can* be used as an address book of sorts even without#

That should be a bookmark or whatever.

> bot but not example.com. Etc.

I don't see how you can have a subscription for such a roster item.

Section 3 says

   "the server MUST stamp the outgoing presence stanza with the bare JID"

and 3.1.3 says about incoming requests

   "the contact's server SHOULD check the syntax of the JID contained in 
the 'to' attribute. If the JID is of the form 
<contact@domainpart/resourcepart> instead of <contact@domainpart>, the 
contact's server SHOULD treat it as if the request had been directed to 
the contact's bare JID and modify the 'to' address accordingly."

and

   "Security Warning: Until and unless the contact approves the 
subscription request as described under Section 3.1.4, the contact's 
server MUST NOT add an item for the user to the contact's roster."

3.1.5 has a similiar text about removing the resource part.

> what you want. If you don't like the current text, please propose

Sorry, maybe I'm dumb, but I still don't see how roster items with an 
resource part can be functional in regard to presence (besides the usage 
by the client as a bookmark) and what that similiar text is. So I'm 
unable to propose a revised text.

Regards,

Alexander