Subject: [xmpp] Roster get to other entities.

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

2.1.3 I think we had consensus that roster gets were no longer
restricted to being from a client to their server (or indeed to any
server), so this should probably be reworded.

Similarly in 2.1.4 for the results.

/K

---

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

On 7/24/10 4:44 AM, Peter Saint-Andre wrote:
> [Typed while in transit, delivery will be delayed.]
> 
> On 7/21/10 3:27 AM, Kevin Smith wrote:
>> restricted to being from a client to their server (or indeed to
>> any server), so this should probably be reworded.
>> 
> And similarly throughout the spec.
> 
> Might I suggest that we add a sentence or two about the possibility
> of storing the roster with entities other than the server, but not
> modify dozens of paragraphs in the spec? For instance, we'd need to
> come up with some term for "entity that stores a roster on behalf of
> a user" (the only thing I can come up with in my jetlagged state is
> "roster depot" but that's ugly). One reason I don't want to change so
> much in the spec is that we'd be modifying a lot of text in order to
> describe something with which we have no experience. I'd rather see
> what happens when we distribute roster storage around the network
> before we change the core specs. However, we do need to make some
> smaller modifications here and there, as you've noted in other
> messages (to which I'll reply separately).

Heh, I'm replying to unsent messages. :)

How's this for text?

   RFC 3921 assumed that the only place where a user stores their roster
   is the server where the user's account is registered and at which the
   user authenticates for access to the XMPP network.  This
   specification removes that strict coupling of roster storage to
   account registration and network authentication, such that a user
   could store their roster at another location, or could have multiple
   rosters that are stored in multiple locations.  However, in the
   absence of implementation and deployment experience with a more
   flexible roster storage model, this specification retains the
   terminology of RFC 3921 by using the terms "client" and server" (and
   "the roster" instead of "a roster"), rather than coining a new term
   for "a place where a user stores a roster".  Future documents might
   provide normative rules for non-server roster storage or for the
   management of multiple rosters, but such rules are out of scope for
   this document.

/psa

---

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

>   management of multiple rosters, but such rules are out of scope for

That seems a simple solution, sure.

/K

---

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

Might I suggest that we add a sentence or two about the possibility of
storing the roster with entities other than the server, but not modify
dozens of paragraphs in the spec? For instance, we'd need to come up
with some term for "entity that stores a roster on behalf of a user"
(the only thing I can come up with in my jetlagged state is "roster
depot" but that's ugly). One reason I don't want to change so much in
the spec is that we'd be modifying a lot of text in order to describe
something with which we have no experience. I'd rather see what happens
when we distribute roster storage around the network before we change
the core specs. However, we do need to make some smaller modifications
here and there, as you've noted in other messages (to which I'll reply
separately).

Peter

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