Subject: [VCARDDAV] [Fwd: I-D Action:draft-gryphon-ldap-schema-vcard4-00.txt]

From: Marc Blanchet <[email-masked]>
Date: Mon, 08 Jun 2009 10:27:02 -0400

FYI. Marc.

-------- Message original --------
Sujet : I-D Action:draft-gryphon-ldap-schema-vcard4-00.txt
Date : Sun,  7 Jun 2009 19:30:01 -0700 (PDT)
De : [email-masked]
Répondre à : [email-masked]
Pour : [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : LDAP Schema for vCard v4.0
	Author(s)       : S. Gryphon
	Filename        : draft-gryphon-ldap-schema-vcard4-00.txt
	Pages           : 33
	Date            : 2009-06-07

This document works to harmonize the vCard directory information card
and Lightweight Directory Access Protocol (LDAP) standards by
extending both standards to support a common directory card entity.

Additional LDAP attributes and object classes, and additional
properties for vCard are defined. A standard mapping process between
the two designed to support vCard's goal of being a transport format
between directories (not just LDAP) is defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gryphon-ldap-schema-vcard4-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Sly Gryphon <[email-masked]>
Date: Wed, 10 Jun 2009 08:38:49 +1000

Suggestions (for my own draft), or actually questions I was unsure of
and wanted to ask others opinions:

1/ TODO: Remove vCard attributes
· Focus on LDAP schema only
· Remove section 5.. put it in vCard 4.0 (if at all)
· Move up calendar attributes section, as superseding RFC.
- This is a TODO which I was already planning, but feel free to discuss
if you think otherwise.

2/ Remove mapping from normative part, e.g. move into appendix.
· Move mapping into non-normative appendix, i.e. intended to support,
however applications may do what they want.
· Keeps things simple, i.e. only have definition of LDAP Schema, i.e.
additional ‘contact’ fields for LDAP.
· Removing the dependency on vCard and putting it into an appendix
decouples the implementation, i.e. the LDAP fields are useful for
themselves (even without vCard).

=> Simple focus is good
=> Removing direct dependency on other standards is good

3/ Would IETF, OpenLDAP or some other organisation like to provide OIDs?
(Currently from a private enterprise I am involved with, but am happy to
use a more central organisation OIDs)

4/ Target implementations (suggestions):
- Schema definition to be released with OpenLDAP.
- Field mappings in Mozilla Thunderbird.
- Would Evolution also implement?

5/ Should name of document be changed, e.g. “LDAP Schema for Contact
Cards”, or “LDAP Schema for Contacts”
- Should object classes be combined or kept separate?
- Should name of object classes change, e.g. “contactCard”,
“contactPerson”, “contactPersonCard” (although I suppose “contact” could
refer to either a person or organization).
- Maybe “contact” for core information and “contactPerson”,
“contactOrganization” for two sub-classes?

---

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Jun 2009 09:19:10 -0400

First, thanks for writing this. This is important work.

DISCLAIMER: My knowledge of LDAP is extremely limited.

Some comments:

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

For example, I'm thinking about a table mapping vCard value types to LDAP
EQUALITY, SYNTAX, and other attributes. Would that be possible?

- How are vCard groups going to be represented in LDAP?

- What about vCard property parameters?

- Why are there many properties that have no equivalent in vCard? For example
spouseName, otherFacsimileTelephoneNumber, etc.

- Please use the same names as in vCard. e.g. sortName vs SORT-STRING

- Do we want to have backward compatibility with inetOrgPerson at all?

- There are some anachronisms with regard to the current status of vCard 4. For
example, section 6.1 mentions the ability of including one vCard object within a
field of another. This doesn't exist anymore.

I think we'll need all the bandwidth of the face-to-face meeting in Stockholm to
resolve most of these issues. Will you be attending?

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Simon Perreault <[email-masked]>
Date: Wed, 10 Jun 2009 09:30:21 -0400

> · Remove section 5.. put it in vCard 4.0 (if at all)

Yes, definitely. I'll comment on the individual attributes that you posted to
the mailing list.

> · Move up calendar attributes section, as superseding RFC.

I don't understand what this means. Probably my English is failing me...

> however applications may do what they want.

On the contrary, I think the mapping should be the primary normative item that
this document describes. This doesn't preclude putting it in an appendix as long
as you refer to it in normative text.

> additional ‘contact’ fields for LDAP.

Not sure what this means.

> themselves (even without vCard).

I disagree. vCard should be the single source defining what a field means, how
it is used, etc. What we need is a 1-to-1 mapping from vCard to LDAP, not a
redefinition of vCard for LDAP.

> => Removing direct dependency on other standards is good

Also, duplication is bad.

> Cards”, or “LDAP Schema for Contacts”

No. I think it is important to mention that this is a mapping of vCard.

Might I suggest "vCard LDAP Schema", to parallel the "vCard XML Schema" draft?
[draft-perreault-vcarddav-vcardxml]

> - Should object classes be combined or kept separate?

Not sure what this means.

> refer to either a person or organization).

