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

From: Alexander Holler <[email-masked]>
Date: Sun, 14 Aug 2011 20:44:10 +0200

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)

Regards,

Alexander

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 19 Aug 2011 11:03:25 -0600

> [email-masked]' and not from [email-masked]/nick' (e.g. with

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>.

    UC: <presence id='xk3h1v69'
                  to=[email-masked]'
                  type='subscribe'/>

    When a user sends a presence subscription request to a potential
    instant messaging and presence contact, the value of the 'to'
    attribute MUST be a bare JID <contact@domainpart> rather than a full
    JID <contact@domainpart/resourcepart>, since the desired result is
    for the user to receive presence from all of the contact's resources,
    not merely the particular resource specified in the 'to' attribute.
    Use of bare JIDs also simplifies subscription processing, presence
    probes, and presence notifications by the user's server and the
    contact's server.

Note also that the checks in Section 3.2.2, 3.3.3, and 4.3 (including 
all of its subsections) are all based on the bare JID.

Peter

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

---

From: Alexander Holler <[email-masked]>
Date: Fri, 19 Aug 2011 20:37:28 +0200

> 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.

Regards,

Alexander