Support extension fields in vcards

[wichert]

We have some extra data that we want to include in a vcard. Currently ejabberd strips away any fields it does not recognise. This used to be accepted a long time ago (ejabberd 16.06), but was changed when moving to a standard XML parser.

As far as I can see the standards say that this should be possible: XEP-0054 states that the XMPP vcards are based on RFC 2426. The RFC states that you can include private fields if you use an X-prefix.

Describe the solution you'd like I would like ejabberd to preserve X- fields in vcards.

[wichert]

XEP-0292 seems to be relevant to this as well.

[zinid]

The DTD of 'vcard-temp' is defined in Section 9 of XEP-0054, so ejabberd implements it. It's unclear whether it's allowed to include 'X-' elements into 'vCard' element. Raise your question in XMPP Standards mailing list.

[wichert]

I've asked for clarification on the standards list.

[zinid]

I didn't find your email here

[wichert]

Neither did I, even though I sent it after subscribing. It might be stuck in a moderation queue since it was my first post.

[wichert]

FWIW I resent it the the list, but it hasn't shown up this time either. This was the contents of the mail:

Hi everyone,

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.

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?

This appears to be a fairly common question for ejabberd, which allowed unknown fields up to 16.11, after which it started throwing them away.

Regards, Wichert.

1: https://tools.ietf.org/html/draft-dawson-vcard-xml-dtd-01#section-4.2 2: https://tools.ietf.org/html/draft-dawson-vcard-xml-dtd-02#section-4 3: https://tools.ietf.org/html/rfc2426#section-4

[SeveFP]

Hi @wichert, @zinid made me aware of your problem with the mailing list. Seems it might be a problem there, we will check and get back to you with more information.

Thank you @zinid for the ping and sorry for my interjection here :)

---

Problem was solved!

[wichert]

Hi @SeveFP, thanks for looking into that!

[Neustradamus]

@badlop: Can you look this ticket? It is about vCard.

[badlop]

The question was sent to the xmpp standards mailing list. The online archive right now doesn't contain such old messages, but I still have them in my email subscription. There were two responses:

Matthew Wild replied:

Prosody also historically preserved everything (it basically treated the vcard as an XML blob). However now we have moved to vcard4, our compatibility code can obviously only convert fields it knows and understands - therefore any custom fields would also get discarded. However I also see that there is a defined way to handle unknown fields in conversion ( https://tools.ietf.org/html/rfc6351#section-6 ), so it's not impossible to preserve them.

That said, our vcard4 implementation largely handles the submitted vcard as an XML blob also - putting stuff into a custom namespace is totally possible.

Peter Saint-Andre replied:

Perhaps it's time to move forward with XEP-0292?

...

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.

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.

In summary, I guess this issue can be closed as "won't fix"