[Standards] XEP-0154: User Profile - comments
gregoire.menuel at gmail.com
Mon Jul 28 14:09:34 UTC 2008
On Wed, Jul 23, 2008 at 7:09 AM, Pavel Simerda <pavlix at pavlix.net> wrote:
> 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.
> 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.
Actually I don't think it add really more complexity to use data
forms, and it is certainly more easy to use since most XMPP libraries
are able to parse these data forms. The only problem I can see with
data forms is the bandwidth overhead added, but with stream
compression it should not really be noticeable.
> 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
I think we should use the power of data forms to ask only partial
data, although having predefined information profiles to retrieve only
given partial information also make sense.
For getting only partial information I see something like that :
from='hamlet at denmark.lit'
to='bard at shakespeare.lit/globe'
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
> * User's picture changes, I don't need to download his about/contacts.
For this the magic of PEP notify should send you only the modified
data when they are modified.
> 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
It is more a client implementation problem than a standard related problem IMHO.
> 4) The instant messaging contacts
> 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>
And what about just :
<field type='list-multi' var='im'>
<item>xmpp:stpeter at jabber.org</im>
<item>msnim:petersaintandre at hotmail.com</item>
I'm just not sure how official the MSN, Yahoo, ... URL scheme are.
> 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 -->
If we want to stick to data forms we can't use your solution.
> 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.
Agreed, I don't see the point to have the geoloc information in both
XEP 0154 and XEP 0080, it doesn't seems to fit right in this spec.
> 7) Implementation issues
> It might be desirable to only mark some of these nodes obligatory
> and maybe even move the others to separate XEPs?
I don't think that any of the nodes are mandatory, like for vcard, a
user won't fill in every thing piece of information, but I think it is
good to let the user have the choice, and therefore i like having so
many field, even if only a part of them will usually be used.
xmpp:omega at im.apinc.org
GPG : 1024D/D3BF3B20
More information about the Standards