[Standards] roster views

Peter Saint-Andre stpeter at stpeter.im
Thu Feb 26 03:35:12 UTC 2009

Matthew Wild wrote:
> On Thu, Feb 26, 2009 at 2:57 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> Matthew Wild wrote:
>>> On Thu, Feb 26, 2009 at 2:33 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>>> [...]
>>>> We had rough consensus that the server would not change its processing
>>>> of your outbound presence, i.e., it would send your presence to your
>>>> entire contact list, not only contacts in the group(s) you specify via
>>>> roster views.
>>> I was of the impression that it would also apply to outgoing
>>> presences, and the filtered roster would essentially become your
>>> roster for that session. I don't know what others think though.
>> I could go either way. If roster views result in filtering of your
>> outbound presence then they are essentially a replacement for (some of)
>> what's now in privacy lists. I like that idea a lot because I don't like
>> privacy lists. :)
> As a user I like that idea a lot, because it cuts out privacy lists.
> As a developer I like it a lot because it cuts out privacy lists :)


> Roster groups/tags are pretty flexible. This combined with simple
> blocking of users (and a way to enable/disable receiving messages from
> people not on your roster) is all that is required in most cases I
> believe, particularly for end-users.



>>>> If people think this would be useful, I'd be happy to write a small spec
>>>> about it. Right now I don't think this belongs in rfc3921bis but I could
>>>> be persuaded to change my mind about that (e.g., it might make sense to
>>>> have both roster versioning and roster views in the same core spec).
>>> I think I already said somewhere that I believe this should be in
>>> core, versioning should be a XEP. Requiring all implementations to
>>> support versioning just feels wrong, and I tend to like smaller specs.
>>> However I understand if others don't feel the same way.
>> I think that either both versioning and views belong in rfc3921bis or
>> neither does. The syntax of what's currently in XEP-0237 (using an
>> attribute to indicate the version number) makes it difficult to split it
>> out into a XEP, but I suppose that could be overcome.
> That's funny, it wasn't like that last week... ;-)

Yeah, then we decided to make it roster-specific as it was in the
beginning, using an attribute. But we could change this:

  <query xmlns='jabber:iq:roster' ver='305'/>

to something like this:

  <query xmlns='jabber:iq:roster'>
    <ver xmlns='urn:xmpp:rosterver' num='305'/>

> I'm not too fussed, it's going to be somewhere at the end of the day,
> doesn't really affect me where it ends up.

Perhaps you're right that we'd better leave rosters alone and define
both versioning and views as extensions. I'll give that some further


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090225/270ff35f/attachment.bin>

More information about the Standards mailing list