[Standards] XEP-0154: User Profile - comments
pavlix at pavlix.net
Mon Jul 28 20:56:43 UTC 2008
On Mon, 28 Jul 2008 16:09:34 +0200
"Grégoire Menuel" <gregoire.menuel at gmail.com> wrote:
> On Wed, Jul 23, 2008 at 7:09 AM, Pavel Simerda <pavlix at pavlix.net>
> > 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 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.
> 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.
I think the complexity is not big, but totally unnecessary. Moxt XMPP
libraries can parse XML.
> > 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.
I think we should split the data into logical groups with different
URIs. Asking for particular pieces of information is meant to save
bandwidth, this will save it better IMHO.
> For getting only partial information I see something like that :
> <iq type='result'
> from='hamlet at denmark.lit'
> to='bard at shakespeare.lit/globe'
> <profile xmlns='urn:xmpp:tmp:profile'>
> <x xmlns='jabber:x:data' type='result'>
> <field var='FORM_TYPE' type='hidden'>
> <field var='nickname'/>
> <field var='email'/>
> > * 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.
Can you point me to this PEP magic specs, maybe I missed
> > 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.
IMHO it's not. You may ignore the "usually presented" section. Then
it's the basic structure of the data. This particular separation is not
the main point of my suggestions.
> > 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.
Of course I thought about it. But you won't know the official schemes
for other networks too. In the previous case it was easier to solve.
> > 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:
> > <birthday>
> > <year>1960</year>
> > <month>03</month>
> > <!-- day is omitted -->
> > </birthday>
> If we want to stick to data forms we can't use your solution.
I don't think this is true, more info?
> > 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.
Mandatory for profile-supporting clients, not users. Sorry for the
Thanks for your feedback,
Jabber & Mail: pavlix(at)pavlix.net
More information about the Standards