[Standards] XEP-0154: User Profile - comments
dave at cridland.net
Mon Jul 28 15:07:24 UTC 2008
On Wed Jul 23 06:09:10 2008, Pavel Simerda wrote:
> 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.
FWIW, I've implemented some of this, primarily because of the mapping
that does exist - it's much easier to present the administrator with
functionality for mapping from XEP-0154 names to whatever storage
exists than to do so directly from vCard.
> 1) Look at the examples at
> (Personal Eventing via Pubsub). Now look at the examples of
> The biggest difference is the added complexity and data because of
> 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
> Possible solution: Replace all of the data forms syntax with
> by custom elements of the same (or similar) names. At the same time
> I propose to keep up with the examples in XEP-0154.
Right, I thought so too, initially. But data forms are well
understood, and prevent people from going too crazy about these
things. Ideally, I just want key=>value mapping, and I can just about
deal with multivalued keys.
> 2) I believe that the answer to the query for user information
> 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
> 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
> former monolithic profile/extended vcard. We would need more
> Example separation:
> * urn:xmpp:tmp:profile:basic - Contact information, birthday,
> * urn:xmpp:tmp:profile:about - About text (as in vcard-temp)
> * urn:xmpp:tmp:profile:picture - User picture / photo
Well, in principle, user images should be XEP-0084 avatars, so we
lose this problem mostly.
Yes, users could go overboard in how much information about
themselves they define, but I've not seen this as a problem in
practical terms with vCards except for the avatars.
> 3) home / work addresses
> There are several solutions for designating home/work addresses. As
> as I understand the current XEP, we need to distinguish three types
> contact information pieces: generic, home and work.
> Home and work addresses are usually presented in separate tabs.
> 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?
Yes, this is a problem for me, too. If you're pulling this stuff out
of a directory, for instance, then LDAP defines work and home contact
data, but not generic contact data - I can't really see that generic
contact data would be anything except either home or work.
> * In low-speed/expensive network environments we also benefit from
> separation. The client program may download only the section the
> user actually wants to see.
Oh, be careful with this. The moment a user wants to see two items of
data, they have to ask twice, which is more transmission, and
therefore more cost.
> 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
Even if you stick with forms, there's still a lot of truth here.
> 5) Birthday / nameday
> I very appreciate you can set individual parts of birthday.
Of course, the whole thing gets hideous when using a back-end store
which can only store a date.
> 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
My impression is that these are left-overs.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards