[Standards] Initial thoughts on vCard4 XMPP extension
laurent at eschenauer.be
Thu Mar 18 10:54:54 UTC 2010
Thanks Peter for the feedback on vcard4. Comments below.
We'll start implementing and experimenting with these concepts on our
side, so if anyone else has feedback, I would be happy to hear now. If
things work well, I'll draft the XEP reflecting the way we do things
and we can iterate on the document if you guys want to move forward on
>> 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. :)
We can call it "update" instead of "merge" if you prefer :-) I
personally think that merging can be hell when we talk about merging
complete address books (multiple vcards). But in this case, it is in
fact a simple update of well identified fields.
>> 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.
Supporting extension will inevitably add complexity. The question is
where: client or server side ? I would favor a richer server API and a
larger server responsibility in guaranteeing validity of the profile.
>> 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. :(
See previous point.
>> 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).
Another argument in favor of selective query is bandwidth/processing
constraints in mobile use cases. Most of the time, our client fetches
someone profile just to get the avatar, the description and maybe an
email. If the profile gets bigger because of extensions, this will be
even more important.
>> 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.
Hmm. I would love to hear more on how you see this being done with
PEP. I will post this question (and a reflection on the micronlog pep
xep) in another thread.
>> 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.
More information about the Standards