[Standards] Initial thoughts on vCard4 XMPP extension

Laurent Eschenauer laurent at eschenauer.be
Fri Mar 12 20:35:18 UTC 2010


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.

Cheers,

-Laurent

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

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

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

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.

7. Should we bring vcard based avatars (XEP-0153) in this or leave it
in vcard-temp for now ?

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.

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 mailing list