[Standards] Initial thoughts on vCard4 XMPP extension
ali.sabil at gmail.com
Wed Mar 17 14:59:31 CDT 2010
On Mon, Mar 15, 2010 at 7:12 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 3/12/10 1:35 PM, Laurent Eschenauer wrote:
>> Hi all,
>> As discussed previously, I've started looking at a potential vcard4
>> extension. Here are some initial thoughts. I'm sure that I missed a
>> lot of things, having just looked at these specs for the first time.
>> Feel free to add/comment. Once we had some more discussions, I'm happy
>> to summarize the feedback and have a go at a first draft.
>> 1. the introduction of extensibility is a good thing, it will enable
>> clients, servers and applications to innovate in the profile space,
>> adding new fields to support new kind of use cases (e.g. social
>> networking related fields, private enterprise fields, etc.). We should
>> aim at supporting it is as much as possible.
>> 2. vCard-4 introduces the notion of 'merge' and PID to uniquely
>> identify a property in the vcard.
> I think those notions might have been defined before, but now they are
> specified more completely.
> The merge stuff scares me. :)
>> Supporting this would enable a
>> client to add or modify a field without having to resubmit the whole
>> profile. I therefore suggest to move away from the 'simple'
>> iq-get/iq-set pattern of vcard-temp and have something like
> Possibly. This is something we need to discuss, because it adds much
> more complexity.
>> 3. the server can't simply store the vCard as a text blob, it will
>> have to be aware of the content, be able to merge two vcards, retrieve
>> a property and update it, etc... In addition, I suggest the server
>> also do validation and enforce some rules with respect to extensions
>> (you don't want to see the profile creep to insane size because a
>> client keeps on adding extensions).
> More complexity. :(
>> 4. because of extension, profile sizes can become much larger anyway.
>> Allowing the query to be selective will help (e.g. a client may just
>> be interested in the name of the user).
>> 5. the JABBERID of vCard-temp is not required anymore, can be replaced by IMPP.
>> 6. I did not find replacement for the DESC property. A lot of other
>> "social properties" are also missing of vcard (see portable contacts
>> for ideas; DESC is equivalent of NOTE in PoCo). It may be worthwile to
>> suggest properties name and namespace in the spec to avoid
>> fragmentation. I don't know if there is a repository of 'vcard
>> extensions' somewhere. We could start.
> There are already discussions about this on the IETF list.
>> 7. Should we bring vcard based avatars (XEP-0153) in this or leave it
>> in vcard-temp for now ?
> Or move to XEP-0084?
> Good questions. I'm not sure yet.
>> 8. I personally don't want to show all fields to all users and would
>> like to be able to specify rules on a per field basis. E.g. birthday
>> only visible to people on my roster with subscription both, phone
>> number only visible to people tagged 'Friend' in my roster, etc...
>> We'll eventually propose to add our acl extension to this.
> And yet more complexity. :(
> PEP gives us a relatively simple approach to that kind of behavior.
>> 9. vcard and PEP ? I can imagine some use cases where you want to be
>> notified of changes in someone profile. I wonder if there is any
>> reasons to try to link this to a PEP node. I don't say this should be
>> part of the spec, but the use case is worth keeping in mind.
I am not quite sure if vCard is a good format in the first place, what
about moving forward to things like the OpenSocial format for
specifying profiles ?
More information about the Standards