I think it should be exactly the same as in vCard. (Adapting case to the LDAP
flavour is OK.)

> “contactOrganization” for two sub-classes?

I think it should have the exact same structure as in vCard. Also note that
vCard can be used to represent things other than people: places, buildings,
groups, etc.

So I would like to see a "vCard" class. ;)

Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 19 Jun 2009 23:27:20 +0100

Hi Sly,

> use a more central organisation OIDs)

You can request OID allocation from IANA.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 20 Jun 2009 20:33:58 +0100

>First, thanks for writing this. This is important work.
Yes, indeed.

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

>EQUALITY, SYNTAX, and other attributes. Would that be possible?
I think producing such table would be worth a try.

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

>- What about vCard property parameters?
Good question.

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

>field of another. This doesn't exist anymore.
Right.

>resolve most of these issues.
>
Agreed.

>Will you be attending?

---

From: Simon Perreault <[email-masked]>
Date: Sat, 20 Jun 2009 15:50:07 -0400

> (even not invented ones) to LDAP attributes, then I don't think it would

Of course, I don't expect that. I didn't do it that way with my XML 
mapping either.

But I think it is better to first explain in general how vCard objects 
(properties, parameters, groups, etc.) are mapped to their LDAP 
equivalent, and afterwards succinctly list the details for all 
predefined vCard objects.

I'm sure we agree. I'm just reiterating in a different way to try to 
engage people in the discussion. ;)

Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 20 Jun 2009 20:49:19 +0100

Hi Sly,

Sly Gryphon wrote:

> Focus on LDAP schema only

Yes.

> Remove section 5.. put it in vCard 4.0 (if at all)

Yes

Some other quick comments after scanning the document:

> 3.6. 'homeCountry'
>
>    The 'homeCountry' (Friendly Country Name) attribute specifies names
>    of countries for the home address of the entry in human-readable
>    format and used in conjunction with 'homeCountryName', which is
>    limited to 2 character ISO codes.

2 ways to represent something is bad. This creates silly states (e.g. if 
homeCountry and homeCountryName contradict each other).

I think homeCountry should go (homeCountryName seems to be Ok). It can 
be derived algorithmically from the registry of 2 letter country codes, 
this list can be localized, etc.

> 3.18. 'otherMailbox'
>
>    The 'otherMailbox' (rfc822mailbox) attribute type holds Internet mail
>    addresses in Mailbox [RFC2821] form (e.g., [email-masked]).
>
>      ( 1.3.6.1.4.1.33592.1.3.18 NAME 'otherMailbox'
>         EQUALITY caseIgnoreIA5Match
>         SUBSTR caseIgnoreIA5SubstringsMatch
>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

This attribute is already defined and it is using a different OID (see 
<http://www.iana.org/assignments/ldap-parameters>):

otherMailbox                          A  0.9.2342.19200300.100.1.22   [RFC1274]

>    The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
>    'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
>    described in [RFC4517].
>
>    Note: See the 'mail' field from [RFC2798] for comments on the
>    implementation of this field.

 [...]

> 3.24. 'tzid'
>
>    The usual time zone for the contact represented by the directory
>    entry. Time zones SHOULD be specified using the time zone identifiers
>    from [UTS35].
>
>      ( 1.3.6.1.4.1.33592.1.3.24 NAME 'tzid'
>         EQUALITY caseIgnoreMatch
>         SUBSTR caseIgnoreSubstringsMatch
>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
>
>    The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
>    'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
>    in [RFC4517].
>
>    Examples: "Australia/Sydney", "America/Los_Angeles", "Europe/London".

I don't see why both tzid and tzOffset are needed. Keep one or the other.

> 3.25. 'tzOffset'
>
>    The usual time zone offset differential for the person. This does not
>    take into account any daylight savings adjustment.

---

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

Simon Perreault wrote:

> Of course, I don't expect that.

Ok, I am glad to confirm that.

> I didn't do it that way with my XML mapping either.

As a side note: defining algorithmic mapping in XML would be easier, as 
in XML there is full control over element names.

> I'm sure we agree.

Yes.

> I'm just reiterating in a different way to try to engage people in the 
> discussion. ;)

Sure :-)