[Standards-JIG] Extended user info updates

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Thu Mar 17 13:02:54 UTC 2005


You definitively brought a good summing up here. 

The original question was about why on earth isn't the nick proposal [1] a
JEP yet. That's all...
We do have JEP-107, JEP-108, JEP-112 and JEP-80 to cover so called
'extended' presence in SIP/SIMPLE and Wireless Village, we are just missing
that one on nick/display names.

There will probably be long debates about the nature of vCard information,
and what is or is not an attribute of presence. I believe this is a lot of
wasted energy. Everybody will probably voice a different position on these
vast and controversial subjects. As a matter of fact the SIP/SIMPLE side has
already taken position on this, and they call it 'rich presence'...

As Richard was pointing out, I am amazed at the passion that a dynamic
nickname is arousing. And how many positions are subjective. After all, do
we want to live in an XMPP only dream, or do we work at making XMPP a better
way to communicate with the world?



-----Original Message-----

Message: 3
Date: Thu, 17 Mar 2005 11:08:05 +0100
From: Ralph Meijer <jabber.org at ralphm.ik.nu>
Subject: Re: [Standards-JIG] Extended user info updates (VCard+)
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <20050317100805.GA79316 at ik.nu>
Content-Type: text/plain; charset=iso-8859-1

On Thu, Mar 17, 2005 at 09:28:38AM -0000, Richard Dobson wrote:
> But anyway, I believe the nickname update etc stuff would be better served

> by rather than just creating something specific for nicknames, create the 
> pubsub functionality as an add on for whichever standard we use to replace

> vcards, so users can subscribe to updates of not just a users nickname but

> also of any of the vcard data e.g. home address etc, this means that 
> contacts do not need to periodically probe a users "vcard+" data (which is

> a waste of bandwidth if it hasnt changed), but rather can just wait to be 
> sent updates notifying them that something has changed, and if we 
> appropriately optimise it only notify about the data that has actually
> changed, rather than just sending a new copy of the vcard. We might also 
> want to allow subscribers to specify in some way that they only wish to 
> receive updates of a particular subset of that information. Now I know
> it might not be a necessity to receive immediate updates of most of a
> vcard info but its still a nice to have, and potensially useful to have 
> completely uptodate info without having to specifically probe for it 
> everytime as we currently do for vcards, this behaviour just seems rather 
> sub optimal to me, certainly considering we have stuff like pubsub at our 
> disposal.

First, the User Nickname proposal [1] is probably misnamed. It isn't about
real nicknames, because, indeed, nicknames don't change very often. What
does change, is the information put in the nickname's place (e.g. in MSN):

  - What they're up to
  - Some reaction to a recent event (personal, political, etc) or the
  - Some favourite quote.

It would be very useful to use pubsub for this. N don't have a good name
for it, though.

Things like 'On the Phone', 'In the Shower' are covered by User Activity
and stuff like 'I am pretty sad' by User Mood [3].

About a vcard replacement. If we use pubsub for this, we could use
content-based subscriptions for only getting updates on the stuff you are
interested in. You configure your subscription with a selection of the list
of data items in the vcard. Birthdays don't change all that often, but other
stuff might.

Another idea of merging User Location with such new vcards is having the
mirror the information last published to a User Location node.

In any case, I would welcome people to do prototype implementations of
the mentioned protocols to get hands-on experience with them. Stuff to be
figured out include:

  - How do present all these different snippets of information to a user?
  - How can a user change his own extended presence information *easily*?
  - How do let the user discover (using disco publish) and subscribe
    to information of others?

If you want to have a pubsub service for testing out your prototype, I have
Idavoll [4] component waiting for you. You can of course also install it

[1] http://www.jabber.org/jeps/inbox/nick.html
[2] http://www.jabber.org/jeps/jep-0108.html
[3] http://www.jabber.org/jeps/jep-0107.html
[4] http://idavoll.jabberstudio.org/



More information about the Standards mailing list