Subject: [xmpp] 3921bis - bare JIDs not shadowing full JIDs

From: Kevin Smith <[email-masked]>
Date: Wed, 21 Jul 2010 15:48:29 +0100

In 4.5.4, it's said that receiving unavailable from a bare JID only
means that the session with an empty resource is offline, not any
other sessions. This seems wrong - if I send a presence probe to the
bare JID, for example, and I receive an unavailable from the bare JID
am I supposed to assume that this doesn't mean that the user is
offline, but just that I should be waiting for other results from full
JIDs?

I vaguely remember reading this before and thinking it looked wrong,
but I can't remember what the context was (whether it was a list
discussion or not).

Can we just say that bare JID unavailable means all resources are offline?

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 24 Jul 2010 01:19:15 -0600

[Typed while in flight, delivery will be delayed.]

On 7/21/10 8:48 AM, Kevin Smith wrote:
> other sessions. This seems wrong 

I think you're right. Good catch.

> - if I send a presence probe to the

Well, I don't think a client would block here and IMHO it never makes
sense for a client to be "waiting for" or "expecting" presence from any
resources (presence notifications always arrive serendipitously, as it
were).

> but I can't remember what the context was (whether it was a list

IIRC there was a discussion about this once on some list or another, but
I'm not sure which list (or when). The context, as I recall, was
zero-length resources. But those are prohibited by the address spec, so
I don't know why we are trying to accommodate them here.

> Can we just say that bare JID unavailable means all resources are offline?

Yes, that is consistent with point 3 of Section 4.3.2:

###

4.3.2.  Server Processing of Inbound Presence Probe

   Upon receiving a presence probe to the contact's bare JID from the
   user's server on behalf of the user, the contact's server MUST reply
   as follows:

   ...

   3.  Else, if the contact has no available resources, then the server
       SHOULD reply to the presence probe by sending to the user a
       presence stanza of type "unavailable" (although sending
       unavailable presence here is preferable because it results in a
       deterministic answer to the probe, it is not mandatory because it
       can greatly increase the number of presence notifications
       generated by the contact's server).  Here the 'from' address is
       the bare JID because there is no available resource associated
       with the contact.

   ...

###

Unavailable from the bare JID might also mean "all resources are offline
as far as you're concerned" -- see point 4 in Section 3.1.3 about
optionally returning presence of type unavailable as an acknowledgement
of having received a subscription request.

###

3.1.3.  Server Processing of Inbound Subscription Request

   ...

   4.  Otherwise, if there is at least one available resource associated
       with the contact when the subscription request is received by the
       contact's server, then the contact's server MUST broadcast that
       subscription request to all available resources in accordance
       with Section 8.

       As a way of acknowledging receipt of the presence subscription
       request, the contact's server MAY send a presence stanza of type
       "unavailable" from the bare JID of the contact to the bare JID of
       the user (the user's client MUST NOT assume that this ack
       provides presence information about the contact, since it comes
       from the contact's bare JID and is received before the
       subscription request has been approved).

   ...

###

That's a long-winded way of saying that in my working copy I have
adjusted the text as follows:

   Typically, presence provides availability information about a
   particular connected resource.  However, it is possible for the
   contact to receive an unavailable notification from the bare JID of
   the user.  In this case, the presence notification SHOULD be treated
   as applying to all resources.

Peter

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

---

From: Kevin Smith <[email-masked]>
Date: Sat, 24 Jul 2010 15:23:08 +0100

>   as applying to all resources.

+1

/K