[standards-jig] UPDATED: JEP-0121 (Initial Infobits Registration)
michael at aurora.gen.nz
Mon Dec 15 22:51:14 UTC 2003
I agree with this. Lets remember that a lot of work over many years has
gone into the open vCard format, and now it appears that we are trying to
invent our own similar-but-different format overnight.
Whatever we come up with, should be directly mapable to a standard vCard
(for humans at least). It needs to follow the same structure as a vCard -
ie if vCard has nested data, we should not be using a flat data structure.
What is really missing from the current vCard solution IMO is some sort of
ACL that would allow me to protect or grant access to certain fields to
public or people on my roster (pubsub?) and a way to be able to request
the data a field or fields at a time.
> 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