Subject: [xmpp] 3921bis Assuming IM clients?

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

In 4.2.4 there's:
"If the user is in the contact's roster, the client MUST display the
presence information in an appropriate roster interface."

That seems rather out of place - surely it's up to the client whether
it wants to display contacts' presence states?

In fact, reading 4.2.3 points 1, 2 and 3, I'm not convinced that any
of them are needed for interoperability, and all seem to just be
preconceptions about how user interfaces should be designed.

I'd suggest either binning the lot, or replacing all three with MAY.

/K

---

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

> I'd suggest either binning the lot, or replacing all three with MAY.

This appears again in 4.4.4

In fact, following these literally would break XEP-0045 (MUC), because
the user isn't explicitly exchanging either messages or iq with the
contact, so must ignore presence from the MUC it just asked to join.

/K

---

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

> This appears again in 4.4.4

And 4.6.4.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 24 Jul 2010 04:23:50 -0600

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

> contact, so must ignore presence from the MUC it just asked to join.

A MUC room is not a contact in the sense described in 3921bis.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 24 Jul 2010 04:28:18 -0600

>> This appears again in 4.4.4

And don't forget 4.5.4, too. :P

Seriously, 3921bis is about presence between a user and a contact. I'd
be happy to add a note about presence from other kinds of entities
(e.g., multi-user chat rooms). Let me formulate some text and find a
good place for it.

Peter

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

---

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

On Sat, Jul 24, 2010 at 11:28 AM, Peter Saint-Andre <[email-masked]> wrote:
> (e.g., multi-user chat rooms).

It is - but it's only about the protocol, it's up to the clients
whether they want to display the presences, or throw half of them
away, or whatever.

Would it hurt to change all three MUSTs to MAY?

> Let me formulate some text and find a
> good place for it.

OK.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 24 Jul 2010 04:22:33 -0600

> I'd suggest either binning the lot, or replacing all three with MAY.

I'd suggest:

###

4.2.4.  Client Processing of Initial Presence

   When the contact's client receives presence from the user, the
   following behavior is RECOMMENDED on the part of the contact's
   client:

   1.  If the user is in the contact's roster, display the presence
       information in an appropriate roster interface.

   2.  If the user is not in the contact's roster but the contact and
       the user are actively exchanging message or IQ stanzas, SHOULD
       display the presence information in the user interface for that
       communication session (see also Section 4.6 and Section 5.1).

   3.  Otherwise, ignore the presence information and not display it to
       the contact.

###

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 25 Jul 2010 14:43:13 +0200

> Would it hurt to change all three MUSTs to MAY?

Right now my working copy says "the following behavior is RECOMMENDED"
for all three. I could easily change "RECOMMENDED" to "suggested" and
thereby remote all normative language. It's really just a UI hint, so a
mere suggestion seems appropriate to me.

>> Let me formulate some text and find a

See above. Here is an example.

###

   When the contact's client receives presence from the user, the
   following behavior is suggested:

###

---

From: Kevin Smith <[email-masked]>
Date: Sun, 25 Jul 2010 13:48:46 +0100

> mere suggestion seems appropriate to me.

Suggestion seems good. If you do want normative language, MAY seems
appropriate, but a suggestion is better to my eyes.

>   3.  Otherwise, ignore the presence information and not display it to

+1 - additionally should that SHOULD be a straight removal?

/K