[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

<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, <MAILTO:  ietf-mime-directory@imc.org> 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 <sgryphon@computer.org>
      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]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/