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

Peter Saint-Andre stpeter at jabber.org
Mon Dec 15 18:40:47 UTC 2003

On Mon, Dec 15, 2003 at 06:12:50PM +0100, Jacek Konieczny wrote:
> 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
> clients. 
> Current proposal - JEP 121:
> - misses some vCard fields

That will be fixed.

> - forbids some usage of vCard fields (no binary data in photo/sound)

That's up for discussion. How large is this binary data?

> - breaks vCard structured types (like N or ADR) into separate fields
> in a way that cannot be reliably reconstructed into vCard and vice versa

I was thinking yesterday about doing things like this:

<bit key='vCard.email.work'>stpeter at jabber.org</bit>

Where "work" is a qualifier such as is used in Dublin Core.

> - fails when some entity has two work addresses, or address that is
>   neither home or worg and in similar cases with other field/values.

You can have multiple infobits with the same name. Perhaps that is not
called out strongly enough.

> 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.

Now, we need to understand that infobits is *not* primarily intended to
replace vCard, it is intended to supply a generic metadata syntax for
Jabber communications. It enables you to provide metadata about anything
on the Jabber network: groupchat rooms, users, pubsub nodes, servers, 
services, commands (JEP-0050), etc. The metadata semantics may be
defined by Dublin Core, FOAF, Liberty Alliance, the IETF, etc. But
whatever representation those people choose (RDF, XML, etc.) can be
mapped into infobits.

So I agree that we need to provide clear mappings. I have done that for
Dublin Core. I have not yet done that for vCard. Which is why there is
more work to do on this JEP.


More information about the Standards mailing list