[Standards] Clarification for XEP-0054: private fields

Peter Saint-Andre stpeter at mozilla.com
Fri Sep 20 18:31:15 UTC 2019

On 9/19/19 1:01 AM, Wichert Akkerman wrote:

> I am looking for a clarification on XEP-0054. The history description
> for the XEP mentions that it essentially encapsulates
> draft-dawson-vcard-xml-dtd-01 over XMPP, with changes to using
> xuppercase for elements and adding JABBERID and
> DESC. draft-dawson-vcard-xml-dtd-01 also documents private fields [1],
> with a basic example:
>   <vCard
>         VERSION="3.0"
>         PRODID="-//HandGen//NONSGML vGen v1.0//EN">
>    <fn>Frank Dawson</fn>
>    <n>  <family>Dawson</family>
>         <given>Frank</given></n>
>    <tel tel.type="WORK MSG">+1-617-693-8728</tel>
>    <x-lotus-blood-type>O+</x-lotus-blood-type>
>    </vCard>
> Unfortunately it forgot to include this in the DTD. This was extended
> later in draft 2 [2], and fully defined in the DTD for RFC 2426.

The vcard-temp namespace has always been a mess and its origins are hazy
(it was cooked up even before I joined the project in November 1999). I
would not rely too much on whatever was documented in draft-dawson-* or
described in XEP-0054.

> My question is: are implementation of XEP-0054 supposed to a) strictly
> use the DTD from XEP-0054, and thus required throw away any extra
> elements not mentioned there, b) support private fields since they are
> mentioned in draft-dawson-vcard-xml-dtd-01, or c) be liberal and
> preserve unknown elements?

Sadly, I don't think we can say definitively what to do. Typically we
don't consider DTDs and schemas to be normative and we have often not
strictly documented extension points such as the private field you've
noted in draft-dawson-vcard-xml-dtd-01.

Personally I think it's best for us to migrate to vCard4 (which as
Matthew notes has a better-defined extension mechanism) and I would
favor discarding unknown elements in the context of vcard-temp because
there's a possibility of abuse.


More information about the Standards mailing list