[standards-jig] UPDATED: JEP-0121 (Initial Infobits Registration)
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
> 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