[Standards] Initial thoughts on vCard4 XMPP extension

Peter Saint-Andre stpeter at stpeter.im
Mon Mar 15 18:12:29 UTC 2010

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

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

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

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.



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/20100315/5f70f808/attachment.bin>

More information about the Standards mailing list