[Standards] XEP-0154: User Profile - enterprise vs. simple
pavlix at pavlix.net
Thu Jul 31 18:07:44 CDT 2008
this is just reactions to your post, I will later summarize what I have
and include some examples so we can advance from theory to something
On Thu, 31 Jul 2008 08:23:36 -0600
Peter Saint-Andre <stpeter at stpeter.im> wrote:
> > 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.
Just to remind... this means all information the client author
> > Note: No additional server requirements, PEP is ok for us.
I would like to keep this as simple as possible, with no support from
the server except PEP and client just reads/stores PEP data.
> > 3) The harder case - server publishes a pre-existing non-xmpp
> > profile with its own structure on behalf of the user
> > 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'>
You hit the point. Data forms do a good job for user interaction and
forms. This is why we have them, isn't it?
Moreover, as backend-based store *already requires* some complexity on
the server, there is no problem in implementing it there.
Some client authors, on the other hand, would not like to implement all
this stuff. But there's a simple solution to that.
Implement it on the server side and use what clients already can!
* XEP-0050: Ad-Hoc Commands
* XEP-0004: Data Forms
This way we don't even need to specify the protocol. Though we may want
to (I don't know) like it's done in XEP-0133: Service Administration
> > 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.
Because we don't want to put SQL, LDAP and all other backend
reperesentation into XMPP. By the word "intermediate" I mean the XMPP
representation, because it sits between the backend (e.g. SQL) store and
the client's user interface (e.g. a graphical window).
Actually it's not more complex data but more complex storage (something
is in the backend store, something is in the PEP store.
> > 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.
Thanks for confirmation.
> > 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.
Fixed in a different meaning. Fixed sets of fields - the
sections/groups of fields that are defined so that clients know what
data they will get.
> > 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
I don't think we should misuse PEP syntax for things it cannot do
itself. That's why I don't like (a).
I included it for completeness.
> > 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.
It cannot be if we don't break the PEP way (use case (2)).
Breaking the simple case means complexity for all clients.
> > 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. :)
We cannot do this with x:data because in PEP, there's no x:data actually
read by the client.
It's not as complex as it may seem (I'm still putting my thougts
together so forgive me if I forget to write something or write too
It's just a single list of nodes that shouldn't be published by the
client. Service discovery looks like a good method to me.
Another possibility would be a single attribute (e.g. read-only) for
every published node that would tell you if you can change it or not.
Any of these two would work well.
Jabber & Mail: pavlix(at)pavlix.net
More information about the Standards