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>[EMAIL PROTECTED]</value>
<value>[EMAIL PROTECTED]</value>
</field>
<field var='msn_id'>
<value>[EMAIL PROTECTED]</value>
</field>
<field var='yahoo_id'>
<value>psaintandre</value>
</field>
In the words of my proposal, this is:
<jid>[EMAIL PROTECTED]</jid>
<jid>[EMAIL PROTECTED]</jid>
<msn_id>[EMAIL PROTECTED]</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">[EMAIL PROTECTED]</im>
<im network="xmpp">[EMAIL PROTECTED]</im>
<im network="msn">[EMAIL PROTECTED]</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.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
