From: http://www.ietf.org/internet-drafts/draft-gryphon-ldap-schema-vcard4-00.txt Title: LDAP Schema for vCard v4.0 Reference: IETF Network Working Group, Internet Draft 'draft-gryphon-ldap-schema-vcard4-00.txt' Date: June 8, 2009 I-D Tracker: http://ietfreport.isoc.org/idref/draft-gryphon-ldap-schema-vcard4/ Tools: http://tools.ietf.org/html/draft-gryphon-ldap-schema-vcard4-00 (HTML) See also: IETF vCard and CardDAV (VCARDDAV) Working Group Charter http://www.ietf.org/html.charters/vcarddav-charter.html IETF vCard and CardDAV Working Group Status Pages http://tools.ietf.org/wg/vcarddav/ IETF vCard and CardDAV Wiki http://www.vcarddav.org/wiki VCARDDAV: vCard and CardDAV Engineering Discussion List https://www1.ietf.org/mailman/listinfo/vcarddav IETF Applications Area http://www.ietf.org/html.charters/wg-dir.html#Applications%20Area The IETF Applications Area Web Site http://www.apps.ietf.org/ XEP-0054: vcard-temp (vCard-XML format used within the Jabber community as of 2008-07-16) http://xmpp.org/extensions/xep-0054.html vCard XML Schema http://tools.ietf.org/html/draft-perreault-vcarddav-vcardxml-00 Microformats: Suggestions for vCard Revision http://microformats.org/wiki/vcard-suggestions ============================================================================== Working Group Name S. Gryphon Internet Draft Gryphon Technology Intended status: Informational June 8, 2009 Expires: December 2009 LDAP Schema for vCard v4.0 draft-gryphon-ldap-schema-vcard4-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 8, 2009. S.Gryphon Expires December 8, 2009 [Page 1] Internet-Draft LDAP Schema for vCard June 2009 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract 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. Table of Contents 1. Introduction ................................................ 4 1.1. Background ............................................. 4 2. Conventions used in this document ........................... 4 3. LDAP Attribute Types......................................... 4 3.1. 'anniversary' .......................................... 5 3.2. 'birthDate' ............................................ 5 3.3. 'category' ............................................. 5 3.4. 'childName' ............................................ 6 3.5. 'gender' ............................................... 6 3.6. 'homeCountry' .......................................... 6 3.7. 'homeCountryName' ...................................... 7 3.8. 'homeHouseIdentifier' .................................. 7 3.9. 'homeLocalityName' ..................................... 8 3.10. 'homePostalCode' ...................................... 8 3.11. 'homePostOfficeBox' ................................... 8 3.12. 'homeStateName' ....................................... 9 3.13. 'homeStreet' .......................................... 9 3.14. 'latLong' ............................................. 9 3.15. 'logo' ............................................... 10 3.16. 'otherFacsimileTelephoneNumber' ...................... 10 3.17. 'otherHomePhone' ..................................... 11 3.18. 'otherMailbox'........................................ 11 S. Gryphon Expires December 8, 2009 [Page 2] Internet-Draft LDAP Schema for vCard June 2009 3.19. 'otherMobile' ........................................ 11 3.20. 'otherPager' ......................................... 12 3.21. 'otherTelephone' ..................................... 12 3.22. 'sortName' ........................................... 12 3.23. 'spouseName' ......................................... 12 3.24. 'tzid' ............................................... 13 3.25. 'tzOffset' ........................................... 13 4. LDAP Object Classes ........................................ 14 4.1. 'basicDirectoryCard' .................................. 14 4.2. 'directoryCard'........................................ 14 4.3. 'extendedDirectoryCard' ............................... 15 5. vCard Schema Extensions .................................... 15 5.1. AN Type Definition .................................... 15 5.2. CAR Type Definition ................................... 16 5.3. DRINK Type Definition ................................. 16 6. Format Conversion .......................................... 17 6.1. Roundtrip support ..................................... 17 6.2. Attribute to Property Mapping ......................... 18 6.3. Converting from LDAP to vCard ......................... 19 6.4. Converting from vCard to LDAP ......................... 21 7. Calendar LDAP Schema Update ................................ 23 7.1. Calendar Attributes ................................... 24 7.1.1. 'calCalAdrURI' ................................... 24 7.1.2. 'calCalURI' ...................................... 24 7.1.3. 'calCAPURI' ...................................... 24 7.1.4. 'calFBURL'........................................ 24 7.1.5. 'calOtherCalAdrURIs' ............................. 24 7.1.6. 'calOtherCalURIs' ................................ 24 7.1.7. 'calOtherCAPURIs' ................................ 25 7.1.8. 'calOtherFBURLs' ................................. 25 7.2. Calendar Object Classes ............................... 25 7.2.1. 'calEntry'........................................ 25 8. Security Considerations .................................... 25 9. IANA Considerations ........................................ 26 10. References ................................................ 28 10.1. Normative References ................................. 28 10.2. Informative References ............................... 28 11. Acknowledgments ........................................... 29 Appendix A. Schema Summary .................................... 30 A.1. Attribute source specifications ....................... 30 A.1.1. 'basicDirectoryCard' Summary ..................... 30 A.1.2. 'directoryCard' Summary .......................... 31 A.1.3. 'extendedDirectoryCard' Summary .................. 31 Appendix B. Changes (to be removed before publication)......... 32 B.1. Changes from draft-gryphon-ldap-schema-vcard-00 ....... 32 S. Gryphon Expires December 8, 2009 [Page 3] Internet-Draft LDAP Schema for vCard June 2009 1. Introduction 1.1. Background vCard is intended to be a format for representing directory information about people in a MIME message, including LDAP directories (see [VCARD4]). Lightweight Directory Access Protocol (LDAP) is a common standard used to store and access directory information, including information about people (see [RFC2798], [RFC4512], [RFC4517], and [RFC4519]). Although both intended to represent contact information about people, the two standards have significant differences in the attributes they support, and no clear method for mapping between the two. This standard documents: o New LDAP attribute types to support additional fields commonly used in vCard. o New LDAP object classes to represent collections of attributes similar to those used in vCard. o Extensions to vCard for some relevant attributes from LDAP or otherwise commonly used. o Definition of a mapping process between LDAP and vCard. o Updates to the Calendar Attributes from [RFC2739]. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. LDAP Attribute Types Current attributes defined in LDAP standards are not sufficient for support of the usual fields in vCard information cards. These attributes provide the additional support needed to implement the 'directoryCard' object class (detailed below). S. Gryphon Expires December 8, 2009 [Page 4] Internet-Draft LDAP Schema for vCard June 2009 In addition, four new attributes ('anniversary', 'childName', 'gender' and 'spouseName') are provided for the vCard extensions detailed in this document (AN, GENDER, RELATED). 3.1. 'anniversary' The date of marriage, or equivalent, of the contact represented by the directory entry. The value is usually only specified to the calendar day, without a time component. ( 1.3.6.1.4.1.33592.1.3.1 NAME 'anniversary' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517]. 3.2. 'birthDate' The date of birth of the contact represented by the directory entry. The value is usually only specified to the calendar day, without a time component. ( 1.3.6.1.4.1.33592.1.3.2 NAME 'birthDate' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517]. 3.3. 'category' The 'category' attribute type is used to classify contact directory entries into categories. Each kind is one value of this multi-valued attribute. S. Gryphon Expires December 8, 2009 [Page 5] Internet-Draft LDAP Schema for vCard June 2009 ( 1.3.6.1.4.1.33592.1.3.3 NAME 'category' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517]. Examples: "work", "friends", and "family". 3.4. 'childName' The 'childName' attribute type contains name strings for the children of a person. Each child is one value of this multi-valued attribute. ( 1.3.6.1.4.1.33592.1.3.4 NAME 'childName' SUP name ) Examples: "Jack Smith", "Jill Smith". 3.5. 'gender' Gender of the person represented by the directory entry, encoded as a value from [SEX]. The attribute should have a single digit, with 0 = Not known, 1 = Male, 2 = Female, or 9 = Not applicable. The values are not enforced by the directory, and user applications should consider any unexpected values as equivalent to 0. ( 1.3.6.1.4.1.33592.1.3.5 NAME 'gender' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) The Integer (1.3.6.1.4.1.1466.115.121.1.27) syntax and the 'integerMatch' and 'integerOrderingMatch' rules are described in [RFC4517]. Example: "1" 3.6. 'homeCountry' The 'homeCountry' (Friendly Country Name) attribute specifies names of countries for the home address of the entry in human-readable S. Gryphon Expires December 8, 2009 [Page 6] Internet-Draft LDAP Schema for vCard June 2009 format and used in conjunction with 'homeCountryName', which is limited to 2 character ISO codes. Although LDAP already supports multiple values for address elements (houseIdentifier, street, l, st, postalCode, c), there are no defined rules for correlating multiple entries or for specifying they type (work, home, etc). In contrast, vCard, provides a very large number of possible options for ways to specify combinations of properties for structured addresses. The various "home" attributes specified here allow a way to store specific home and work addresses for the same directory entry (similar to 'telephone' and 'homePhone'). ( 1.3.6.1.4.1.33592.1.3.6 NAME 'homeCountry' 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]. 3.7. 'homeCountryName' The 'homeCountryName' attribute type contains a two-letter ISO 3166 [ISO3166] country code. ( 1.3.6.1.4.1.33592.1.3.7 NAME 'homeCountryName' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE ) 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax [RFC4517]. Examples: "DE", "AU" and "FR". 3.8. 'homeHouseIdentifier' The 'houseIdentifier' attribute type contains identifiers for a building within a location. Each identifier is one value of this multi-valued attribute. S. Gryphon Expires December 8, 2009 [Page 7] Internet-Draft LDAP Schema for vCard June 2009 ( 1.3.6.1.4.1.33592.1.3.8 NAME 'homeHouseIdentifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517]. Example: "Unit 20" to represent the unit number 20. 3.9. 'homeLocalityName' The 'homeLocalityName' attribute type contains names of a locality or place, such as a city, county, or other geographic region. ( 1.3.6.1.4.1.33592.1.3.9 NAME 'homeLocalityName' SUP name ) Examples: "Geneva", "Paris", and "Edinburgh". 3.10. 'homePostalCode' The 'homePostalCode' attribute type contains codes used by a Postal Service to identify postal service zones. ( 1.3.6.1.4.1.33592.1.3.10 NAME 'homePostalCode' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517]. Example: "22180", to identify Vienna, VA, in the USA. 3.11. 'homePostOfficeBox' The 'homePostOfficeBox' attribute type contains postal box identifiers that a Postal Service uses when a customer arranges to receive mail at a box on the premises of the Postal Service. S. Gryphon Expires December 8, 2009 [Page 8] Internet-Draft LDAP Schema for vCard June 2009 ( 1.3.6.1.4.1.33592.1.3.11 NAME 'homePostOfficeBox' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517]. Example: "Box 45". 3.12. 'homeStateName' The 'homeStateName' attribute type contains the full names of states or provinces. This attribute may contain a value consistent with the codes specified in [ISO3166] part 2. ( 1.3.6.1.4.1.33592.1.3.12 NAME 'homeStateName' SUP name ) Example: "California". 3.13. 'homeStreet' The 'homeStreet' attribute type contains site information from a postal address (i.e., the street name, place, avenue, and the house number). ( 1.3.6.1.4.1.33592.1.3.13 NAME 'homeStreet' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax [RFC4517]. Example: "15 Main St.". 3.14. 'latLong' Represents a geographical location using the WGS84 data co-ordinates (used by GPS). The attribute consists of the latitude in decimal degrees (positive representing north), a semi colon, and then the longitude in decimal degrees (positive representing east). The location may be followed by S. Gryphon Expires December 8, 2009 [Page 9] Internet-Draft LDAP Schema for vCard June 2009 an optional additional semicolon and then height in decimal meters above sea level (of the reference geoid). This format is not checked by the directory. ( 1.3.6.1.4.1.33592.1.3.14 NAME 'latLong' 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]. Example: "-33.92;151.28". 3.15. 'logo' Used to store one or more images of a company logo using formats such as the JPEG File Interchange Format [JFIF]. ( 1.3.6.1.4.1.33592.1.3.15 NAME 'logo' SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 ) 3.16. 'otherFacsimileTelephoneNumber' The 'otherFacsimileTelephoneNumber' attribute type contains telephone numbers (and, optionally, the parameters) for facsimile terminals. Each telephone number is one value of this multi-valued attribute. Although 'facsimileTelephoneNumber', and other telephone number fields, are already multi-valued, having a separate attribute allows a distinction to be made between the preferred number (usually only one, stored in the main attribute), and any number of additional (not preferred) numbers, stored in the "other" attribute (multiple non- preferred numbers are more common). Note: Some user applications may not support multiple valued attributes, and so only be able to display at most two numbers in a category (the main one, plus the first "other"). ( 1.3.6.1.4.1.33592.1.3.16 NAME 'otherFacsimileTelephoneNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone Number syntax [RFC4517]. Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution". S. Gryphon Expires December 8, 2009 [Page 10] Internet-Draft LDAP Schema for vCard June 2009 3.17. 'otherHomePhone' The 'otherHomePhone' attribute specifies additional home telephone numbers (e.g., "+1 775 555 1234") associated with a person. ( 1.3.6.1.4.1.33592.1.3.17 NAME 'otherHomePhone' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are described in [RFC4517]. 3.18. 'otherMailbox' The 'otherMailbox' (rfc822mailbox) attribute type holds Internet mail addresses in Mailbox [RFC2821] form (e.g., user@example.com). ( 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} ) 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.19. 'otherMobile' The 'otherMobile' attribute specifies mobile telephone numbers (e.g., "+1 775 555 6789") associated with a person (or entity). ( 1.3.6.1.4.1.33592.1.3.19 NAME 'otherMobile' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are described in [RFC4517]. S. Gryphon Expires December 8, 2009 [Page 11] Internet-Draft LDAP Schema for vCard June 2009 3.20. 'otherPager' The 'otherPager' attribute specifies pager telephone numbers (e.g., "+1 775 555 5555") for an object. ( 1.3.6.1.4.1.33592.1.3.20 NAME 'otherPager' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are described in [RFC4517]. 3.21. 'otherTelephone' The 'otherTelephone' attribute type contains telephone numbers that comply with the ITU Recommendation E.123 [E123]. Each number is one value of this multi-valued attribute. ( 1.3.6.1.4.1.33592.1.3.21 NAME 'otherTelephone' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax [RFC4517]. Example: "+1 234 567 8901". 3.22. 'sortName' The 'sortName' attribute type contains name strings for the family names of a person. ( 1.3.6.1.4.1.33592.1.3.22 NAME 'sortName' SUP name ) Example: "Beethoven", where the sn attribute is "van Beethoven". 3.23. 'spouseName' The 'spouseName' attribute type contains name of the spouse of the contact represented by the directory entry. S. Gryphon Expires December 8, 2009 [Page 12] Internet-Draft LDAP Schema for vCard June 2009 ( 1.3.6.1.4.1.33592.1.3.23 NAME 'spouseName' SUP name ) Example: "Jane Smith". 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". 3.25. 'tzOffset' The usual time zone offset differential for the person. This does not take into account any daylight savings adjustment. The attribute contains a plus or minus sign, two digit hour, and then optional two digit minute, similar to the differential portion of Generalized Time syntax. This format is not checked by the directory. ( 1.3.6.1.4.1.33592.1.3.25 NAME 'tzOffset' 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]. Example: "+1000". S. Gryphon Expires December 8, 2009 [Page 13] Internet-Draft LDAP Schema for vCard June 2009 4. LDAP Object Classes 4.1. 'basicDirectoryCard' The 'basicDirectoryCard' object class contains basic attributes used in vCard that are supported in the inetOrgPerson object class. This object class is defined as auxiliary, because it will be used in conjunction with an existing structural object classes. Any directory which supports inetOrgPerson [RFC2798] should be able to support this class. ( 1.3.6.1.4.1.33592.1.4.1 NAME 'basicDirectoryCard' SUP top AUXILIARY MUST ( cn $ sn ) MAY ( audio $ businessCategory $ description $ displayName $ facsimileTelephoneNumber $ givenName $ homePhone $ homePostalAddress $ initials $ l $ labeledURI $ mail $ mobile $ o $ ou $ pager $ photo $ postalAddress $ postalCode $ postOfficeBox $ secretary $ st $ street $ telephoneNumber $ title $ uid $ userCertificate ) ) 4.2. 'directoryCard' The 'directoryCard' provides support for additional vCard attributes that are not in existing LDAP standards, or are in [RFC4519] and [RFC4524] but not attributes of inetOrgPerson. S. Gryphon Expires December 8, 2009 [Page 14] Internet-Draft LDAP Schema for vCard June 2009 ( 1.3.6.1.4.1.33592.1.4.2 NAME 'directoryCard' SUP basicDirectoryCard AUXILIARY MAY ( birthDate $ c $ category $ co $ generationQualifier $ homeCountry $ homeCountryName $ homeHouseIdentifier $ homeLocalityName $ homePostalCode $ homePostOfficeBox $ homeStateName $ homeStreet $ houseIdentifier $ latLong $ logo $ otherFacsimileTelephoneNumber $ otherHomePhone $ otherMailbox $ otherMobile $ otherPager $ otherTelephone $ personalTitle $ sortName $ tzOffset ) ) 4.3. 'extendedDirectoryCard' The 'extendedDirectoryCard' provides support for new vCard attributes defined in this document and [RFC4770]. It includes some attributes already defined in [RFC4519] and [RFC4524] but not in the original vCard specifications. ( 1.3.6.1.4.1.33592.1.4.3 NAME 'extendedDirectoryCard' SUP directoryCard AUXILIARY MAY ( anniversary $ carLicense $ childName $ drink $ gender $ manager $ messagingURI $ otherMessagingURI $ spouseName ) ) 5. vCard Schema Extensions The following extensions are defined for the vCard [VCARD4] to support common attributes from LDAP specifications and other applications. vCard type definitions are provided corresponding to the 'carLicense' attribute from [RFC2798], and the 'drink' attribute from [RFC4524]. In addition, one new type (AN) is provided, along with corresponding LDAP attribute defined above ('anniversary'). 5.1. AN Type Definition To: ietf-mime-directory@imc.org Subject: Registration of text/directory MIME type AN Type name: AN S. Gryphon Expires December 8, 2009 [Page 15] Internet-Draft LDAP Schema for vCard June 2009 Type purpose: To specify the date of marriage, or equivalent, of the person the vCard represents. Type encoding: 8bit Type value: The default is a single date value. Type examples: ANIV:1998-10-31 5.2. CAR Type Definition To: ietf-mime-directory@imc.org Subject: Registration of text/directory MIME type CAR Type name: CAR Type purpose: Vehicle license or registration plate associated with the person the vCard represents. Type encoding: 8bit Type value: A single text value. Type special notes: This type is based on the semantics of the [RFC2798] 'carLicense' attribute. Type examples: CAR:ABC-123 5.3. DRINK Type Definition To: ietf-mime-directory@imc.org Subject: Registration of text/directory MIME type DRINK Type name: DRINK Type purpose: Specifies the favorite drinks of an object (or person), for instance, "cola" and "beer". Type encoding: 8bit S. Gryphon Expires December 8, 2009 [Page 16] Internet-Draft LDAP Schema for vCard June 2009 Type value: A single text value. Type special notes: This type is based on the semantics of the [RFC4524] 'drink' attribute. Type examples: DRINK: Cola 6. Format Conversion 6.1. Roundtrip support The conversion rules are intended to support roundtrip conversion from LDAP to vCard and then back into LDAP again. One purpose of vCard is to allow information to be exchanged between directories. A defined mapping gives assurance that when a "business card" is produced from one directory, it will be accurately represented when imported into another. In practice this means that the vCard produced by this process will only even be subset of the features possible within vCard. Several advanced features of vCard, such as being able to include one vCard object within a field of another (such as for the AGENT attribute) are not used. vCard also has a very large number of possible combinations of attributes for fields such a TEL (telephone number), although in practice only a limited set will usually be used. Alternative handling for information outside this subset when converting in the reverse direction (from vCard to LDAP) is fully detailed below, but in general the full details of the vCard will not be preserved (for example, the exact same set of properties for a TEL attribute may not be retained). This means that round tripping in the other direction (from vCard to LDAP and back to vCard) is not guaranteed to work unless the vCard falls within the subset supported by this standard. S. Gryphon Expires December 8, 2009 [Page 17] Internet-Draft LDAP Schema for vCard June 2009 6.2. Attribute to Property Mapping The following table defines a mapping from LDAP attributes to vCard parametized properties, indicating the specific structured field where necessary. LDAP Attribute vCard Property Structured Field ----------------------------- ------------------- ---------------- anniversary AN audio SOUND birthDate BDAY businessCategory ROLE c, co WORK.ADR country name carLicense CAR category CATEGORIES childName RELATED;TYPE=child cn FN description NOTE displayName NAME distinguishedName (*1) SOURCE;CONTEXT=LDAP drink DRINK facsimileTelephoneNumber TEL;TYPE=fax;PREF=1 gender GENDER generationQualifier N suffixes givenName N given name homeCountry, homeCountryName HOME.ADR country name homeHouseIdentifier HOME.ADR extended homeLocalityName HOME.ADR locality homePhone HOME.TEL;PREF=1 homePostalAddress HOME.LABEL homePostalCode HOME.ADR postal code homePostOfficeBox HOME.ADR post office box homeStateName HOME.ADR region homeStreet HOME.ADR street address houseIdentifier WORK.ADR extended address initials N given name l WORK.ADR city labeledURI URL latLong GEO logo LOGO mail EMAIL;PREF=1 manager RELATED;TYPE=manager messagingURI IMPP;PREF=1 mobile TEL;TYPE=cell;PREF=1 o ORG org. name otherFacsimileTelephoneNumber TEL;TYPE=fax otherHomePhone HOME.TEL S. Gryphon Expires December 8, 2009 [Page 18] Internet-Draft LDAP Schema for vCard June 2009 otherMailbox EMAIL otherMessagingURI IMPP otherMobile TEL;TYPE=cell otherPager TEL;TYPE=pager otherTelephone WORK.TEL ou ORG org. unit names pager TEL;TYPE=pager;PREF=1 personalTitle N prefixes photo PHOTO postalAddress WORK.LABEL postalCode WORK.ADR postal code postOfficeBox WORK.ADR post office box secretary RELATED;TYPE=assistant sn N family name sortName SORT-STRING spouseName RELATED;TYPE=spouse st WORK.ADR region street WORK.ADR street address telephoneNumber WORK.TEL;PREF=1 title TITLE tzOffset, tzid TZ uid NICKNAME uniqueIdentifier UID userCertificate KEY whenChanged REV (*1) distinguishedName encoded as an LDAP URI. The above table includes mappings administrative attributes uniqueIdentifier and whenChanged. In addition to the above mapping, the SOURCE property should specify CONTEXT=LDAP and provide the LDAP URI with the distinguishedName of the directory entry. 6.3. Converting from LDAP to vCard Attributes SHOULD be mapped from the LDAP entry to the vCard properties as specified above, with the following rules. 1. An application SHOULD map all fields it holds data for, except an application MAY decide to omit fields (or default to omitting fields) containing more personal or sensitive information (primarily AN, BDAY, RELATED fields of type child and spouse). S. Gryphon Expires December 8, 2009 [Page 19] Internet-Draft LDAP Schema for vCard June 2009 2. It is recommended that a user SHOULD be able to configure an application to omit or include fields or use an alternative mapping, and an application MAY fallback to alternative properties if the mappings specified here are not possible. e.g. If a directory entry does not have a 'photo' attribute, then an application may use (or be configurable to use) an alternative attribute such as 'jpegPhoto'. 3. Where a LDAP attribute has multiple values, all values SHOULD appear in the vCard, for example multiple values of the 'title' attribute will result in multiple "TITLE" properties in the vCard. 4. Where a LDAP attribute has multiple values and the mapping specifies a vCard PREF=1, an application MAY omit the PREF attribute from the second and subsequent values. e.g. If a directory entry has two 'telephoneNumber' values, the first may be mapped to WORK.TEL;PREF=1 and the second to WORK.TEL. 5. Where a single LDAP value exists for an attribute where the mapping specifies a vCard PREF=1, the application MAY omit the PREF attribute provided that no other value (such as from another directory attribute) maps to the resulting vCard property (without the TYPE=PREF). e.g. If a directory entry has a single 'telephoneNumber' value, then it may be mapped to WORK.TEL provided there are no 'otherTelephone' values (normally 'otherTelephone' maps to WORK.TEL without the PREF attribute). 6. Where a LDAP attributes has multiple values and maps to part of a structured vCard property (such as the ADR or N properties), then the first value of each attribute SHOULD map to the first property, the second value of each attribute SHOULD map to the second property, etc (leaving structured values blank where necessary). e.g. If a directory entry has one values for 'sn' and two values for 'givenName', then two N properties will be generated. The first N property has the first value for each attribute, and the second N property has the second 'givenName' value only (other parts of the structured value will be empty). S. Gryphon Expires December 8, 2009 [Page 20] Internet-Draft LDAP Schema for vCard June 2009 7. The 'givenName' attribute SHOULD be mapped to the first value of the given name structured field in the N property. The 'initials' attribute SHOULD be mapped to a second value of the given name structured field (separated by a comma). 8. To generate the country name portion of an ADR vCard property, any of the following MAY be used (in order of recommendation, noting that vCard is intended to contain a name, not necessarily a code): a. The 'co' (or 'homeCountryName') attribute. b. The value of the 'c' (or 'homeCountry') attribute, converted from a two character code into a country name via lookup. c. The 'c' (or 'homeCountry') attribute (a two character code). 9. To generate the TZ property, any of the following MAY be used (in order of recommendation): a. The 'tzid' attribute (as a text value). b. The 'tzid' attribute timezone, converted to an offset via lookup. The date used for the conversion SHOULD be the time specified in the REV property. c. The 'tzOffset' attribute. 10.The 'manager' and 'secretary' attributes of a directory entry are mapped to RELATED properties by finding the entry they refer to (the attributes contain distinguished names) and taking the 'cn' attribute of the referenced entry. 6.4. Converting from vCard to LDAP As the mapping from LDAP only utilizes a subset of the vCard format, additional rules are required to consistently import vCard formats that lie outside that subset. 1. An application SHOULD map all fields contained in the vCard. 2. It is recommended that a user SHOULD be able to configure an application to omit or include fields or use an alternative mapping. S. Gryphon Expires December 8, 2009 [Page 21] Internet-Draft LDAP Schema for vCard June 2009 3. Where a mapping is defined for a property with PREF=1 and the vCard does not contain a corresponding property, but does contain has a TEL property of that type without PREF=1, then the first property of that type SHOULD be treated as if it contains PREF=1 (and map accordingly). e.g. If a vCard contains a property WORK.TEL, but no property WORK.TEL;PREF=1, then the value is mapped to the LDAP attribute 'telephoneNumber'. 4. Where a vCard has multiples of the same property with PREF=1, then the application MAY choose to treat the second and subsequent attributes as if they do not have PREF=1 (and map accordingly). e.g. If a vCard contains multiple properties for the value EMAIL;PREF=1, then the first value must map to LDAP attribute 'mail', but the other values may be mapped to either 'mail' or 'otherMailbox' (i.e. treated as if they are just EMAIL). 5. Any TEL property types other than FAX, CELL, PAGER should be ignored when mapping. If the resulting TEL property has no TYPE and is not in the HOME group: a. If the vCard has no WORK.TEL (either with or without PREF=1), then it SHOULD be mapped to the LDAP attribute 'telephoneNumber'. b. Otherwise, it SHOULD be mapped to the LDAP attribute 'otherTelephone'. e.g. If a vCard contains TEL;TYPE=cell,voice;PREF=1 then it is treated as if it is TEL;TYPE=cell, and if it contains TEL;TYPE=bbs,modem,car then it is treated as WORK.TEL (or WORK.TEL;PREF=1). These mappings are necessary because LDAP supports a much smaller range of telephone number types and combinations than vCard. 6. Any ADR or LABEL property TYPE should be ignored when mapping. 7. Any ADR or LABEL property without a group should be treated as in the WORK group, i.e. WORK.ADR or WORK.LABEL. S. Gryphon Expires December 8, 2009 [Page 22] Internet-Draft LDAP Schema for vCard June 2009 8. The country name field of a structured ADR property SHOULD be used to set both the 'c' and 'co' attributes (or 'homeCountry' and 'homeCountryName' attributes) if possible. Note that applications should expect that this field may contain either a country name or a two character code. 9. The TZ property SOULD be used to set both the 'tzid' and 'tzOffset' attributes if possible. If TZ only contains a numeric offset then it should be considered as the offset as at the time specified in the REV property. 10.Any RELATED property of type manager or assistant SHOULD try to be resolved as the 'cn' of another directory entry if possible. Otherwise, an application MAY either: a. Create a new directory entry with the 'cn', using the last word of the value as the 'sn'. In this case the new entry should be tracked in case it can be replaced by another vCard being imported. b. Store the property name and 'cn' value as an additional 'description' attribute of the entry, e.g. "assistant: Bob Smith". 7. Calendar LDAP Schema Update [RFC2739] defines calendar attributes for vCard and LDAP. The OID values used are from the ISO USA Microsoft tree (1.2.840.113556), however Microsoft is not listed as one of the contributors to the RFC. In fact, the the OID used for calCAPURI (1.2.840.113556.1.4.480) conflicts with an existing OID used within Microsoft Active Directory (for an attribute named defaultGroup). Clarification is also needed as to the attributes of the calEntry object class. The LDAP definitions in [RFC2739] should be updated to the following values. S. Gryphon Expires December 8, 2009 [Page 23] Internet-Draft LDAP Schema for vCard June 2009 7.1. Calendar Attributes 7.1.1. 'calCalAdrURI' ( 1.3.6.1.4.1.33592.1.3.26 NAME 'calCalAdrURI' EQUALITY caseIgnoreMatch SUBSTRING caseIgnoreMatch SYNTAX 'IA5String' USAGE userApplications ) 7.1.2. 'calCalURI' ( 1.3.6.1.4.1.33592.1.3.27 NAME 'calCalURI' EQUALITY caseIgnoreMatch SUBSTRING caseIgnoreMatch SYNTAX 'IA5String' USAGE userApplications ) 7.1.3. 'calCAPURI' ( 1.3.6.1.4.1.33592.1.3.28 NAME 'calCAPURI' EQUALITY caseIgnoreMatch SUBSTRING caseIgnoreMatch SYNTAX 'IA5String' USAGE userApplications ) 7.1.4. 'calFBURL' ( 1.3.6.1.4.1.33592.1.3.29 NAME 'calFBURL' EQUALITY caseIgnoreMatch SUBSTRING caseIgnoreMatch SYNTAX 'IA5String' USAGE userApplications ) 7.1.5. 'calOtherCalAdrURIs' ( 1.3.6.1.4.1.33592.1.3.30 NAME 'calOtherCalAdrURIs' EQUALITY caseIgnoreMatch SUBSTRING caseIgnoreMatch SYNTAX 'IA5String' MULTI-VALUE USAGE userApplications ) 7.1.6. 'calOtherCalURIs' ( 1.3.6.1.4.1.33592.1.3.31 NAME 'calOtherCalURIs' EQUALITY caseIgnoreMatch S. Gryphon Expires December 8, 2009 [Page 24] Internet-Draft LDAP Schema for vCard June 2009 SUBSTRING caseIgnoreMatch SYNTAX 'IA5String' MULTI-VALUE USAGE userApplications ) 7.1.7. 'calOtherCAPURIs' ( 1.3.6.1.4.1.33592.1.3.32 NAME 'calOtherCAPURIs' EQUALITY caseIgnoreMatch SUBSTRING caseIgnoreMatch SYNTAX 'IA5String' MULTI-VALUE USAGE userApplications ) 7.1.8. 'calOtherFBURLs' ( 1.3.6.1.4.1.33592.1.3.33 NAME 'calOtherFBURLs' EQUALITY caseIgnoreMatch SUBSTRING caseIgnoreMatch SYNTAX 'IA5String' MULTI-VALUE USAGE userApplications ) 7.2. Calendar Object Classes 7.2.1. 'calEntry' (1.3.6.1.4.1.33592.1.4.4 NAME 'calEntry' SUP top AUXILIARY MAY ( calCalAdrURI $ calCalURI $ calCAPURI $ calFBURL $ calOtherCalAdrURIs $ calOtherCalURIs $ calOtherCAPURIs $ calOtherFBURLs ) ) 8. Security Considerations Transporting directory information via vCard has several security considerations outlined in [VCARD4]. These include the transport of cryptographic keys, security classification policies for vCards, spoofing of vCards, and revision date considerations. As detailed in the mapping section, an application SHOULD allow a user to configure what information is included in a vCard, particularly for personal information such as birth date and family members. S. Gryphon Expires December 8, 2009 [Page 25] Internet-Draft LDAP Schema for vCard June 2009 An application MAY implement a mapping or other way of designating a CLASS property for a vCard, or a process for handling the CLASS property of imported vCards. Like [VCARD4], this document does not detail any specific policy for handling CLASS attributes. 9. IANA Considerations This memo defines IANA registered extensions to the attributes defined by LDAP [RFC4512] and vCard [RFC2426]. IANA registration proposals for vCard, detailed in section 5, are to be emailed to the registration agent for the "text/directory" MIME content-type, using the format defined in [VCARD]. The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry [RFC4520] as indicated in the following template: Subject: Request for LDAP Descriptor Registration Update Descriptor (short name): see comment Object Identifier: see comments Person & email address to contact for further information: Stephen Gryphon Usage: see comments Specification: draft-gryphon-ldap-schema-vcard-01 Author/Change Controller: IESG S. Gryphon Expires December 8, 2009 [Page 26] Internet-Draft LDAP Schema for vCard June 2009 Comments: The following descriptors have been updated to refer to this RFC. NAME Type OID ------------------------------ ---- ------------------------- anniversary A 1.3.6.1.4.1.33592.1.3.1 basicDirectoryCard O 1.3.6.1.4.1.33592.1.4.1 birthDate A 1.3.6.1.4.1.33592.1.3.2 calCalAdrURI A 1.3.6.1.4.1.33592.1.3.26 calCalURI A 1.3.6.1.4.1.33592.1.3.27 calCAPURI A 1.3.6.1.4.1.33592.1.3.28 calEntry O 1.3.6.1.4.1.33592.1.4.4 calFBURL A 1.3.6.1.4.1.33592.1.3.29 calOtherCalAdrURIs A 1.3.6.1.4.1.33592.1.3.30 calOtherCalURIs A 1.3.6.1.4.1.33592.1.3.31 calOtherCAPURIs A 1.3.6.1.4.1.33592.1.3.32 calOtherFBURLs A 1.3.6.1.4.1.33592.1.3.33 category A 1.3.6.1.4.1.33592.1.3.3 childName A 1.3.6.1.4.1.33592.1.3.4 directoryCard O 1.3.6.1.4.1.33592.1.4.2 extendedDirectoryCard O 1.3.6.1.4.1.33592.1.4.3 gender A 1.3.6.1.4.1.33592.1.3.5 homeCountry A 1.3.6.1.4.1.33592.1.3.6 homeCountryName A 1.3.6.1.4.1.33592.1.3.7 homeHouseIdentifier A 1.3.6.1.4.1.33592.1.3.8 homeLocalityName A 1.3.6.1.4.1.33592.1.3.9 homePostalCode A 1.3.6.1.4.1.33592.1.3.10 homePostOfficeBox A 1.3.6.1.4.1.33592.1.3.11 homeStateName A 1.3.6.1.4.1.33592.1.3.12 homeStreet A 1.3.6.1.4.1.33592.1.3.13 latLong A 1.3.6.1.4.1.33592.1.3.14 logo A 1.3.6.1.4.1.33592.1.3.15 otherFacsimileTelephoneNumber A 1.3.6.1.4.1.33592.1.3.16 otherHomePhone A 1.3.6.1.4.1.33592.1.3.17 otherMailbox A 1.3.6.1.4.1.33592.1.3.18 otherMobile A 1.3.6.1.4.1.33592.1.3.19 otherPager A 1.3.6.1.4.1.33592.1.3.20 otherTelephone A 1.3.6.1.4.1.33592.1.3.21 sortName A 1.3.6.1.4.1.33592.1.3.22 spouseName A 1.3.6.1.4.1.33592.1.3.23 tzid A 1.3.6.1.4.1.33592.1.3.24 tzOffset A 1.3.6.1.4.1.33592.1.3.25 where Type A is Attribute, Type O is ObjectClass, and * indicates that the registration is historic in nature. S. Gryphon Expires December 8, 2009 [Page 27] Internet-Draft LDAP Schema for vCard June 2009 10. References 10.1. Normative References [E123] Notation for national and international telephone numbers, ITU-T Recommendation E.123, 1988 [ISO3166] ISO 3166, "Codes for the representation of names of countries". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, April 2000. [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006. [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. [RFC4519] Sciberras, A. (Editor), "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006. [RFC4524] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524, June 2006. [SEX] ISO 5218:2004, "Codes for the representation of human sexes". [UTS35] Davis, M., "Unicode Locale Data Markup Language (LDML)", Unicode Technical Standard #35, version 1.7, May 2007. [VCARD4] draft-ietf-vcarddav-vcardrev-07 10.2. Informative References [WGS84] National Geospatial-Intelligence Agency, "NIMA Technical Report TR8350.2 Department of Defense World Geodetic System 1984, Its Definition and Relationships With Local Geodetic Systems", Third Edition. S. Gryphon Expires December 8, 2009 [Page 28] Internet-Draft LDAP Schema for vCard June 2009 11. Acknowledgments Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Thanks to Andrew Sciberras, Anton Bobrov, Cullen Jennings, Dan Mosedale, David Bienvenu, Denis Hennessy, Frank Dawson, Julian Reschke, Kurt Zeilenga, Mark Smith, Matthew Barnes, Pat Egen, Rich Megginson, Steven Legg, Tim Howes, and Tony Small for reviewing this document. This document was prepared using 2-Word-v2.0.template.dot. S. Gryphon Expires December 8, 2009 [Page 29] Internet-Draft LDAP Schema for vCard June 2009 Appendix A. Schema Summary A.1. Attribute source specifications This appendix provides a summary of all the attribute types used in the 'basicDirectoryCard', 'directoryCard' and 'extendedDirectoryCard' object classes defined in this document along with their source. Attributes without a source listed are specified in this document. A.1.1. 'basicDirectoryCard' Summary Attribute Source ------------------------------ ------- audio RFC2798 businessCategory RFC2798 cn RFC4519 description RFC4519 displayName RFC2798 facsimileTelephoneNumber RFC4519 givenName RFC2798 homePhone RFC2798 homePostalAddress RFC2798 initials RFC2798 l RFC4519 labeledURI RFC2798 mail RFC2798 mobile RFC2798 o RFC2798 ou RFC4519 pager RFC2798 photo RFC2798 postalAddress RFC4519 postalCode RFC4519 postOfficeBox RFC4519 secretary RFC2798 sn RFC4519 st RFC4519 street RFC4519 telephoneNumber RFC4519 title RFC4519 uid RFC2798 userCertificate RFC2798 S. Gryphon Expires December 8, 2009 [Page 30] Internet-Draft LDAP Schema for vCard June 2009 A.1.2. 'directoryCard' Summary In addition to the attributes specified for 'basicDirectoryCard'. Attribute Source ------------------------------ -------- co RFC4524 generationQualifier RFC4519 homeCountry homeCountryName homeHouseIdentifier homeLocalityName homePostalCode homePostOfficeBox homeStateName homeStreet houseIdentifier RFC4519 latLong logo otherFacsimileTelephoneNumber otherHomePhone otherMailbox otherMobile otherPager otherTelephone personalTitle RFC4524 sortName tzid tzOffset A.1.3. 'extendedDirectoryCard' Summary In addition to the attributes specified for 'directoryCard'. Attribute Source ------------------------------ ------- drink RFC4524 gender manager RFC2798 messagingURI RFC4770 otherMessagingURI RFC4770 spouseName S. Gryphon Expires December 8, 2009 [Page 31] Internet-Draft LDAP Schema for vCard June 2009 Appendix B. Changes (to be removed before publication) B.1. Changes from draft-gryphon-ldap-schema-vcard-00 o Update from vCard 3.0 to vCard 4.0 draft, including: o Mapping for 'initials' attribute changed from additional names to a second value for given name in the N property. o Remove CHILD, MGR, SEX, SPOUSE additional vCard properties. o Update mapping for AGENT, CHILD, MGR, SPOUSE to use new RELATED property. o Remove mention of inline vCards o Update mapping for gender (from SEX to GENDER). o Change TYPE=WORK, HOME to WORK., HOME. o TODO: Check updates for new vCard drafts, e.g. mapping should refer to PREF ordering (not just PREF=1). o TODO: Considerations for PID values, URIs in TEL, RELATED. o TODO: Submit additional properties (AN, CAR, DRINK) back into VCARD4 (not this document), i.e. remove part 5. Also submit recommendations on GENDER coding (use ISO5218) and TYPE=spouse for the RELATED property. o TODO: Calendar now party of vCard 4.0, so move to part of main document (e.g. after section 4). S. Gryphon Expires December 8, 2009 [Page 32] Internet-Draft LDAP Schema for vCard June 2009 Authors' Addresses Stephen Gryphon Gryphon Technology Pty Ltd P.O. Box 1615 Macquarie Centre NSW 2113 Australia Phone: +61 4 1454 2562 Email: sgryphon@computer.org S. Gryphon Expires December 8, 2009 [Page 33]