[Standards] XEP-0154: User Profile - enterprise vs. simple

Pavel Simerda pavlix at pavlix.net
Wed Jul 30 01:35:00 UTC 2008


Hello,

I'm going to describe the issues we discussed in the jdev MUC room from
my point of view. I'll also try to offer something new :).

dwd pointed out many issues with enterprise-grade solutions and user
profiles. stpeter suggested that these may also affect bigger public
services (e.g. Facebook). I unfortunately missed these issues in my
previous posts.

*For all*: please read at least sections (1) through (3), they're short.


1) Common requirements - getting user profiles

Servers must support *XEP-0163: Personal Eventing via Pubsub* to
push the profile data to the client.

Clients must be able to recieve PEP data, parse the profile data, and
implement UI for viewing it.


2) The simpler case - user publishes his xmpp-based profile

Clients should be able to *set* at least the most basic information. We
need PEP support, profile data structure knowledge and UI for setting
the data.

Note: No additional server requirements, PEP is ok for us.


3) The harder case - server publishes a pre-existing non-xmpp profile
with its own structure on behalf of the user

a) viewing profile

The server has to map the profile to the profile schema as well as it
can and publish it with the PEP. The mapping may not be obvious in some
cases.

The client just views what it gets.

b) setting profile

The server may or may not allow the user to set the profile data
through Jabber. What's more, the server should be able to specify which
fields are read-write and which read-only (or even absent in the data
model).

This requires a totally different approach to setting the profile.


4) The controversy - model versus protocol

In the simple case (2), we define a data model for user profiles. We
also specify methods to retrieve them and publish them. Client authors
design the UI.

But in (3), we actually define an intermediate presentation layer so
other clients understand the data and can present them in the UI. We
omit or fix fields on the server-side and limit the flexibility we
would otherwise offer.

Many backend stores will only offer basic info and contacts. Shall we
drop all other info sections and disallow any future extensions?
I believe we should not!


5) Possible solutions for profile setting

I believe we agree on the need to split the user profile into several
PEP nodes (groups of fields) to avoid unnecessary data flows.

We have to define fixed sets of fields (with value formats) to allow
client authors to create usable viewing user interfaces.

When we start thinking about setting the profile, the controversy shows
itself.

a) We could require user profile setting implementation on both the
client and server side and disallow PEP publishing (this is effectively
what the current version does, it uses PEP syntax but requires special
handling!).

But this means that we cannot use User Profile without server support
which is weird! We're only using PEP events but not publishing features.

This also means the client implementation will be a bit more
complicated than necessary for (2).

The added server-side and client-side complexity may extend the
vcard-temp's usage and defer real-world implementation of XEP-0154.

b) As the setting method for the backend-based profiles is totally
different, it follows we could just ignore it and leave it to a
different protocol/extension.

No required server support (except for backend-based profiles). We're
using PEP's publishing functionality.

Client support only consists of PEP, profile elements and user
interface. A backend-based profile server would reject any publishing
requests with an appropriate error.

Additionally, there would be a disco feature(s) that would warn the
client not to set the profile (as it will be rejected anyway). Usually
we announce features but this would rather be an exception from
implied functionality of PEP. Disco would also say which URIs should
not be set via PEP.

Note: Backend-based settings would be done the same way it is done
without Jabber. Additionally, we can use HTML forms over HTTP (with a
web browser) or any user interaction technology, including
ad-hoc commands.

c) If we stick with (b) but we need the missing protocol for setting
backend-based profile, we can do it.

We can use service discovery to discover support for flexible profile
setting. This disco feature also suggest we SHOULD NOT set the profile
via PEP.

The steps for a client to set a profile could be as follows:
 * we discover server requires special handling of some PEP
   (profile-related) nodes
 * we discover which nodes are to be handled specially
 * we let the user set the non-backend nodes without restriction
 * for a backend-based node, we take following steps:
   * we ask the server which fields we can set
   * we let the user fill in (modify) data (in an appropriate UI)
   * we send the data to the server (finished)

This would be best described by <iq/> stanzas with answers from the
server.

d) Waits for you to write.

Note: (a) is difficult and unnecessary, (b) and (c) both offer good
performance for both (2) and (3). The main difference between them is
that (3) offers a custom protocol with the possibility to create custom
client UIs (generic jabber client authors may be reluctant to do this)
and (2) offers NONE but lets the authors use existing technology.


6) Minor issues

Server should announce which profile-related PEP nodes are to be
handled by special means to avoid confusion.

All PEP nodes that are not announced as specially-handled
(backend-based) should be considered publishable by the client.

The notion of non-publishable (or read-only/server-handled/whatever)
PEP nodes could be solved in the PEP spec (and/or pubsub that I still
have to read better) instead of User Profile XEPs.


Cheers,
pavlix

-- 

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



More information about the Standards mailing list