Hello, 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.
I have a few suggestions we already discussed in the jdev room and elsewhere. It will be long. Sorry. But please read on if you're interested in replacing the vcard by something both more powerful and efficient. 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. 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>[EMAIL PROTECTED]</value> <value>[EMAIL PROTECTED]</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>[EMAIL PROTECTED]</jid> <jid>[EMAIL PROTECTED]</jid> </profile> </item> </publish> </pubsub> </iq> (Btw, the <item/> element was missing in at least one of the examples, if my understanding is correct.) 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 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. 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 b) Home information (self-describing) c) Work information (except several elements has the same structure as home info) 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. 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. * 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). * *Extensibility* is achieved by allowing more sections to be added later. * The natural way to add company-specific data (that shouldn't be usually necessary) is to add special section for internal stuff. 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!). 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 Third alternative: <birthday> <year>1960</year> <month>03</month> <!-- day is omitted --> </birthday> 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 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. Grey area is the user picture. We should maintain a clear distinction between dynamic avatars and profile images. 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. Cheers, Pavel Simerda -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
