OpenFire vCard Properties

The vCard mappings served up my the OpenFire instant messaging server are found in the ldap.vcard-mapping property. In the absence of an accepted standard, the developers came up with their own idiosyncratic schema for this. Details below.

The following was tested with OpenFire 3.7.1 on a RHEL 6 server and Spark 2.6.3 client on Windows.

Here is the raw CDATA stored in the ldap.vcard-mapping property (as shown in on the OpenFire Admin Console System Properties page):

<![CDATA[<vCard xmlns="vcard-temp"><N><FAMILY>{sn}</FAMILY><GIVEN>{givenname}</GIVEN></N><NICKNAME>{cn}</NICKNAME><EMAIL><INTERNET/><USERID>{mail}</USERID></EMAIL><FN>{cn}</FN><PHOTO><TYPE>image/jpeg</TYPE><BINVAL>{jpegPhoto}</BINVAL></PHOTO><ADR><HOME/><STREET>{homePostalAddress}</STREET></ADR><ADR><WORK/><STREET>{street}</STREET><LOCALITY>{l}</LOCALITY><REGION>{st}</REGION><PCODE>{postalCode}</PCODE><CTRY>{c}</CTRY></ADR><TEL><HOME/><VOICE/><NUMBER>{homePhone}</NUMBER></TEL><TEL><WORK/><VOICE/><NUMBER>{telephoneNumber}</NUMBER></TEL><TEL><WORK/><CELL/><NUMBER>{mobile}</NUMBER></TEL><TEL><WORK/><PAGER/><NUMBER>{pager}</NUMBER></TEL><TEL><WORK/><FAX/><NUMBER>{facsimileTelephoneNumber}</NUMBER></TEL><TITLE>{title}</TITLE><ORG><ORGNAME>{o}</ORGNAME><ORGUNIT>{ou}</ORGUNIT></ORG></vCard>]]>

Note that the above is formatted without any linefeeds or carriage returns. This is intentional. Linefeeds or carriage returns will cause these mappings to fail.

Here is the same configuration formatted for human eyes:

<![CDATA[
<vCard xmlns="vcard-temp">
 <N>
    <FAMILY>{sn}</FAMILY>
    <GIVEN>{givenname}</GIVEN>
 </N>
 <NICKNAME>{cn}</NICKNAME>
 <EMAIL>
    <INTERNET/>
       <USERID>{mail}</USERID>
 </EMAIL>
 <FN>{cn}</FN>
 <PHOTO>
    <TYPE>image/jpeg</TYPE>
       <BINVAL>{jpegPhoto}</BINVAL>
 </PHOTO>
 <ADR>
    <HOME/>
       <STREET>{homePostalAddress}</STREET>
 </ADR>
 <ADR><WORK/>
    <STREET>{street}</STREET>
    <LOCALITY>{l}</LOCALITY>
    <REGION>{st}</REGION>
    <PCODE>{postalCode}</PCODE>
    <CTRY>{c}</CTRY>
 </ADR>
 <TEL>
    <HOME/>
       <VOICE/>
          <NUMBER>{homePhone}</NUMBER>
 </TEL>
 <TEL>
    <WORK/>
       <VOICE/>
          <NUMBER>{telephoneNumber}</NUMBER>
 </TEL>
 <TEL>
    <WORK/>
       <CELL/>
          <NUMBER>{mobile}</NUMBER>
 </TEL>
 <TEL>
    <WORK/>
       <PAGER/>
          <NUMBER>{pager}</NUMBER>
 </TEL>
 <TEL>
    <WORK/>
       <FAX/>
          <NUMBER>{facsimileTelephoneNumber}</NUMBER>
 </TEL>
 <TITLE>{title}</TITLE>
 <ORG>
    <ORGNAME>{o}</ORGNAME>
    <ORGUNIT>{ou}</ORGUNIT>
 </ORG>
</vCard>
]]>

The order in which elements of each field are implemented IS significant. For example, the <N> element requires the order <FAMILY></FAMILY><GIVEN></GIVEN>. Reversing that order will break it.

Known working field mappings:

Field Name, XML Element, LDAP Attribute

Last Name, <N/><FAMILY/>, sn

First Name, <N/><GIVEN/>, givenname

E-mail, <EMAIL/><INTERNET/><USERID/>, mail

Full Name, <FN/>, cn

Work Street, <ADR/><WORK/><STREET/>, street

Work City, <ADR/><WORK/><LOCALITY/>, l

Work State, <ADR/><WORK/><ST/>, st

Work Postal Code, <ADR/><WORK/><PCODE/>, postalcode

Work Country, <ADR/><WORK/><CTRY/>, c

Work Phone, <TEL/><WORK/><VOICE/><NUMBER/>, telephonenumber

Work Cell, <TEL/><WORK/><CELL/><NUMBER/>, mobile

Work Fax, <TEL/><WORK/><FAX/><NUMBER/>, facsimiletelephonenumber

Title, <TITLE/>, title

Company, <ORG/><ORGNAME/>, o

Department, <ORG/><ORGUNIT/>, ou