[Standards] Initial thoughts on vCard4 XMPP extension

Peter Saint-Andre stpeter at stpeter.im
Thu Mar 18 11:55:51 UTC 2010

On 3/18/10 4:54 AM, Laurent Eschenauer wrote:
> 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
> this.

We definitely want to move forward on this.

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

I need to look at the merge logic again. Perhaps it's not as scary as I

>>> 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
>>> <query/><publish/><merge/>.
>>> http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-09#section-7
>> 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.

That is the original Jabber tradition, yes.

>>> 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).
>> Probably.
> 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.
>>> http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-09#section-6.4.3
>> Yes.
>>> 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.

Yes, more discussion is needed...


Peter Saint-Andre

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

More information about the Standards mailing list