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

Peter Saint-Andre stpeter at stpeter.im
Thu Jul 31 14:23:36 UTC 2008


Pavel Simerda wrote:
> 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.

For attributes we've defined in XEP-0154, the mapping should be 
straightforward. For attributes we haven't defined in XEP-0154, we 
either add them to XEP-0154 or leave the mapping up to the application.

> 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).

We can do this with x:data, because we can specify that some fields are 
*fixed*, for example:

<profile xmlns='urn:xmpp:tmp:profile'>
   <x xmlns='jabber:x:data' type='result'>
     <field var='FORM_TYPE' type='hidden'>
       <value>urn:xmpp:tmp:profile</value>
     </field>
     <field type='fixed' var='common_name'>
       <value>Peter Saint-Andre</value>
     </field>
     <field type='text-single' var='nickname'>
       <value>stpeter</value>
     </field>
   </x>
</profile>

> This requires a totally different approach to setting the profile.

Maybe. :)

> 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.

I don't see why the case of more complex data requires an intermediate 
presentation layer etc.

> 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!

Agreed.

> 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.

+1

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

See above on <field type='fixed'> -- x:data helps us here.

> 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.

I think an application can specify some fields as fixed and ignore any 
changes generated by the client. But then the PEP service needs to be a 
bit specialized because it's not just publishing payloads but inspecting 
the XML of the payload to see if it matches some business rules.

> 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.

I think this would be part of the form.

> 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.

I'm not sure of the best location to solve this -- PEP itself (your 
proposal seems complex to me) or the x:data form. Right now I prefer the 
latter. Perhaps it's time for another groupchat about this in the jdev 
room. :)

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080731/0d9cb040/attachment.bin>


More information about the Standards mailing list