idnits 2.17.1 draft-ietf-asid-ldapv3schema-vcard-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([LDAPV3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 309: '... ABSTRACT MUST objectClass)...' RFC 2119 keyword, line 317: '...P top STRUCTURAL MUST aliasedObjectNam...' RFC 2119 keyword, line 325: '... SUP top STRUCTURAL MUST formattedName...' RFC 2119 keyword, line 326: '... MAY (structuredName $ photogra...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 1997) is 9788 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'LDAPV3' on line 937 looks like a reference -- Missing reference section? 'VCARD' on line 964 looks like a reference -- Missing reference section? 'X500' on line 927 looks like a reference -- Missing reference section? 'LDAPSYN' on line 930 looks like a reference -- Missing reference section? 'RFC822' on line 948 looks like a reference -- Missing reference section? 'RFC2045' on line 954 looks like a reference -- Missing reference section? 'RFC1766' on line 951 looks like a reference -- Missing reference section? 'PCM' on line 294 looks like a reference -- Missing reference section? 'LDAPX500' on line 941 looks like a reference -- Missing reference section? 'LDAPURL' on line 934 looks like a reference -- Missing reference section? 'UTF8' on line 958 looks like a reference -- Missing reference section? 'LDIF' on line 945 looks like a reference -- Missing reference section? 'US-ASCII' on line 961 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Frank Dawson 2 Internet Draft Mike O'Brien 3 Lotus/Iris Associates 4 Expires January 1998 July 8, 1997 6 The vCard Schema For Use In LDAPv3 7 draft-ietf-asid-ldapv3schema-vcard-00.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 andits working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced, or made obsolete 18 by other documents at any time. It is not appropriate to use 19 Internet-Drafts as reference material or to cite them other than as a 20 "working draft" or "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Distribution of this document is unlimited. 30 Abstract 32 The Lightweight Directory Access Protocol (LDAP) [LDAPV3] is gaining 33 widespread acceptance as a method for accessing Internet directories. 34 Many of the LDAP clients accessing these directories also provide 35 support for emitting the directory information in the form of a vCard 36 electronic business card object. This memo defines a new X.500 object 37 class, called the vCardObject, that extends the X.521 standard 38 organizationalPerson and residentialPerson in order to provide a 39 unique LDAP schema for accessing Internet directories in terms of 40 the vCard attributes. 42 The schema defined by this memo should be used when accessing a 43 directory via LDAP Version 3 and searching or retrieving directory 44 information based on vCard related attributes. The schema describes 45 the attribute types and object classes that have a 1-to-one 46 correspondence with vCard properties. 48 This schema may also be used to define a set of object classes and 49 attributes for storing metadata and binding information for a 50 directory entry that closely follows the vCard object in directories 51 that support LDAP. 53 1. Introduction 55 The Lightweight Directory Access Protocol [LDAPV3] defines a standard 56 protocol for accessing Internet directory services. A common purpose 57 for such directory services is the collection of directory 58 information related to people and resources. The vCard Electronic 59 Business Card Format [VCARD] defines a standard format for exchanging 60 information about people and resources. These two standards are 61 linked by their technical foundations on the International 62 Telecommunications Union Recommendations for The Directory Services 63 [X500]. However, up to this point a more formal correlation between 64 the two standards has been missing. This memo links the two standards 65 by defining the LDAP schema to be used for LDAP-based access to a 66 directory, when the resultant information is intended to be in the 67 form of the attributes that make up a vCard object. 69 The [VCARD] specification defines a relatively flat schema. Each 70 instance of a vCard is a container for a set of peer attributes, 71 which vCard calls properties. These attributes describe various 72 facets of a physical person or resource in terms of their 73 identification, delivery addressing, telecommunications addressing, 74 geographical, organizational, explanatory and security properties. 75 Additionally, non-standardized, implementation-specific attributes 76 may be present. With minor exceptions, all of the features of the 77 [VCARD] specification are supported by this schema. 79 2. Notation 81 The notation used to describe object classes and attribute types in 82 this memo is the same that is used in [LDAPSYN]. The BNF used in this 83 memo is the same as in [RFC822]. 85 The use of the terms attribute and property are used interchangeably 86 in this memo. 88 The object identifier (OID) used by this schema is rooted at 89 "1.3.6.1.4.1.2309.1.1.1.1". The Internet Mail Consortium (IMC) is the 90 authority for the name spaced under this root object identifier. 92 3. Object Naming 94 All vCardObject objects must have the formattedName as their naming 95 attribute. This attribute provides the RDN for the object. This 96 attribute is based on the Common Name attribute of [X.500], as 97 defined in [VCARD]. Values should adhere to the guidelines for the 98 Common Name attribute, as specified in [LDAPV3]. 100 In addition, the uniqueID attribute may be present to provide a 101 method for correlating different vCardObject objects that refer to 102 the same physical person or resource, yet contain differing 103 descriptions. For example, a single person or resource might be 104 described by a Canadian-French language-based vCardObject and also an 105 US-English language-based vCardObject. This would be accomplished by 106 both vCardObjects containing the uniqueID property with the same 107 value. 109 The uniqueID attribute is also used to refer to the vCardObject 110 corresponding to the physical person or resource in the agent 111 property. 113 4. Grouping 115 The [VCARD] specification supports to forms of grouping or 116 collections. The "vCard Grouping" capability permits a vCardObject to 117 be the container for a sequence of one or more vCardObjects. For 118 example a vCardObject describing a work group might consist of the 119 vCardObjects for each member of that work group. The vCard Grouping 120 is not supported by this memo. 122 The "Property Grouping" capability permits individual attributes 123 within a vCard object to be further grouped by the pre-concatenation 124 of a textual, group label. For example the telephone number and 125 delivery label for a vacation residence might be prefixed with a 126 group label of "VACATION.". Property Grouping is not supported by 127 this memo. 129 5. Structured Property Values 131 Some of the attributes defined by the [VCARD] specification consist 132 of multiple components. Structured attribute values are also 133 supported by this schema. The components are separated by either the 134 "$" or "#" character. 136 6. Property Parameters 138 The [VCARD] specification allows attribute values to be qualified 139 with "property parameters". For example, "home" and "office" 140 telephone numbers can be distinguished by the property parameters 141 "TYPE=HOME" and "TYPE=OFFICE" being applied to the respective home 142 and office telephone number values. Property parameters are supported 143 using attribute description options, as defined in [LDAPV3]. 145 6.1 Property Value Types 147 The [VCARD] specification provides for the optional specification of 148 the attribute value data type as a property parameter. The data type 149 of all attributes defined by this schema are implicitly defined by 150 their attribute type description. The property value parameter type 151 is not further supported by this schema. 153 6.2 Encoding Options 155 The default encoding or format for vCardObject attribute values is 156 8bit textual data. The encoding may be overridden for an individual 157 property value by the specification of an encoding option on the 158 attribute description. These options allow for the return of the 159 attribute value in a format other than the default textual format. 161 These options may be specified only on the logo, photo and sound 162 attributes defined by this schema. 164 An encoding option is based on the following BNF: 166 Encodeoption = ["encoding-"] binaryencode / b64encode 168 Binaryencode = "binary" ;As defined by [LDAPV3] 170 b64encode = "base64" ;As defined by [RFC2045] 172 6.2.1 Binary Encoding 174 The "binary" option is as described in [LDAPV3]. 176 6.2.2 Base-64 Encoding 178 The "base64" option overrides the default format for attribute values 179 so that they are transferred as 7-bit text, thus making it safe to 180 carry over restricted transports. [RFC2045] defines the encoding of 181 this format. 183 6.3 Language Option 185 The language used in the vCardObject attribute values may be 186 explicitly specified for an individual property value by the 187 specification of a language option on the attribute description. The 188 language is specified as a string consistent with [RFC1766]. This 189 option may be specified on any attribute defined by this schema. 191 The language option is based on the following BNF: 193 langoption = "language-" langtype 195 langtype = 197 For example, "comment;language-us-eng" for a Comment attribute 198 description whose textual value is written in US English. 200 6.4 Image Format Option 202 This option specifies the image image format for the photo and logo 203 attributes value. The image format option must be specified only on 204 the photo and logo attribute. These attributes must specify this 205 option in order to specify the graphic image format of the photo or 206 logo value. 208 The image format option is based on the following BNF: 210 imageoption = "format-" formattype 212 formattype = 213 For example, "photo;format-jpeg" for a Photo attribute description 214 for a value in a JPEG image format. 216 6.5 Delivery Type Option 218 This option specifies the characteristics of delivery address and 219 delivery label attributes value. The delivery type option may be 220 specified only in the deliveryAddress or deliveryLabel attributes. 222 The delivery address type option is based on the following BNF: 224 deliveroption = (["dom"] ;An domestic delivery 225 / ["intl"]) ;An international delivery 226 ["postal"] ;A postal delivery 227 ["parcel"] ;A parcel delivery 228 ["home"] ;A residential delivery 229 ["work"] ;A business delivery 230 ["pref"] ;A preferred delivery 232 For example, "adr;dom;postal;parcel;home" for an attribute 233 description for a domestic delivery address for a residence that is 234 used for postal and parcel service delivery. 236 6.6 Telephone Type Option 238 This option specifies the characteristics of telephone number 239 attribute value. The telephone type option may be specified only in 240 the telephoneNumber attribute. 242 The telephone type option is based on the following BNF: 244 teleoption = ["home"] ;A residential number 245 ["work"] ;A business number 246 ["voice"] ;A voice number 247 ["fax"] ;A facsimile number 248 ["msg"] ;A number with voice mail 249 ( ["cell"] ;An analog cellular number 250 / ["pager"] ;A pager number 251 / ["pcs"] ;A digital PCS number 252 / ["bbs"] ;A bulletin board system number 253 / ["modem"] ;A number with a MODEM attached 254 / ["car"] ;A car cellular number 255 / ["isdn"] ;An ISDN SPID 256 / ["video"]) ;A video conferencing number 257 ["pref"] ;A preferred number 259 For example, "tel;pref;work;voice;msg" for a Telephone Number 260 property which is preferred over other telephone numbers for work. In 261 addition, the telephone number is a voice line with voice mail 262 support. 264 6.7 Electronic Mail Type Option 266 This option specifies the characteristics of electronic mail 267 attribute value. The electronic mail type option may be specified 268 only in the electronicMail attribute. 270 The electronic mail type option is based on the following BNF: 272 emailoption = (["internet"] ;An internet email address 273 / ["x400"] ;A X.400 OR address 274 / ["video"] ;A video conferencing number 275 / [word] ) ;Any other email address type 276 ["pref"] ;A preferred number 278 word = 1*char ;A word 280 For example, "email;internet" for an attribute description with a 281 value that is an Internet, RFC822 address format. 283 6.8 Sound Format Type Option 285 This option specifies the format of the sound attribute value. The 286 sound format type option may be specified only in the sound 287 attribute. 289 The sound format type option is based on the following BNF: 291 soundoption = 293 For example, "sound;basic" for a Sound attribute description whose 294 value is single channel audio encoded using 8bit ISDN mu-law [PCM] at 295 a sample rate of 8000 Hz. 297 7. Object Definitions 299 The following object classes are defined by this schema. LDAP servers 300 should recognize the object classes listed in this section as values 301 of the objectClass attribute. 303 7.1 Top 305 This object class is the same as that defined in [LDAPX500]. 307 (2.5.6.0 308 NAME 'top' 309 ABSTRACT MUST objectClass) 311 7.2 Alias 313 This object class is the same as that defined in [LDAPX500]. 315 (2.5.6.1 316 NAME 'alias' 317 SUP top STRUCTURAL MUST aliasedObjectName) 318 7.3 VCard Object 320 The vCardObject is a container for collecting together attributes 321 describing a person or resource. 323 (1.3.6.1.4.1.2309.1.1.1.1.1 324 NAME 'vCardObject' 325 SUP top STRUCTURAL MUST formattedName 326 MAY (structuredName $ photograph $ birthDate $ uid $ 327 deliveryAddress $ 328 deliveryLabel $ telephoneNumber $ eMail $ mailer $ timeZone $ 329 globalPosition $ title $ role $ logo $ agent $ orgNameUnit $ 330 comment $ 331 revision $ sound $ url $ version $ key) 333 8. Attribute Type Definitions 335 These attribute type descriptions are defined as follows. LDAP 336 servers should recognize the attribute types defined in this section. 338 8.1 Identification Attributes 340 8.1.1 Formatted Name 342 This attribute specifies the formatted text of the distinguished name 343 associated with the vCardObject. This is the text that should be used 344 to display the distinguish name. It may contain desired honorific 345 prefixes, suffixes, titles, etc. This attribute corresponds to the 346 [vCard] "FN" property. Implementations conforming to this memo must 347 support this attribute. In addition, every directory entry must 348 contain this attribute. 350 (1.3.6.1.4.1.2309.1.1.1.1.2 NAME 'formattedName' 351 DESC 'formatted name text' 352 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 353 SYNTAX 'vCardString{255}' SINGLE-VALUE) 355 8.1.2 StructuredName 357 This attribute specifies the structured text components of the name 358 associated with the vCardObject. This attribute corresponds to the 359 [vCard] "N" property. The attribute value consists of the Family 360 Name, Given Names, Additional Names, Honorific Prefixes and Honorific 361 Suffixes. The components are separated by "$" or "#" characters. 363 (1.3.6.1.4.1.2309.1.1.1.1.3 NAME 'structuredName' 364 DESC 'structured name components' 365 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 366 SYNTAX 'vCardName{255}' SINGLE-VALUE) 367 8.1.3 Photograph 369 This attribute specifies a photograph associated with the 370 vCardObject. This attribute corresponds to the [vCard] "PHOTO" 371 property. 373 (1.3.6.1.4.1.2309.1.1.1.1.4 NAME 'photograph' 374 DESC 'photograph' 375 SYNTAX 'vCardImage' SINGLE-VALUE) 377 8.1.4 BirthDate 379 This attribute specifies the birthdate associated with the 380 vCardObject. This attribute corresponds to the [vCard] "BDAY" 381 property. 383 (1.3.6.1.4.1.2309.1.1.1.1.5 NAME 'birthDate' 384 DESC 'birthdate' 385 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 386 SYNTAX 'vCardDate' SINGLE-VALUE) 388 8.1.5 Unique Identifier 390 This attribute specifies a globally unique identifier associated with 391 the vCardObject. This attribute corresponds to the [vCard] "UID" 392 property. A person or resource may be represented by more than one 393 vCardObject. For example, entries in different languages. This 394 attribute is used to correlate the vCardObjects that refer to the 395 same physical person or resource. 397 (1.3.6.1.4.1.2309.1.1.1.1.6 NAME 'uid' 398 DESC 'unique identifier' 399 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 400 SYNTAX 'vCardString{255}' SINGLE-VALUE) 402 8.2 Delivery Addressing Attributes 404 8.2.1 DeliveryAddress 406 This attribute specifies the structured text components of the 407 deliver address associated with the vCardObject. This attribute 408 corresponds to the [vCard] "ADR" property. The attribute value 409 consists of the Extended Address, Post Office Box, Street Address, 410 Locality or City, Region or State or Province, Postal Code and 411 Country Name. If the address option indicates that the value is an 412 international address, then the country component must be present. 413 The components are separated by "$" or "#" characters. 415 (1.3.6.1.4.1.2309.1.1.1.1.7 NAME 'deliveryAddress' 416 DESC 'structured delivery address components' 417 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 418 SYNTAX 'vCardAddress{255}' SINGLE-VALUE) 419 8.2.2 DeliveryLabel 421 This attribute specifies the text for the delivery label associated 422 with the vCardObject. This attribute corresponds to the [vCard] 423 "LABEL" property. If the address option indicates that the value is 424 an international address, then the country name must be present. 426 (1.3.6.1.4.1.2309.1.1.1.1.8 NAME ' deliveryLabel' 427 DESC 'delivery label' 428 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 429 SYNTAX 'vCardMultiLineString{1023}' SINGLE-VALUE) 431 8.2.3 TelephoneNumber 433 This attributes specifies a telephone number associated with the 434 vCardObject. This attribute corresponds to the [vCard] "TEL" 435 property. The value should be specified in it's international form. 437 (1.3.6.1.4.1.2309.1.1.1.1.9 NAME 'telephoneNumber' 438 DESC 'telephone number' 439 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 440 SYNTAX 'vCardTelephone{32}' SINGLE-VALUE) 442 8.2.4 ElectronicMail 444 This attribute specifies an electronic mail or messaging address 445 associated with the vCardObject. This attribute corresponds to the 446 [vCard] "EMAIL" property. 448 1.3.6.1.4.1.2309.1.1.1.1.10 NAME 'eMail' 449 DESC 'electronic mail address' 450 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 451 SYNTAX 'vCardString{255}' SINGLE-VALUE) 453 8.2.5 Mailer 455 This attribute specifies the type of electronic mail software that is 456 used by the person or resource associated described by the 457 vCardObject. This attribute corresponds to the [vCard] "MAILER" 458 property. 460 (1.3.6.1.4.1.2309.1.1.1.1.11 NAME 'mailer' 461 DESC 'electronic mail mailer' 462 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 463 SYNTAX 'vCardString{255}' SINGLE-VALUE) 465 8.3 Geographical Attributes 467 8.3.1 TimeZone 469 This attribute specifies the UTC offset for the nominal standard zone 470 of the locale for the person or resource described by the 471 vCardObject. This attribute corresponds to the [vCard] "TZ" property. 473 (1.3.6.1.4.1.2309.1.1.1.1.12 NAME 'timeZone' 474 DESC 'standard utc offset' 475 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 476 SYNTAX 'vCardTimeZone' SINGLE-VALUE) 478 8.3.2 GeoPosition 480 This attribute specifies the longitude and latitude form of the 481 global positioning information of the person or resource described by 482 the vCardObject. This attribute corresponds to the [vCard] "GEO" 483 property. 485 (1.3.6.1.4.1.2309.1.1.1.1.13 NAME 'globalPosition' 486 DESC 'global positioning information' 487 EQUALITY vcCardFloatMatch SUBSTR caseIgnoreSubstringMatch 488 SYNTAX 'vCardPosition' SINGLE-VALUE) 490 8.4 Organizational Attributes 492 8.4.1 Title 494 This attribute specifies the job title, functional position or 495 function of the person or resource described by the vCardObject. This 496 attribute corresponds to the [vCard] "TITLE" property. 498 (1.3.6.1.4.1.2309.1.1.1.1.14 NAME 'title' 499 DESC 'title' 500 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 501 SYNTAX 'vCardString{255}' SINGLE-VALUE) 503 8.4.2 Role 505 The attribute specifies the role, occupation or business category of 506 the person or resource described by the vCardObject. This attribute 507 corresponds to the [vCard] "ROLE" property. 509 (1.3.6.1.4.1.2309.1.1.1.1.15 NAME 'role' 510 DESC 'role' 511 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 512 SYNTAX 'vCardString{255}' SINGLE-VALUE) 514 8.4.3 Logo 516 This attribute specifies a graphical image of a logo associated with 517 the vCardObject. This attribute corresponds to the [vCard] "LOGO" 518 property. 520 (1.3.6.1.4.1.2309.1.1.1.1.16 NAME 'logo' 521 DESC 'logo' 522 SYNTAX 'vCardImage' SINGLE-VALUE) 523 8.4.4 Agent 525 This attribute specifies the globally unique identifier of another 526 vCardObject that describes a person or resource that will act on 527 behalf of the person or resource described by this vCardObject. This 528 attribute corresponds to the [vCard] "AGENT" property. 530 (1.3.6.1.4.1.2309.1.1.1.1.17 NAME 'agent' 531 DESC 'agent' 532 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 533 SYNTAX 'vCardString{255}' SINGLE-VALUE) 535 8.4.5 OrgNameUnits 537 This attribute specifies the text components of the organizational 538 name and units of the person or resource associated with the 539 vCardObject. This attribute corresponds to the [vCard] "ORG" 540 property. The attribute value consists of the organizational name 541 followed by any organizational units. The components are separated by 542 "$" or "#" characters. 544 (1.3.6.1.4.1.2309.1.1.1.1.18 NAME 'orgNameUnits' 545 DESC 'organizational name and units' 546 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 547 SYNTAX 'vCardOrgNameUnit{255} SINGLE-VALUE) 549 8.5 Explanatory Attributes 551 8.5.1 Comment 553 This attribute specifies a textual comment or note associated with 554 the vCardObject. This attribute corresponds to the [vCard] "NOTE" 555 property. 557 (1.3.6.1.4.1.2309.1.1.1.1.19 NAME 'comment 558 DESC 'comment or note' 559 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 560 SYNTAX 'vCardMultiLineString{1023}' SINGLE-VALUE) 562 8.5.2 LastRevision 564 The attribute specifies the date and time that the vCardObject was 565 last revised. This attribute corresponds to the [vCard] "REV" 566 property. 568 (1.3.6.1.4.1.2309.1.1.1.1.20 NAME 'revision' 569 DESC 'date and time of last revision' 570 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 571 SYNTAX 'vCardDateTime' SINGLE-VALUE) 572 8.5.3 Sound 574 This attribute specifies a digital sound content that annotates some 575 aspect of the person or resource described by the vCardObject. This 576 attribute corresponds to the [vCard] "SOUND" property. 578 (1.3.6.1.4.1.2309.1.1.1.1.21 NAME 'sound' 579 DESC 'sound' 580 SYNTAX 'vCardSound' SINGLE-VALUE) 582 8.5.4 URL 584 This attribute specifies a uniform resource locator (URL) associated 585 with the vCardObject. This attribute corresponds to the [vCard] "URL" 586 property. This URL will allow subsequent access to the directory 587 containing the vCardObject. The URL may be in the format defined for 588 a LDAP URL by [LDAPURL]. 590 (1.3.6.1.4.1.2309.1.1.1.1.22 NAME 'url' 591 DESC 'url' 592 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 593 SYNTAX 'vCardString{255}' SINGLE-VALUE) 595 8.5.5 Version 597 This attribute specifies the version of [VCARD] represented by the 598 schema used in the vCardObject. This attribute corresponds to the 599 [vCard] "VERSION" property. 601 (1.3.6.1.4.1.2309.1.1.1.1.23 NAME 'version' 602 DESC 'agent' 603 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 604 SYNTAX 'vCardString{255}' SINGLE-VALUE) 606 8.6 Security Attributes 608 8.6.1 PublicKey 610 The attribute specifies a public key or authentication certificate 611 associated with the vCardObject. This attribute corresponds to the 612 [vCard] "KEY" property. If the value of the attribute is a public 613 key, then the value is encoded in the vCardString syntax. If the 614 value of the attribute is a certificate, then the binary option must 615 be specified and the value is an octet-string. 617 (1.3.6.1.4.1.2309.1.1.1.1.24 NAME 'key' 618 DESC 'key or certificate' 619 EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringMatch 620 SYNTAX 'vCardString{255}' SINGLE-VALUE) 622 9. Syntax Definitions 624 The following syntax descriptions are defined by this schema. New 625 syntax definitions were defined by this memo in order to assure an 626 unambiguous rendering of the directory information in a syntax 627 consistent with the [VCARD]. Reuse of existing syntax definitions 628 from either X.500 or other person schemas would not guarantee 629 delivery of the directory information in a syntax consistent with 630 [VCARD]. For example, the existing date/time syntax is not consistent 631 with ISO 8601 or the emerging Internet date/time specification. The 632 directory string syntax does not convey the form of the multi-line 633 label text. 635 Servers should recognize all the syntax definitions described in this 636 memo. 638 9.1 VCardString 640 Values with the vCardString syntax are encoded in the [UTF8] form. 641 Servers and clients must be prepared to receive encodings of 642 arbitrary Unicode characters. Values with the vCardString syntax are 643 encoded according to the following BNF: 645 string = *char 647 char = 649 (1.3.6.1.4.1.2309.1.1.1.1.25 DESC 'vCardString') 651 9.2 vCardName 653 Values with the vCardName syntax are encoded as if they were 654 vCardString types. The value is structured text consisting of the 655 family name component, the given names component, the other names 656 component, honorific prefix components and honorific suffix 657 components. The value is encoded according to the following BNF: 659 name = family delim given [delim other [delim prefix 660 [delim sufix]]] 662 space = 1*" " 663 delim = "$" / "#" 664 family = 1*char 665 given = 1*char 666 other = 1*char / 1*char [space other] 667 prefix = 1*char / 1*char [space prefix] 668 suffix = 1*char / 1*char [space suffix] 670 (1.3.6.1.4.1.2309.1.1.1.1.26 DESC 'vCardName') 672 9.3 vCardImage 674 Values with the vCardImage syntax are encoded as graphical images in 675 the format specified by the image type option. This can be any IANA 676 registered graphical image format. These binary data formats must 677 either be passed as a binary object using the binary encoding option 678 or as packed binary text data when the base64 encoding option is 679 specified. 681 (1.3.6.1.4.1.2309.1.1.1.1.27 DESC 'vCardImage') 683 9.4 vCardDate 685 Values with the vCardDate syntax are encoded as if they were 686 vCardString types. The values are text represenations of the calendar 687 date as specified in ISO 8601 and by the following BNF: 689 date = fulldate 691 digit = ;0-9 692 date-fullyear = 4digit 693 date-month = 2digit ;01-12 694 date-mday = 2digit ;01-28, 01-29, 01-30, 01-31 695 ;based on month/year 696 full-date = date-fullyear date-month date-mday 698 For example, the following represents July 14, 1997: 700 19970714 702 (1.3.6.1.4.1.2309.1.1.1.1.28 DESC 'vCardDate') 704 9.5 vCardDateTime 706 Values with the vCardDateTime syntax are encoded as if they were 707 vCardString types. The value is the text represenations of the 708 calendar date and time of day as specified in ISO 8601 and by the 709 following BNF: 711 date-time = date "T" time ;As specified above and below 713 digit = ;0-9 714 time-hour = 2digit ;00-23 715 time-minute = 2digit ;00-59 716 time-second = 2digit ;00-59 717 time-numzone = ("+" / "-") time-hour time-minute 718 time-zone = "Z" / time-numzone 719 full-time = time-hour time-minute time-second [time-zone] 721 time = fulltime 723 (1.3.6.1.4.1.2309.1.1.1.1.29 DESC 'vCardDateTime') 725 9.6 vCardAddress 727 Values with the vCardAddress syntax are encoded as if they were 728 vCardString types. The value is structured text consisting of the 729 extended component, post office box component, street address 730 component, locality component, region component, postal code 731 component and country component. If the address option includes 732 indicates that the value is an international address, then the 733 country component must be present. The syntax is specified by the 734 following BNF: 736 address = [extcomp] delim [pobcomp] delim [stcomp] delim 737 [loccomp] delim [regcomp] delim [codcomp] 738 [delim ctrcomp] 740 delim = "$" / "#" 741 space = *" " 742 char = 743 phrase = 1*char / 1*char *(space 1*char) 744 extcomp = phrase ;Extended address 745 pobcomp = phrase ;Post Office Box 746 stcomp = phrase ;Street address 747 loccomp = phrase ;Locality or city name 748 regcomp = phrase ;Region, state or province name 749 codcomp = phrase ;Postal code 750 ctrcomp = phrase ;Country name or code 752 (1.3.6.1.4.1.2309.1.1.1.1.30 DESC 'vCardAddress') 754 9.7 vCardMultiLineString 756 Value with the vCardMultiLineString syntax are encoded as if they 757 were vCardString types. The value may consist of multiple lines of 758 text as defined in [VCARD]. However, the multiple line values are 759 specified in this syntax by the following BNF: 761 char = 762 space = 1*" " 763 delim = "$" / "#" 764 linetext = 1*char *(space 1*char) 765 multiline = 1*linetext 767 (1.3.6.1.4.1.2309.1.1.1.1.31 DESC 'vCardMultiLineString') 769 9.8 vCardTimeZone 771 Values with the vCardTimeZone syntax are encoded as if they were 772 vCardString types. The value is the text represenations of the UTC 773 offset specified in ISO 8601 and by the following BNF: 775 time-numzone = ("+" / "-") time-hour time-minute 777 digit = ;0-9 779 time-hour = 2DIGIT ;00-23time-minute = 2DIGIT 780 ;00-59 782 (1.3.6.1.4.1.2309.1.1.1.1.32 DESC 'vCardTimeZone') 783 9.9 vCardTelephone 785 Values with the vCardTelephone syntax are encoded as if they were 786 vCardString types. Telephone numbers are recommended to be in 787 international form. 789 (1.3.6.1.4.1.2309.1.1.1.1.33 DESC 'vCardTelephone') 791 9.10 vCardPosition 793 Values with the vCardPosition syntax are encoded as if they were 794 vCardString types. The value is structured text consisting of the 795 floating point longitude global position followed by the latitude 796 global position and by the following BNF: 798 position = float delim float 800 delim = "$" / "#" 801 digit = ;0-9 802 float = ["+" / "-"] *DIGIT ["." *DIGIT] 804 (1.3.6.1.4.1.2309.1.1.1.1.34 DESC 'vCardPosition') 806 9.11 vCardOrgNameUnit 808 Values with the vCardOrgNameUnit syntax are encoded as if they were 809 vCardString types. The value is structured text consisting of the 810 organizational name component followed by any organization unit 811 names. The value is encoded according to the following BNF: 813 organ = orgname [orgunit] 815 delim = "$" / "#" 816 orgname = 1*char 817 orgunit = delim 1*char [orgunit] 819 (1.3.6.1.4.1.2309.1.1.1.1.35 DESC 'vCardOrgNameUnit') 821 9.12 vCardSound 823 Values with the vCardSound syntax are encoded as digital audio in the 824 format specified by the sound type option. This can be any IANA 825 registered digital audio format. This binary data must either be 826 passed as a binary object using the binary encoding option or as 827 packed binary text data when the base64 encoding option is specified. 829 (1.3.6.1.4.1.2309.1.1.1.1.36 DESC 'vCardSound') 831 10. Matching Rule Definitions 833 The vCardObject data is primarily encoded as textual information. 834 Therefore, only the following matching rules from [LDAPSYN] are 835 required by this schema. 837 caseIgnoreMatch 838 caseIgnoreSubstringMatch 840 Servers should allow all matching rules listed in this section to be 841 used in the extensibleMatch. In general, these servers should allow 842 matching rules to be used with all attribute types known to the 843 server, when the assertion syntax of the matching rule is the same at 844 the value syntax of the attribute. 846 Servers may implement additional matching rules. 848 For all these rules, the assertion syntax is the same as the value 849 syntax. 851 When performing the caseIgnoreMatch and caseIgnoreSubstringMatch, 852 multiple adjoining whitespace characters are treated the same, as an 853 individual space, and leading and trailing whitespace is ignored. 855 11. Example Usage 857 The following is an example of LDAP URL query to get the formatted 858 name and work telephone number for anyone in the USA named Smith. 860 ldap:///c=US?formattedName,telephoneNumber;work??(formattedName= 861 Smith*) 863 The following is an example of a vCardObject using the LDIF format of 864 [LDIF]. 866 dn: formattedName = John Smith 867 objectClass: top 868 objectClass: vCardObject 869 formattedName: John Smith 870 structuredName: Smith$John 871 uid: 19970708T113000-ds01@host.com-10373AFBC38391 872 deliveryAddress;work;postal: MS101$PO Box 1234$1024 B 873 St.$Columbia$MO$65201$USA 874 deliveryLabel;work;parcel:1024 B St.$Columbia, MO 65201$USA 875 telephoneNumber;work;msg;voice;pref: +1-314-555-1234 876 telephoneNumber;work;voice:+1-314-555-1236 877 telephoneNumber;work;fax:+1-314-555-9876 878 eMail: john.smith@host1.com 879 title: V.P. Engineering 880 orgNameUnits: TigerSoft$MidWest Region$MSG$Financial Services 881 version: 2.1 883 12. Security Considerations 885 In addition to the security considerations specified in [LDAPV3] the 886 following considerations should be reviewed by implementors of this 887 memo. 889 12.1 Disclosure 891 Attributes of directory entries are used to provide descriptive 892 information about the real-word objects they represent, which be 893 people or resources. Most countries have privacy laws regarding the 894 publication of information about people. 896 12.2 Security Concerns 898 The [VCARD] specification provides a robust schema for representing 899 information about people or resources. Publication of this 900 information in Internet directories providing LDAP support for this 901 schema may provide an inadvertent means for unauthorized use of the 902 information once it has been retrieved. Care should be taken in 903 managing both the access of directories containing personal data. 905 In addition, the flexible nature of the vCard format may facilitate 906 the spoofing of a person or resource or other such fraudulent 907 activities by an untrusted individual. Care should be taken to 908 authenticate the originator of any vCard based personal data. 910 13. Acknowledgments 912 This document is based on the [VCARD] specification. This work is 913 heavily influenced by the early contributions of Roland Alden, Gary 914 Hand, Pat Megowan and others who helped draft the original 915 specification. 917 In addition, the following have participated in the review and 918 discussion of this memo: 920 Roland Alden, Harald Alvestrand, Mike Dugan, Alec Dun, David Goodman, 921 Bruce Greenblatt, Frode Hernes, Paul Hoffman, Tim Howes, Burton Lee, 922 Chris Newman, Dave Mease, Vinod Seraphin, Richard Shusterman, and 923 Mark Wahl. 925 14. Bibliography 927 [X500] ITU-T Recommendations. X.500-X.525 Series, "The Directory 928 Services", 1993. 930 [LDAPSYN] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 931 Directory Access Protocol (v3): Attribute Syntax Definitions", 932 INTERNET-DRAFT , June 1997. 934 [LDAPURL] T. Howe, M. Smith, "The LDAP URL Format", INTERNET-DRAFT 935 , June 1997. 941 [LDAPX500] M. Wahl, "A Summary of the X.500(93) User Schema for use 942 with LDAPv3", INTERNET-DRAFT , March 1997. 945 [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) _ Technical 946 Specification", INTERNET-DRAFT . 948 [RFC822] D. Crocker, "Standard of the Format of ARPA-Internet Text 949 Messages", STD 11, RFC 822, August 1982. 951 [RFC1766] H. Alvestrand, " Tags for the Identification of Languages", 952 RFC 1766, March 1995. 954 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 955 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 956 2045, November 1996. 958 [UTF8] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 959 10646", RFC 2044, October 1996. 961 [US-ASCII] Coded Character Set--7-bit American Standard Code for 962 Information Interchange, ANSI X3.4-1986. 964 [VCARD] F. Dawson, T. Howes, "vCard MIME Directory Profile", 965 INTERNET-DRAFT , March 1997. 967 15. Author's Address 969 The following address information is provided in the IETF vCard, 970 Electronic Business Card, format. 971 BEGIN:VCARD 972 VERSION:2.1 973 FN:Frank Dawson 974 ORG:Lotus Development Corporation 975 ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh; 976 NC;27613-3502;USA 977 TEL;WORK;MSG:+1-919-676-9512 978 TEL;WORK;FAX:+1-919-676-9564 979 EMAIL;INTERNET;WORK;PREF:Frank_Dawson@Lotus.com 980 EMAIL;INTERNET:fdawson@earthlink.net 981 URL:http://home.earthlink.net/~fdawson 982 END:VCARD 984 BEGIN:VCARD 985 VERSION:2.1 986 FN:Mike O'Brien 987 ORG:Iris Associates 988 ADR;WORK;POSTAL;PARCEL:;; One Technology Park Drive;Westford; 989 MA; 01886;USA 990 TEL;WORK;MSG:+1-508-692-9265 991 TEL;WORK;FAX:+1-919-692-7365 992 EMAIL;INTERNET;WORK:MOBrien@iris.com 993 END:VCARD