Subject: [xmpp] 321bis - roster name optional

From: Kevin Smith <[email-masked]>
Date: Wed, 21 Jul 2010 10:25:20 +0100

2.1.2.3. The name here is OPTIONAL. I'd suggest that it's optional for
a client to provide one, but that if provided the server SHOULD
persist it.

In general, I see what this section is doing - but using OPTIONAL to
define situational attributes doesn't seem right to me, because their
inclusion is not 'truly optional'.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Jul 2010 19:55:52 -0600

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

> inclusion is not 'truly optional'.

Well, the same is true of the <group/> element, and indeed of any
<item/> elements that the user has added to the roster. I think there is
a better way to state the server's responsibility over data stroage than
by modifying the compliance keywords here (although we might want to do
that in addition).

I'll post to the list again after I've had a chance to look at and
perhaps tweak the current text.

Peter

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

---

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

On 7/24/10 3:55 AM, Peter Saint-Andre wrote:
> <item/> elements that the user has added to the roster. 

In Section 2.1.2.3, I now have:

   It is OPTIONAL for a client to include the 'name' attribute when
   adding or updating a roster item.

In Section 2.1.2.5, I now have:

   It is OPTIONAL for a client to include the <group/> element when
   adding or updating a roster item.

> I think there is

In the first paragraph of Section 2, I now have:

   In XMPP, a user's roster contains any number of specific contacts.  A
   user's roster is stored by the user's server on the user's behalf so
   that the user can access roster information from any device.  When
   the user adds items to the roster or modifies existing items, if an
   error does not occur then the server MUST store that data and return
   it unmodified when an authorized client requests the roster.

/psa

---

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

>   it unmodified when an authorized client requests the roster.

That works, thanks.

/K

---

From: Waqas Hussain <[email-masked]>
Date: Mon, 26 Jul 2010 03:12:18 +0500

>   adding or updating a roster item.

I already see in -08:

  Inclusion of the <group/> element is OPTIONAL. If a roster set
  includes no <group/> element, then the item is to be interpreted
  being affiliated with no group.

>   it unmodified when an authorized client requests the roster.

MUST should be SHOULD. Returning unmodified can be out of the control
of the XMPP server (e.g., when roster storage is backed by an external
non-XMPP service, with its own set of policies, or a SQL db can be set
to convert 'name' to all-caps, etc).

--
Waqas Hussain

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Jul 2010 08:56:56 +0200

>   being affiliated with no group.

Right. I didn't quote the entire paragraph from my working copy:

   It is OPTIONAL for a client to include the <group/> element when
   adding or updating a roster item.  If a roster set (Section 2.1.5)
   includes no <group/> element, then the item is to be interpreted as
   being affiliated with no group.

> to convert 'name' to all-caps, etc).

How about this further tweak?

   In XMPP, a user's roster contains any number of specific contacts.  A
   user's roster is stored by the user's server on the user's behalf so
   that the user can access roster information from any device.  When
   the user adds items to the roster or modifies existing items, if an
   error does not occur then the server SHOULD store that data
   unmodified if at all possible and MUST return the data it has stored
   when an authorized client requests the roster.

I see three possibilities:

1. SHOULD store that data unmodified if at all possible.

2. MUST store that data unmodified if at all possible.

3. MUST store that data (which SHOULD be unmodified if at all possible).

/psa

---

From: Kevin Smith <[email-masked]>
Date: Mon, 26 Jul 2010 08:43:48 +0100

>   when an authorized client requests the roster.

That text works for me.

/K