[Standards] XEP-0154: User Profile - comments

Dave Cridland 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  
> 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
> names
> 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  
> 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
> includes:
>  * 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
> namespaces.
> Example separation:
>  * urn:xmpp:tmp:profile:basic - Contact information, birthday,  
> nameday,
> etc...
>  * 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  
> 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?
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  
> the
>    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>
> <field var='msn_id'>
>   <value>petersaintandre at hotmail.com</value>
> </field>
> <field var='yahoo_id'>
>   <value>psaintandre</value>
> </field>
> 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>
> <yahoo_id>psaintandre</yahoo_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
> storage!).
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  
> purpose.

My impression is that these are left-overs.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list