[Standards] Proposed XMPP Extension: vCard4 Over XMPP

Waqas Hussain waqas20 at gmail.com
Sat Feb 26 06:12:04 UTC 2011

On Fri, Feb 25, 2011 at 11:30 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> On 2/12/11 4:26 PM, XMPP Extensions Editor wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>> Title: vCard4 Over XMPP
>> Abstract: This document specifies an XMPP extension for use of the
>> vCard4 XML format in XMPP systems, with the intent of obsoleting the
>> vcard-temp format.
>> URL: http://www.xmpp.org/extensions/inbox/vcard4.html
>> The XMPP Council will decide at its next meeting whether to accept
>> this proposal as an official XEP.
> BTW, I've fixed some errors in the examples, so the latest version is
> now 0.0.4. Reload http://www.xmpp.org/extensions/inbox/vcard4.html as
> necessary.
> Peter

Many more errors in the examples. The prefix element's end tag is
invalid. Fixing that makes the XML valid. Running a Relax NG validator
on that brings up many errors.

<additional/> required before <prefix/> in <n/>

As meaningful as the following is, "love" is not a valid organization
type. <type/> can only contain "work" or "home".

Same for the <type/> in <adr/>.

<pobox/> and <ext/> are required before <street/>

<region/> and <code/> are required before <country/>

<class/> is no longer allowed.

Here's the example fixed:

<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
  <fn><text>Romeo Montague</text></fn>
    <street><text>123 Capulet Way</text></street>
    <text>romeo at montague.lit</text>

Now some comments. This was the first time I saw the vcard4 XML
schema. I was surprised at how it requires elements (even if they are
empty), and requires they be in a specific order. Just for amusement,
I proceeded to run the validator on the two largest examples within
the vcardxml draft. As I half expected, they failed.

The schema seemed long enough that I gave up on figuring out how
compatible this is with the existing vcard-temp. It looks like mapping
vCard4, vcard-temp, User Avatar, etc to a single backend is going to
be much more work than I had anticipated.

Waqas Hussain

More information about the Standards mailing list