Subject: Re: [VCARDDAV] VCARDDAV Digest, Vol 22, Issue 94

From: Peter Mogensen <[email-masked]>
Date: Sat, 20 Jun 2009 21:54:58 +0200

Alexey Melnikov wrote:
>> - Overall it seems like a redefinition of vCard in LDAP terms instead of a
>> mapping. The draft should focus on a generic mapping. There is no need to
>> enumerate and describe all the properties once again.
>>
> Simon, if you are talking about algorithmic mapping of vCard properties 
> (even not invented ones) to LDAP attributes, then I don't think it would 
> be possible.

We'll never be able to completely (1-1) map the data-model of vCard to 
LDAP without introduction of new LDAP extensions.
We would however be able to do a more generic mapping, but it would 
really require dropping compatibility with inetOrgPerson.

"sn" being mandatory in inetOrgPerson makes it very difficult to use for 
  ad-hoc address books. Remember that it cannot be the empty string.

>> - How are vCard groups going to be represented in LDAP?
>>
> Most likely as multivalued LDAP attributes (e.g. as a list of names of 
> people)

Again... groupOfNames cannot be empty. That makes compatibility with the 
whole inetOrgPerson universe hard and costly in terms of legacy 
restrictions.

>> - What about vCard property parameters?
>>
> Good question.

LDAP attribute options can do some of them, but not all.
They cannot handle "VALUE", but they can do most "TYPE".
And they can handle "PREF=1".
PREF in general would be hard to handle since ordered LDAP attribute 
values are not standard. (AFAIK)

>> - Do we want to have backward compatibility with inetOrgPerson at all?
>>
> Personally I think this might be desirable, as inetOrgPerson is widely 
> used to describe a person with email address.

I would suggest not.
In our setup we have concluded that inetOrgPerson is best supported by a 
read-only proxy which map the underlying datastore to the most important 
inetOrgPerson attributes.
There's often no point in having read-write access to inetOrgPerson 
data, since most client don't support that anyway. (not in a consistent 
way, anyway).

/Peter

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 20 Jun 2009 21:04:52 +0100

Hi Peter,

Peter Mogensen wrote:

>> Simon, if you are talking about algorithmic mapping of vCard 
>> properties (even not invented ones) to LDAP attributes, then I don't 
>> think it would be possible.
>
> "sn" being mandatory in inetOrgPerson makes it very difficult to use 
> for  ad-hoc address books. Remember that it cannot be the empty string.

Right. This comes from the "person" object class.
I guess the next best thing is to reuse as many attributes defined by 
inetOrgPerson as possible.

>> Most likely as multivalued LDAP attributes (e.g. as a list of names 
>> of people)
>
> Again... groupOfNames cannot be empty. That makes compatibility with 
> the whole inetOrgPerson universe hard and costly in terms of legacy 
> restrictions.

It doesn't have to be groupOfNames. I was talking about doing this in 
LDAP in general terms.

 [...]

---

From: Peter Mogensen <[email-masked]>
Date: Sat, 20 Jun 2009 22:16:05 +0200

> inetOrgPerson as possible.

Doing that, one has to pay special attention to details in syntax
constraints.

Example:
"mail" is 1.3.6.1.4.1.1466.115.121.1.26 (IA5 String)

However... modern domain names can have non-ascii letters.
Of course, you could store the punicoded version, but that should really 
be an implementation detail of DNS.

You'll find a lot of such small "annoyances" when trying to reuse 
inetOrgPerson attributes.

Another example:
You cannot use "displayName" for NICKNAME, sine displayName is SINGLE-VALUE.

/Peter

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 20 Jun 2009 21:18:15 +0100

Peter Mogensen wrote:

> Of course, you could store the punicoded version, but that should 
> really be an implementation detail of DNS.

This is a bad example, as email address syntax as defined in RFC 5322 
doesn't allow non US-ASCII.

> You cannot use "displayName" for NICKNAME, sine displayName is 

Right.

---

From: Peter Mogensen <[email-masked]>
Date: Sat, 20 Jun 2009 22:37:08 +0200

> doesn't allow non US-ASCII.

Hmm... Since the vCard4 draft explicitly references RFC5322, I'll grant 
you that argument. :)
"mail" values must be punicoded, then.

Another one then...
vCard4 organizes ORG like O;OU1;OU2;OU3....

LDAP "ou" cannot (unless non standard features are used) be sorted.

In general structured values could pose a serious problem to reusing 
inetOrgPerson attributes.

There's really no LDAP mechanish for mapping several ADR properties and 
maintaining the association between their structural parts.

One solution though would be to define and special LDAP syntax for 
structured values and store ADR properties in attributes like:

vcard4ADR: po<US>ext<US>street<US>locality<US>region<US>pcode<US>country

Where <US> is some kind of field separator.
Personally I use ASCII \x1F (Unit Separator) which is kind of meant for 
such use. Of course, it's non-printable, but it really takes away a lot 
of escaping annoyances.

/Peter