[Standards] XEP-0154: User Profile - comments

Pavel Simerda pavlix at pavlix.net
Tue Jul 29 10:48:47 CDT 2008


On Mon, 28 Jul 2008 21:21:02 -0600
Peter Saint-Andre <stpeter at stpeter.im> wrote:

> Ahoj Pavle! ;-)
> 
> Pavel Simerda wrote:
> > Hello,
> > 
> > I finally got to examine the XEP-0154 (User Profile). 
> 
> Thanks for the review.

It was fun :).

> > When reading
> > through I realized how big a job it was to synchronize the items and
> > names with various standards and other XEPs. 
> 
> I think it was mostly bookkeeping, but thanks.
> 
> > 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'm not a huge fan of x:data here either.
> 
> > 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.
> > 
> > Example:
> > 
> > <iq type='set' id='pub1'>
> >   <pubsub xmlns='http://jabber.org/protocol/pubsub'>
> >     <publish node='urn:xmpp:tmp:profile'>
> >       <item>
> >         <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>
> >             </field>
> >           </x>
> >         </profile>
> >       </item>
> >     </publish>
> >   </pubsub>
> > </iq>
> > 
> > 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'>
> >       <item>
> >         <profile xmlns='urn:xmpp:tmp:profile'>
> > 	  <jid>stpeter at jabber.org</jid>
> > 	  <jid>peter at saint-andre.com</jid>
> >         </profile>
> >       </item>
> >     </publish>
> >   </pubsub>
> > </iq>
> 
> Another possibility: a simple name-value format would work just as
> well as x:data, for example:

Possibly. I preffered XML names for this but it depends on what logic
we use in the extensibility stuff (see down this mail).

> <iq type='set' id='pub1'>
>    <pubsub xmlns='http://jabber.org/protocol/pubsub'>
>      <publish node='urn:xmpp:tmp:profile'>
>        <item>
>          <profile xmlns='urn:xmpp:tmp:profile'>
>            <item name='jid' value='stpeter at jabber.org'/>
>            <item name='jid' value='peter at saint-andre.com'/>
>          </profile>
>        </item>
>      </publish>
>    </pubsub>
> </iq>
> 
> > (Btw, the <item/> element was missing in at least one of the
> > examples, if my understanding is correct.)
> 
> Probably. :)
> 
> > 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
> 
> Those are good goals.
> 
> > Possible solution: Don't include any data except short text. This
> > includes:
> >  * User pictures (aka avatars)
> 
> I'm not sure that user pictures are the same as avatars. But perhaps 
> it's better to host such data via HTTP?
> 
> >  * Long 'about' texts
> >  * Piles of unnecessary or uninteresting information
> 
> Unnecessary or uninteresting to whom?

To most people. Better stated: to those that don't explicitly request
them (formerly this was solved by selecting individual fields that is
imho suboptimal).

> > 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
> 
> That seems reasonable.
> 
> > 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.
> 
> What is this "download" stuff? Isn't the data pushed to you via PEP?

Recieve would be a better word, maybe. But it is actually downloaded
by the client when pushed.

> > 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
> > sections:
> > 
> > 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
> 
> I agree that generic contact information may not be useful, at least
> for physical addresses.
> 
> > b) Home information (self-describing)
> > c) Work information (except several elements has the same
> > structure as home info)
> 
> Agreed.
> 
> > 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.
> 
> Yes, it does.
> 
> And let's not forget that we want to make it possible for people to
> add more fields as needed (for gaming or any other application).

Yes, specific uses would have specific URIs. If we need it, there could
be a generic cookie storage XEP.

> > 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 dialog).
> >  * 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
> >    whole.
> 
> Good point. For example if I change jobs all my work contact info
> will change at once.

That's it.

> >  * 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).
> 
> Or perhaps even download only the basic info.

Sure.

> >  * *Extensibility* is achieved by allowing more sections to be added
> >    later.
> 
> What about adding new fields to existing sections?

This is possible with any of the formats.

But I'm against regular changes of the structure for basic info. It will
be presented localized to the users, so it needs changes in the clients.

The older clients will miss newer fields and it will be confusing. We
need to put it in the XEP anyway. We could make careful changes during
the standardization process and generally avoid changes for final and
deployed extensions.

When we need incompatible or confusing changes in deployed sections
(usually in separate XEPs!), I suggest to make a new XEP and obsolete
the old one.

For particular sections where the names are determine by
some entity (as opposed to the standard ones), a simple name-value
syntax would be used (and defined in a single XEP).

Example:

<item source="games.example.net" name="some-game-cookie">value</item>

But I believe such a node and URI belongs to the particular
extension specification. Then clients will only recieve node data they
can use.

> >  * The natural way to add company-specific data (that shouldn't be
> >    usually necessary) is to add special section for internal stuff.
> 
> Probably. I defer to people like Dave Cridland and Joe Hildebrand on 
> that score since they deal with enterprise customers all the time. :)

Ok.

> > 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.
> 
> Why not use URIs? That's what they're for, after all. :)

If we can use URIs, I would be more than happy.

Did you mean:

<im>xmpp:stpeter at jabber.org</im>

or

<im network="network-uri"
service="service-uri">xmpp:stpeter at jabber.org</im>

or better

<im>
    <network>network-uri</network>
    <service>service-uri</service>
    <id>user-id</id>
</im>

Either way, I'd go for simplicity and usability.

> > This applies to:
> >  * 6.4. Telephony Address Data Aspects
> >  * 6.5. Electronic Address Data Aspects
> >  * 6.6. World Wide Web Resource Aspects
> 
> I certainly agree that we need to make extensibility easy, because we 
> know that people will be launching new IM services, telephony
> services, social networking services, microblogging services, and
> everything else.

But keeping strict structure and names will allow us to create a next
great XEP :D - user searching (based on profile data).

> BTW, don't over-estimate the ability of people to know what
> technology powers their services. Does the average user know that
> Google Talk uses XMPP or that Gizmo5 uses SIP? I doubt it.

Adding a paragraph with recommendations for client UI should help it.

A drop down list with either URI schemes or "network" attribute values
would be fine. But... how do we cope with extensibility and with values
that don't belong to any of the specified possibilities? Should we add
the "other" value for "network" attribute? What URI would be used for
this?

These and other issues are reasons I would like to move the contacts
into a separate XEP and give other people more time for their
comments.

> > 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!).
> > 
> > 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
> 
> IMHO dates should be parseable into year, month, and day, so I think
> the current approach is OK.
> 
> > 
> > Third alternative:
> > <birthday>
> >   <year>1960</year>
> >   <month>03</month>
> >   <!-- day is omitted -->
> > </birthday>
> 
> Or that, sure.

Both would work.

> > 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 think that is static geolocation (e.g., for work or home).
> 

Ok, then it could be put to work/home contact sections. I missed this
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.
> 
> I agree in principle.
> 
> > Grey area is the user picture. We should maintain a clear
> > distinction between dynamic avatars and profile images.
> 
> Yes, I think so -- my picture won't change (at least not frequently) 
> whereas my avatar might.

Maybe the clients could use the user picture for both when there's no
avatar.

> > 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.
> 
> Dekuji vam!
> 
> /psa

Rádo se stalo :).

pavlix

-- 

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


More information about the Standards mailing list