[Standards] XEP-0154: User Profile - comments

Pavel Simerda pavlix at pavlix.net
Wed Jul 23 05:09:10 UTC 2008


I finally got to examine the XEP-0154 (User Profile). When reading
through I realized how big a job it was to synchronize the items and
names with various standards and other XEPs. I hope I can help to
get further with this protocol extension.

I have a few suggestions we already discussed in the jdev room
and elsewhere.

It will be long. Sorry. But please read on if you're interested in
replacing the vcard by something both more powerful and efficient.

1) Look at the examples at http://www.xmpp.org/extensions/xep-0163.html
(Personal Eventing via Pubsub). Now look at the examples of XEP-0154.

The biggest difference is the added complexity and data because of the
data form syntax. These are actually no forms but data with a
particular structure.

I read carefully the arguments for data forms but most of them also
apply to structured formats. Then there is database storage which
I consider a non-issue (I can give more details if needed) and
extensibility that should be IMO done differently (more details later).

Possible solution: Replace all of the data forms syntax with variable
by custom elements of the same (or similar) names. At the same time
I propose to keep up with the examples in XEP-0154.


<iq type='set' id='pub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:tmp:profile'>
        <profile xmlns='urn:xmpp:tmp:profile'>
          <x xmlns='jabber:x:data' type='result'>
            <field var='jid'>
              <value>stpeter at jabber.org</value>
              <value>peter at saint-andre.com</value>

would be changed (if we make no other changes) to:

<iq type='set' id='pub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:tmp:profile'>
        <profile xmlns='urn:xmpp:tmp:profile'>
	  <jid>stpeter at jabber.org</jid>
	  <jid>peter at saint-andre.com</jid>

(Btw, the <item/> element was missing in at least one of the examples,
if my understanding is correct.)

2) I believe that the answer to the query for user information should
be reasonably short. This would have several consequences.

 * it would be possible to use with mobile client (I still have
problems with vcard images on my mobile)
 * it would not be then necessary to implement special techniques for
partial profile getting/setting

Possible solution: Don't include any data except short text. This
 * User pictures (aka avatars)
 * Long 'about' texts
 * Piles of unnecessary or uninteresting information

These requirements are very easy to achieve. We only need to divide the
former monolithic profile/extended vcard. We would need more

Example separation:

 * urn:xmpp:tmp:profile:basic - Contact information, birthday, nameday,
 * urn:xmpp:tmp:profile:about - About text (as in vcard-temp)
 * urn:xmpp:tmp:profile:picture - User picture / photo

Use cases:
 * I have a desktop client and good connection but lots of contacts.
   I want my client to first get the information about users and then
   (possibly) the pictures.
 * I have a mobile client and/on slow internet connection. I just want
   to check my friend's phone number. Downloading other contact info
   is considered a reasonable overhead (I may need it if the phone
   number is not published anyway). Downloading user's picture and a
   long about section *cannot*.
 * User's picture changes, I don't need to download his about/contacts.
 * User's contacts change, I don't need to recieve all the other
   (unchanged) stuff.

3) home / work addresses

There are several solutions for designating home/work addresses. As far
as I understand the current XEP, we need to distinguish three types of
contact information pieces: generic, home and work. 

Home and work addresses are usually presented in separate tabs. There
could be also usecases where home information is irrelevant or has a
different publishing policy than work information. What I'm not sure
about is the generic info, any suggestions?

Possible solution: further split the basic information into four

a) General information (and possibly generic contacts, which I see not
much use for)
 * Name and related
 * Birthday and nameday (possibly moved to misc.)
 * Generic stuff
b) Home information (self-describing)
c) Work information (except several elements has the same
structure as home info)
d) Miscellanous information
 * I've seen something about religion
 * languages spoken
 * more personal stuff
For the sake of completeness, I repeat the other sections:
e) About page
f) User picture
Some other permanent suggestions:
g) xhtml-im version of the about page

Of course this list needs an extensive review.

Advantages of this approach:
 * We almost never need to read all this stuff at the same time.
   This suggestion actually copies the way the data are actually used
   and displayed (roughly one section per tab in a typical user info
 * With a desktop client we may want to cache the user data on
   the disk and only download if changed. We should keep the
   synchronization stuff together and there's no better place than
   PEP/PubSub and divided into cathegories that usually change as a
 * In low-speed/expensive network environments we also benefit from the
   separation. The client program may download only the section the
   user actually wants to see.
 * In other environments the client may first download what the user
   wants and only then cache what the user may want next (e.g. first
   download general info and avatar for the typical current UI's first
   tab and then the other data).
 * *Extensibility* is achieved by allowing more sections to be added
 * The natural way to add company-specific data (that shouldn't be
   usually necessary) is to add special section for internal stuff.

4) The instant messaging contacts

The current spec proposes:

<field var='jid'>
  <value>stpeter at jabber.org</value>
  <value>peter at saint-andre.com</value>
<field var='msn_id'>
  <value>petersaintandre at hotmail.com</value>
<field var='yahoo_id'>

In the words of my proposal, this is:

<jid>stpeter at jabber.org</jid>
<jid>peter at saint-andre.com</jid>
<msn_id>petersaintandre at hotmail.com</msn_id>

It's fairly inflexible and even with the current version,
we need to add another field. That means the clients won't
understand it at all. Adding new elements makes no more harm
but is also no better!

what I suggest is to unify all contact addresses with the same type
(purpose). An example would be:

<im network="xmpp">stpeter at jabber.org</im>
<im network="xmpp">peter at saint-andre.com</im>
<im network="msn">petersaintandre at hotmail.com</network>
<im network="yahoo">psaintandre</im>

One might also consider other possible syntaxes.

This applies to:
 * 6.4. Telephony Address Data Aspects
 * 6.5. Electronic Address Data Aspects
 * 6.6. World Wide Web Resource Aspects

Alternatively, we might call it always 'type' to make easier mapping to
a relational database (but it doesn't help a generic pubsub xml

5) Birthday / nameday

I very appreciate you can set individual parts of birthday.
The only thing I would think of... is if we couldn't do with:

<birthday>1960-xx-xx</birthday> - only year specified
<birthday>xxxx-03-20</birthday> - month and day specified

Advantages: one birthday - one field
Disadvantages: one might consider the current way more XMLish

Third alternative:
  <!-- day is omitted -->

6) Non-profile

There are some data included that don't seem to fit in the "static"
profile like geolocation. But maybe I just misunderstood their purpose.

I believe these should be moved out of the scope of the user profile
specification to make clear distinction between permanent profile
and often-changing (rather presence) data.

Grey area is the user picture. We should maintain a clear distinction
between dynamic avatars and profile images.

7) Implementation issues

a) Servers need to include storage for node data.

b) Servers may (and usually will) implement the vcard-temp extension
mapped to the appropriate nodes (if available)

c) Client authors may not want to include UI for every single piece of
information. Proper division into node for various types of data
enables them to just choose the groups of fields they're authors (and
users) want.

Server administrators may provide other means to fill-in data not
supported by some of the clients - e.g. in a web form confirmed by
"XEP-0070: Verifying HTTP Requests via XMPP".

It might be desirable to only mark some of these nodes obligatory
and maybe even move the others to separate XEPs?

This are a lot of issues to cope with, I expect a lot of comments and
discussion. I want to help as much as I can with this one :), tell me
what need to be done.

Pavel Simerda


Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

More information about the Standards mailing list