[standards-jig] UPDATED: JEP-0121 (Initial Infobits Registration)

Jacek Konieczny jajcus at bnet.pl
Mon Dec 15 17:12:50 UTC 2003

On Sun, Dec 14, 2003 at 11:03:28PM -0600, Peter Saint-Andre wrote:
> JEP-0121 (Initial Infobits Registration) has been updated to track
> changes in JEP-0120, provide a more complete vCard mapping, and reflect
> further research into Dublin Core. The changelog for Version 0.5 is:
>    Added more vCard mappings; specified prefixes for some infobits;
>    defined registry submission. (psa)
> http://www.jabber.org/jeps/jep-0121.html

I know vcard-temp was bad, but this is, at some points, even worse.

vcard-temp was supposed to be XML version of RFC2426 vCard MIME
Directory Profile. And it was mostly compatible with that RFC, so 
it could be used to integrate existing address-book software with Jabber

Current proposal - JEP 121:
- misses some vCard fields
- forbids some usage of vCard fields (no binary data in photo/sound)
- breaks vCard structured types (like N or ADR) into separate fields
in a way that cannot be reliably reconstructed into vCard and vice versa
- fails when some entity has two work addresses, or address that is
  neither home or worg and in similar cases with other field/values.

RFC2426 vCard could be easily and in most cases without any loss mapped
into vcard-temp, and vcard-temp into RFC2426 vCard. This is no longer
possible for JEP-121.

IMHO a better solution for vcard problem would be:
- redefine a schema for XML vCard representation in a new JEP with new
  namespace name
- define protocol for requesting/publishing information like vCards (but
  not limited to vCards)
- formally extend vCard MIME Directory Profile via IETF. This may be the
  hardest thing. Until it is not done, jabber/XMPP fields still may be
  represented in RFC2426 vCards using "x-jid" field names or similar.


More information about the Standards mailing list