From fb30695d904e08fadb89257f559a805d8ec3bdce Mon Sep 17 00:00:00 2001 From: Miles Lott Date: Wed, 21 Mar 2001 05:18:38 +0000 Subject: [PATCH] Moving vcard doc to doc dir --- addressbook/doc/vcard-21.txt | 2335 ++++++++++++++++++++++++++++++++++ 1 file changed, 2335 insertions(+) create mode 100644 addressbook/doc/vcard-21.txt diff --git a/addressbook/doc/vcard-21.txt b/addressbook/doc/vcard-21.txt new file mode 100644 index 0000000000..85e08b7e90 --- /dev/null +++ b/addressbook/doc/vcard-21.txt @@ -0,0 +1,2335 @@ +vCard +The Electronic Business Card +Version 2.1 + +A versit Consortium Specification +September 18, 1996 + + +Copyrights +? 1996, International Business Machines Corp., Lucent Technologies, +Inc., and Siemens. All rights reserved. +Permission is granted to copy and distribute this publication provided +that it is reproduced in its entirety without modification and +includes the above copyright notice and this permission notice. +No licenses, express or implied, are granted with respect to any of +the technology described in this publication. International Business +Machines Corp., Lucent Technologies, Inc., and Siemens retain all +their intellectual property rights in the technology described in this +publication. +Even though International Business Machines Corp., Lucent +Technologies, Inc., and Siemens have reviewed this specification, +INTERNATIONAL BUSINESS MACHINES CORP., LUCENT TECHNOLOGIES, INC, AND +SIEMENS, MAKE NO WARRANTY OR REPRESENTATION, EITHER EXPRESS OR +IMPLIED, WITH RESPECT TO THIS PUBLICATION, ITS QUALITY OR ACCURACY, +NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE. +AS A RESULT, THIS SPECIFICATION IS DELIVERED "AS IS" AND THE READER +ASSUMES THE ENTIRE RISK AS TO ITS QUALITY, ACCURACY OR SUITABILITY FOR +ANY PARTICULAR PURPOSE.. +IN NO EVENT WILL INTERNATIONAL BUSINESS MACHINES CORP., LUCENT +TECHNOLOGIES, INC, AND SIEMENS, BE LIABLE FOR DIRECT, INDIRECT, +SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM ANY +DEFECT OR INACCURACY IN THIS PUBLICATION, EVEN IF ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. +This publication is provided with RESTRICTED RIGHTS. Use, duplication, +or disclosure by the Government are subject to restrictions set forth +in DFARS 252.227-7013 or 48 CFR 52.227-19, as applicable. + + +Trademarks +versit, the versit logo, versitcard, vCard, and vCalendar are +trademarks of Apple Computer, Inc., AT&T Corp., International Business +Machines Corp., and Siemens. +Apple, is a trademarks of Apple Computer, Inc. registered in the U.S. +and other countries. +AT&T and ATTMail are registered trademarks of AT&T Corp. +IBM, IBM Mail, and OS/2 are registered trademarks of International +Business Machines Corporation. +America Online is a registered trademark of America Online, Inc. +CompuServe, CompuServe Information Services are registered trademarks +of Compuserve Incorporated. +MCIMail is a registered trademark of MCI Communications Corporation. +Microsoft is a registered trademark, and Microsoft Windows is a +trademark of Microsoft Corporation. +Prodigy is a registered trademark of Prodigy Services Company. +Unicode is a registered trademark of Unicode, Inc. + + +Contributors +Roland Alden +Greg Ames, Ames & Associates +Masanari Arai, Puma Technologies +Stephen W. Bartlett +Donal Carroll +Liang-Jye Chang, Starfish Software +Frank Dawson, IBM Corporation +Ken Dobson, IntelliLink Inc. +Scott Feldstein, Nimble Software, Inc. +Anik Ganguly, OnTime/Division of FTP Software. +Beijing Goo, Microsoft +Arvind K. Goyal, Lotus Development Corporation +Gary Hand, IBM Corporation +Tim Howes, Netscape Communications Corporation +Mark Joseph, Attachmate Corporation +Kerry Kelly, Now Software, Inc. +Phac Letuan, Apple Computer, Inc. +Pat Megowan, Counterpoint Sytems Foundry Inc. +Tohri Mori, IBM Japan/Salutation Consortium +Ravi Pandya, NetManage, Inc. +Geoff Ralston, Four11 Corporation +Steven Rummel, Lucent Technologies +Michael Santullo, Four11 Corporation +Vinod Seraphin, Lotus Development Corporation +Dexter Seely, Corex Technologies, Inc. +Vlad Shmunis, Ring Zero Systems Inc. +Dean Stevens, Now Software, Inc. +Michelle Watkins, Netscape Communications Corporation +Horst Widlewski, Siemens + + +Reference Information +The cited references contain provisions which, through reference in +this specification, constitute provisions of this specification. At +the time of publication, the indicated versions in the following +references were valid. Parties to agreements based on this +specification are encouraged to research the possibility of revised +standards. +* ANSI X3.4-1977, Code for Information Interchange, American +National Standards Institute, 1977. +* CCITT (ITU) Recommendation E.163, Numbering Plan for The +International Telephone Service, CCITT Blue Book, Fascicle II.2, pp. +128-134, November, 1988. +* CCITT (ITU) Recommendation G.721, 32 kbit/s Adaptive Differential +Pulse Code Modulation (ADPCM), CCITT Red Book, Fascicle III.4, +November, 1988. +* CCITT (ITU) Recommendation X.121, International Numbering Plan +for Public Data Networks, CCITT Blue Book, Fascicle VIII.3, pp. 317- +332, November, 1988. +* CCITT (ITU) Recommendations X.500-X.521, Data Communication +Networks: Directory, CCITT Blue Book, Fascicle VIII.8, November, 1988. +* CCITT Recommendation X.520, The Directory-Selected Attribute +Types, 1988. +* CCITT Recommendation X.521, The Directory-Selected Object +Classes, 1988. +* IETF RFC 1738, Universal Resource Locator, December 1994. +* IETF Network Working Group RFC 1766, Tags for the Identification +of Languages, March 1995. +* IETF Network Working Group Draft, A MIME Content-Type for +Directory Information, January 1996. Available from the University of +Michigan, 535 W. William St., Ann Arbor, MI 48103-4943, +FTP://ds.internic.net/Internet-Drafts/draft-ietf-asid-mime-direct- +01.txt. +* IETF Network Working Group Draft, An Application/Directory MIME +Content-Type Electronic Business Card Profile, May 1996. Available +FTP://ds.internic.net/Internet-Drafts/draft-ietf-asid-mime-vcard- +00.txt. +* IETF Network Working Group Draft, UTF-8, A Transformation Format +of UNICODE and ISO 10646, July 1996. Available from +FTP://ds.internic.net/Internet-Drafts/draft-yergeau-utf8-01.txt. +* ISO 639, Code for The Representation of names of languages, +International Organization for Standardization, April, 1988. +* ISO 3166, Codes for The Representation of names of countries, +International Organization for Standardization, December, 1993. +* ISO 8601, Data elements and interchange formats-Information +interchange-Representation of dates and times, International +Organization for Standardization, June, 1988. +* ISO 8601, Technical Corrigendum 1, Data elements and interchange +formats-Information interchange-Representation of dates and times, +International Organization for Standardization, May, 1991. +* ISO 8859-1, Information Processing-8-Bit single-byte coded +graphic character sets-Part 1: Latin Alphabet No. 1, International +Organization for Standardization, February, 1987. +* ISO 9070, Information Processing-SGML support facilities- +Registration Procedures for Public Text Owner Identifiers, 1990-02- +01.[DS1] +? ISO/IEC 9070, Information Technology?SGML Support +Facilities?Registration Procedures for Public Text Owner Identifiers, +Second Edition, International Organization for Standardization, April, +1991. +? ISO/IEC 11180, Postal addressing, International Organization for +Standardization, 1993. +? Apple?s Representation of a Canonical Static DeviceID in The +Telephony Suite, version 1.0, Apple Computer, Inc., 1993. +* Microsoft TAPI in Microsoft Windows 3.1 Telephony Programmers' +Guide, version 1.0, Microsoft Corporation, 1993. +* RFC1521, MIME (Multipurpose Internet Mail Extensions) Part One: +Mechanisms for Specifying and Describing the Format of Internet +Message Bodies, Network Working Group, September, 1993. +* The Unicode Standard, Version 1.1: Version 1.0, Volume 1 (ISBN 0- +201-56788-1), version 1.0, volume 2 (ISBN 0-20-60845-6) and Unicode +Technical Report #4, The Unicode Standard, version 1.1, The Unicode +Consortium, October, 1991. Both references to be published by Addison- +Wesley. + + +versit Update +versit is a multivendor development initiative of the communication +and computer industries, founded by Apple, AT&T, IBM and Siemens. The +versit parties believe that great potential exists in improving the +nature of communications in the business world-permitting companies to +better manage their quality, productivity, customer satisfaction and +cost of operations, while expanding the market opportunities for a +variety of product and service vendors. versit parties will jointly +define and support open specifications that facilitate and promote the +interoperability of advanced personal information and communication +devices, networks and services. +The versit vision is to enable diverse communication and computing +devices, applications and services from competing vendors to +interoperate in all environments. Through developing a series of +specifications for interoperability among diverse communications and +computing devices, applications, networks and services, versit 's +vision will become a reality. +versit 's primary development areas are in: +* Personal Data Interchange (PDI) +* Computer Telephone Integration (CTI) +* Conferencing and Messaging (C&M) +* Wired and Wireless connectivity +versit specifications are directed at both the decision makers and the +implementation teams of: +* Equipment Manufacturers +* Independent Software Vendors +* Information Service Providers +* Online Service Providers +* Software Houses +* Users +versit specifications are made available to any interested party. In +turn, versit encourages the support of our goals by soliciting +feedback on versit specifications. + +All comments relating to versit or the material within this +specification should be submitted to: +versit +(800) 803-6240 ++1 (201) 327-2803 (Outside USA) +pdi@versit.com +http://www.versit.com/pdi + + +Contents +Section 1 : Introduction +1.1 Overview +1.2 Scope +1.3 Contents +1.4 Definitions and Abbreviations +Section 2 : vCard Specificiation +2.1 Encoding Characteristics +2.1.1 vCard Object +2.1.2 Property +2.1.3 Delimiters +2.1.4 Grouping +2.1.4.1 vCard Grouping +2.1.4.2 Property Grouping +2.1.5 Encodings +2.1.6 Character Set +2.1.7 Language +2.1.8 Value Location +2.1.9 Binary Values +2.2 Identification Properties +2.2.1 Formatted Name +2.2.2 Name +2.2.3 Photograph +2.2.3.1 Photo Format Type +2.2.4 Birthdate +2.3 Delivery Addressing Properties +2.3.1 Delivery Address +2.3.1.1 Delivery Address Type +2.3.2 Delivery Label +2.3.2.1 Delivery Label Type +2.4 Telecommunications Addressing Properties +2.4.1 Telephone Number +2.4.1.1 Telephone Type +2.4.2 Electronic Mail +2.4.2.1 Electronic Mail Type +2.4.3 Mailer +2.4.4 Geographical Properties +2.4.5 Time Zone +2.4.6 Geographic Position +2.5 Organizational Properties +2.5.1 Title +2.5.2 Business Category +2.5.3 Logo +2.5.3.1 Logo Format Type +2.5.4 Agent +2.5.5 Organization Name and Organizational Unit +2.6 Explanatory Properties +2.6.1 Comment +2.6.2 Last Revision +2.6.3 Sound +2.6.3.1 Sound Digital Audio Type +2.6.4 Uniform Resource Locator +2.6.5 Unique Identifier +2.6.6 Version +2.7 Security Properties +2.7.1 Public Key +2.7.2 Key Type +2.8 Miscellaneous Properties +2.8.1 Extensions +2.9 Formal Definition +Section 3 : Internet Recommendations +3.1 Recommended Practice with SMTP/MIME +3.1.1 Text/Plain Content Type +3.1.2 Text/X-vCard Content Type +3.1.3 Application/Directory Content Type +3.2 Recommended Practice with HTTP/HTML +3.2.1 Form Element Usage +3.2.2 Mapping To INPUT Element Attribute Names +3.2.3 Example HTML Code +Section 4 : UI Support Recommendations +4.1 File System +4.2 Clipboard +4.3 Drag/Drop +Section 5 : Conformance + + + +Section 1 : Introduction +[DS2] +Personal Data Interchange (PDI) occurs every time two or more +individuals communicate, in either a business or personal context, +face-to-face, or across space and time. Such interchanges frequently +include the exchange of informal information, such as business cards, +telephone numbers, addresses, dates and times of appointments, etc. +Augmenting PDI with electronics and telecommunications can help ensure +that information is quickly and reliably communicated, stored, +organized and easily located when needed. +Personal information, by nature, is complex and diverse. Currently, +proprietary standards exist to structure some types of PDI +information, but no single, open specification comprehensively +addresses the needs of collecting and communicating PDI information +across many common communication channels such as telephones, voice- +mail, e-mail, and face-to-face meetings. versit is developing a +comprehensive family of PDI technologies based on open specifications +and interoperability agreements to help meet this technology need. +Overview +This specification defines a format for an electronic business card, +or vCard. The format is suitable as an interchange format between +applications or systems. The format is defined independent of the +particular method used to transport it. The transport for this +exchange might be a file system, point-to-point asynchronous +communication, wired-network transport, or some form of unwired +transport. +A vCard is a data stream consisting of one or more vCard objects. The +individual vCard definitions can be identified and parsed within the +datastream. The vCard data stream may exist as a persistent form in a +file system, document management system, network connection between +two network endpoints, or in any other digital transport that has an +abstraction of a stream of bytes. +Conceptually, a vCard Writer creates vCard data streams and a vCard +Reader interprets vCard data streams. The vCard Reader and Writer may +be implemented as a single application or as separate applications. It +is not the intent of this specification to define the implementation +of these processes beyond some fundamental capabilities related to the +format of the vCard data stream and a common set of conformance +requirements . +This specification provides for a clear-text encoding that is intended +to be based on the syntax used by the MIME specification (RFC 1521). +The encoding of this specification can be used in environments which +are constrained to 7-bit transfer encodings, short line lengths, and +low bandwidth. In addition, the encoding is simple in order to +facilitate the implementation of reader and writer applications on +small platforms, such as Personal Digital Assistants (PDA), cellular +telephones, or alphanumeric pagers. +Scope +The vCard is intended to be used for exchanging information about +people and resources. In today's business environment, this +information is typically exchanged on business cards. It is +appropriate, then that this specification define this information in +terms of a paradigm based on an electronic business card object. +The ultimate destination for this information is often a collection of +business cards, Rolodex® file, or electronic contact manager. Prior to +the introduction of the vCard specification, users of such +applications typically had to re-key the original information, often +transcribing it from paper business cards. With the advent of the +vCard specification, this information can be exchanged in an automated +fashion. +The basis for the data types supported by this specification have +their origin in openly defined, international standards and in +additional capabilities based on enhancements suggested by the +demonstration of the exchange of prototypical vCards using the +Internet based World-Wide-Web, Infra-red data transport, and +simultaneous voice and data (SVD) modems. +The "person" object defined by the CCITT X.500 Series Recommendation +for Directory Services was the primary reference for the properties +that are defined by this specification. Every attempt was made to make +it possible to map the X.520/X.521 attributes and objects into and out +of an instance of a vCard. The vCard specification has extended the +capabilities that have been defined within the CCITT X.500 Series +Recommendation to allow the exchange of additional information often +recorded on business cards and electronic contact managers. For +example, this specification provides support for exchanging graphic +images representing company logos, photographs of individuals, geo- +positioning information, and other extensions to properties defined by +the X.500 Recommendation. +The specification of all date and time values are defined in terms of +the ISO 8601 standard for representation of dates and times. ISO 8601 +supersedes all other international standards defined at the time this +specification was drafted. +The paradigm of an electronic business card is related to the concepts +of an entry in a LAN/WAN directory or an electronic mail address book +or distribution list. However, the requirements of the electronic +business card go beyond the definitions of a "person" object found in +either the CCITT X.500 Series Recommendation, network directory +services, or electronic mail address book products. The vCard +specification is needed to address the requirements for an interchange +format for the "person" personal data type or object. +Personal data applications such as Personal Information Managers (PIM) +often provide an import/export capability using Comma Separated Value +(CSV) or Tab Delimited Files (TDF) formats. However, these solutions +do not preserve the intent of the originating application. When a CSV +and TDF format is used by a PIM, the meta-data or semantics of the +originating object are only apparent to a similar version of the +originating application. Exchange of data between such applications is +another important application of an industry-standard specification +for an electronic business card interchange format, such as the vCard +specification. +Contents +This specification is separated into eight sections: +* "Section 1 : Introduction" introduces PDI and the vCard +specification with an overview, scope statement and section on +definitions and abbreviations. +* "Section 2 : vCard Specification" defines the semantics and +syntax for the vCard. +* "Section 3 : Internet Recommendations" specifies a set of +guidelines to facilitate the exchange of vCard objects over Internet +protocols such as HTTP using HTML and SMTP using MIME. +* "Section 4 : UI Support Recommendations" specifies a set of +guidelines to facilitate the exchange of vCard objects at the desktop +user interface using the file system, clipboard and drag/drop +capabilities of the operating system. +* "Section 5 : Conformance" defines minimum conformance +requirements to consider while developing support for this vCard +specification. +Definitions and Abbreviations +Definitions and abbreviations used within this specification follow. +Electronic Business Card: Also known as vCard. +FPI: Formal Public Identifier. A string expression that represents a +public identifier for an object. FPI syntax is defined by ISO 9070. +GUID: Globally Unique IDentifier +Internet: A WAN connecting thousands of disparate networks in +industry, education, government, and research. The Internet uses +TCP/IP as the standard for transmitting information. +ISO: Organization for International Standardization; a worldwide +federation of national standards bodies (ISO Member bodies). +MIME: Multipurpose Internet Mail Extensions, as defined in RFC1521. +PDA: Personal Digital Assistant computing device +PDI: Personal Data Interchange, a collaborative application area which +involves the communication of data between people who have a business +or personal relationship, but do not necessarily share a common +computing infrastructure. +PIM: Personal Information Manager +RFC#### documents: Internet "Request For Comment" documents (i.e., +RFC822, RFC1521, etc.). +URL: Uniform Resource Locator; a string expression that can represent +any resource on the Internet or local system. RFC 1738 defines the +syntax for an URL. +UTC: Universal Time Coordinated; also known as UCT, for Universal +Coordinated Time. +vCard: The generic term for an electronic, virtual information card +that can be transferred between computers, PDAs, or other electronic +devices through telephone lines, or e-mail networks, or infrared +links. How, when, why, and where vCard are used depends on the +applications developed utilizing a vCard. +versitcard: a vCard. +WAN: Wide-Area Network + + +Section 2 : vCard Specificiation +[DS3] +This section defines the semantics and syntax for the vCard. +A vCard is a collection of one or more properties. A property is a +uniquely named value. A set of properties can be grouped within a +vCard. For example, the properties for a telephone number and comment +can be grouped in order to preserve the coupling of the annotation +with the telephone number. In addition to property groupings, a vC. +versit is developing a comprehensive family of PDI technologies based +on open specifications and interoperability agreements to help meet +this technology need. +Overview +This specification defines a format for an electronic business card, +or vCard. The format is suitable as an interchange format between +applications or systems. The format is defined independent of the +particular method used to transport it. The transport for this +exchange might be a file system, point-to-point asynchronous +communication, wired-network transport, or some form of unwired +transport. +A vCard is a data stream consisting of one or more vCard objects. The +individual vCard definitions can be identified and parsed within the +datastream. The vCard data stream may exist as a persistent form in a +file system, document management system, network connection between +two network endpoints, or in any other digital transport that has an +abstraction of a stream of bytes. +Conceptually, a vCard Writer creates vCard data streams and a vCard +Reader interprets vCard data streams. The vCard Reader and Writer may +be implemented as a single application or as separate applications. It +is not the intent of this specification to define the implementation +of these processes beyond some fundamental capabilities related to the +format of the vCard data stream and a common set of conformance +requirements . +This specification provides for a clear-text encoding that is intended +to be based on the syntax used by the MIME specification (RFC 1521). +The encoding of this specification can be used in environments which +are constrained to 7-bit transfer encodings, short line lengths, and +low bandwidth. In addition, the encoding is simple in order to +facilitate the implementation of reader and writer applications on +small platforms, such as Personal Digital Assistants (PDA), cellular +telephones, or alphanumeric pagers. +Scope +The vCard is intended to be used for exchanging information about +people and resources. In today's business environment, this +information is typically exchanged on business cards. It is +appropriate, then that this specification define this information in +terms of a paradigm based on an electronic business card object. +The ultimate destination for this information is often a collection of +business cards, Rolodex® file, or electronic contact manager. Prior to +the introduction of the vCard specification, users of such +applications typically had to re-key the original information, often +transcribing it from paper business cards. With the advent of the +vCard specification, this information can be exchanged in an automated +fashion. +The basis for the data types supported by this specification have +their origin in openly defined, international standards and in +additional capabilities based on enhancements suggested by the +demonstration of the exchange of prototypical vCards using the +Internet based World-Wide-Web, Infra-red data transport, and +simultaneous voice and data (SVD) modems. +The "person" object defined by the CCITT X.500 Series Recommendation +for Directory Services was the primary reference for the properties +that are defined by this specification. Every attempt was made to make +it possible to map the X.520/X.521 attributes and objects into and out +of an instance of a vCard. The vCard specification has extended the +capabilities that have been defined within the CCITT X.500 Series +Recommendation to allow the exchange of additional information often +recorded on business cards and electronic contact managers. For +example, this specification provides support for exchanging graphic +images representing company logos, photographs of individuals, geo- +positioning information, and other extensions to properties defined by +the X.500 Recommendation. +The specification of all date and time values are defined in terms of +the ISO 8601 standard for representation of dates and times. ISO 8601 +supersedes all other international standards defined at the time this +specification was drafted. +The paradigm of an electronic business card is related to the concepts +of aQuoted-Printable lines of text must also be limited to less than +76 characters. The 76 characters does not include the CRLF (RFC 822) +line break sequence. For example a multiple line LABEL property value +of: +123 Winding Way +Any Town, CA 12345 +USA +Would be represented in a Quoted-Printable encoding as: +LABEL;ENCODING=QUOTED-PRINTABLE:123 Winding Way=0D=0A= + Any Town, CA 12345=0D=0A= + USA +Property parameter substrings are delimited by a field delimiter, +specified by the Semi-colon character (ASCII decimal 59). A Semi-colon +in a property parameter value must be escaped with a Backslash +character (ASCII 92). +Compound property values are property values that also make use of the +Semi-colon, field delimiter to separate positional components of the +value. For example, the Name property is made up of the Family Name, +Given Name, etc. components. A Semi-colon in a component of a compound +property value must be escaped with a Backslash character (ASCII 92). +Grouping +There are two forms of grouping or collections supported within the +vCard. A collection of vCard objects can be grouped and a collection +of properties within an individual vCard can be grouped. +vCard Grouping +The vCard data stream can consist of multiple vCard objects. The vCard +data stream can, sequentially, contain one or more vCard objects., In +addition, the vCard data stream can contain a property whose value is +a nested vCard. In both of these cases, each vCard object will be +delimited by the vCard Delimiters. The vCard Reader conforming to this +specification must be able to parse and process any of these +combinations of vCard Groupings. The support for vCard Grouping is +optional for a vCard Writer conforming to this specification. +Property Grouping +A Property Grouping is the definition of a method for specifying a +collection of related properties within a vCard object. There is no +requirement on a vCard reader that it preserve the property group +name. However, the vCard reader is required to preserve the grouping +of the properties. +The Property Grouping is identified by a character string prefix to +the property name; separated by the Period character (ASCII decimal +46). +The grouping of a comment property with a telephone property is shown +in the following example: +A.TEL;HOME:+1-213-555-1234 +A.NOTE:This is my vacation home. +The vCard Reader conforming to this specification must be able to +parse and process the property grouping. The support for Property +Grouping is optional for a vCard Writer conforming to this +specification. +Encodings +The default encoding for the vCard object is 7-Bit. The default +encoding can be overridden for an individual property value by using +the "ENCODING" property parameter. This parameter value can be either +"BASE64", "QUOTED-PRINTABLE", or "8BIT". This parameter may be used on +any property. +Some transports (e.g., MIME based electronic mail) may also provide an +encoding property at the transport wrapper level. This property can be +used in these cases for transporting a vCard data stream that has been +defined using a default encoding other than 7-bit (e.g., 8-bit). +Character Set +The default character set is ASCII. The default character set can be +overridden for an individual property value by using the "CHARSET" +property parameter. This property parameter may be used on any +property. However, the use of this parameter on some properties may +not make sense. +Any character set registered with the Internet Assigned Numbers +Authority (IANA) can be specified by this property parameter. For +example, ISO 8859-8 or the Latin/Hebrew character set is specified by: +ADR;CHARSET=ISO-8859-8:... +Some transports (e.g., MIME based electronic mail) may also provide a +character set property at the transport wrapper level. This property +can be used in these cases for transporting a vCard data stream that +has been defined using a default character set other than ASCII (e.g., +UTF-8). +Language +The default language is "en-US" (US English). The default language can +be overridden for an individual property value by using the "LANGUAGE" +property parameter. The values for this property are a string +consistent with RFC 1766, Tags for the Identification of Languages. +This property parameter may be used on any property. However, the use +of this parameter on some properties, such as PHOTO, LOGO, SOUND, TEL, +may not make sense. Canadian French would be specified by this +parameter by the following: +ADR;LANGUAGE=fr-CA:... +Value Location +The default location of the property value is inline with the +property. However, for some properties, such as those that specify +multimedia values, it is efficient to organize the property value as a +separate entity (e.g., a file out on the network). The property +parameter "VALUE" can be specified to override the "INLINE" location +of the property value. In the case of the vCard being transported +within a MIME email message, the property value can be specified as +being located in a separate MIME entity with the "Content-ID" value, +or "CID" for short. In this case, the property value is the Content-ID +for the MIME entity containing the property value. In addition, the +property value can be specified as being located out on the network +within some Internet resource with the "URL" value. In this case, the +property value is the Uniform Resource Locator for the Internet +resource containing the property value. This property parameter may be +used on any property. However, the use of this parameter on some +properties may not make sense; for example the Version, Time Zone, +Comment, Unique Identifier, properties . The following specifies a +value not located inline with the vCard but out in the Internet: +PHOTO;VALUE=URL;TYPE=GIF:http://www.abc.com/dir_photos/my_photo.gif +SOUND;VALUE=CONTENT-ID: ; ( 15, 13.) + LF = ; ( 12, 10.) + CRLF = CR LF + SPACE = ; ( 40, 32.) + HTAB = ; ( 11, 9.) +All literal property names are valid as upper, lower, or mixed case. +ws = 1*(SPACE / HTAB) + ; "whitespace," one or more spaces or tabs +wsls = 1*(SPACE / HTAB / CRLF) + ; whitespace with line separators +word = +groups = groups "." word + / word +vcard_file = [wsls] vcard [wsls] +vcard = "BEGIN" [ws] ":" [ws] "VCARD" [ws] 1*CRLF + items *CRLF "END" [ws] ":" [ws] "VCARD" +items = items *CRLF item + / item + ; these may be "folded" +item = [groups "."] name + [params] ":" value CRLF + / [groups "."] "ADR" + [params] ":" addressparts CRLF + / [groups "."] "ORG" + [params] ":" orgparts CRLF + / [groups "."] "N" + [params] ":" nameparts CRLF + / [groups "."] "AGENT" + [params] ":" vcard CRLF + ; these may be "folded" +name = "LOGO" / "PHOTO" / "LABEL" / "FN" / "TITLE" + / "SOUND" / "VERSION" / "TEL" / "EMAIL" / "TZ" / "GEO" / +"NOTE" + / "URL" / "BDAY" / "ROLE" / "REV" / "UID" / "KEY" + / "MAILER" / "X-" word + ; these may be "folded" +value = 7bit / quoted-printable / base64 +7bit = <7bit us-ascii printable chars, excluding CR LF> +8bit = +quoted-printable = +base64 = + ; the end of the text is marked with two CRLF sequences + ; this results in one blank line before the start of the next +property +params = ";" [ws] paramlist +paramlist = paramlist [ws] ";" [ws] param + / param +param = "TYPE" [ws] "=" [ws] ptypeval + / "VALUE" [ws] "=" [ws] pvalueval + / "ENCODING" [ws] "=" [ws] pencodingval + / "CHARSET" [ws] "=" [ws] charsetval + / "LANGUAGE" [ws] "=" [ws] langval + / "X-" word [ws] "=" [ws] word + / knowntype +ptypeval = knowntype / "X-" word +pvalueval = "INLINE" / "URL" / "CONTENT-ID" / "CID" / "X-" word +pencodingval = "7BIT" / "8BIT" / "QUOTED-PRINTABLE" / "BASE64" / "X- +" word +charsetval = +langval = +addressparts = 0*6(strnosemi ";") strnosemi + ; PO Box, Extended Addr, Street, Locality, Region, Postal Code, + Country Name +orgparts = *(strnosemi ";") strnosemi + ; First is Organization Name, remainder are Organization Units. +nameparts = 0*4(strnosemi ";") strnosemi + ; Family, Given, Middle, Prefix, Suffix. + ; Example:Public;John;Q.;Reverend Dr.;III, Esq. +strnosemi = *(*nonsemi ("\;" / "\" CRLF)) *nonsemi + ; To include a semicolon in this string, it must be escaped + ; with a "\" character. +nonsemi = +knowntype = "DOM" / "INTL" / "POSTAL" / "PARCEL" / "HOME" / "WORK" + / "PREF" / "VOICE" / "FAX" / "MSG" / "CELL" / "PAGER" + / "BBS" / "MODEM" / "CAR" / "ISDN" / "VIDEO" + / "AOL" / "APPLELINK" / "ATTMAIL" / "CIS" / "EWORLD" + / "INTERNET" / "IBMMAIL" / "MCIMAIL" + / "POWERSHARE" / "PRODIGY" / "TLX" / "X400" + / "GIF" / "CGM" / "WMF" / "BMP" / "MET" / "PMB" / "DIB" + / "PICT" / "TIFF" / "PDF" / "PS" / "JPEG" / "QTIME" + / "MPEG" / "MPEG2" / "AVI" + / "WAVE" / "AIFF" / "PCM" + / "X509" / "PGP" + + +Section 3 : Internet Recommendations +[DS4] 1 +Recommended Practice with SMTP/MIME +The vCard information can be transported through SMTP/MIME based +electronic mail services. Interoperability of vCard information over +SMTP/MIME transports can be better assured by following a common set +of recommended practices for encapsulation of the vCard. +Text/Plain Content Type +Without any change to existing SMTP or MIME compliant user agents, a +vCard can be included within Internet email messages. This might be +the case for an existing, simple user agent such as a legacy SMTP mail +system. While this approach provides for transport of vCards over SMTP +services, it does not allow for the end user to take advantage of the +full capabilities of either the vCard or Internet email (i.e., MIME) +functionality. +The following demonstrates how a vCard can be included as an epilog to +a SMTP message made up of a RFC 822 message. This may be an initial +method for incorporating vCard objects into SMTP messages. +Date: Thr, 25 Jan 96 0932 EDT +From: john.smith@host.com +Subject: Re: RFC822 vCard Example +Sender: john.smith@host.com +To: smartin@host2.com +Message-ID: + +Steve: Thanks for the call earlier today. I am unable to +use your material at this time. Please feel free to contact +me in the future. +BEGIN:VCARD +VERSION:2.1 +N:Smith;John;M.;Mr.;Esq. +TEL;WORK;VOICE;MSG:+1 (919) 555-1234 +TEL;WORK;FAX:+1 (919) 555-9876 +ADR;WORK;PARCEL;POSTAL;DOM:Suite 101;1 Central St.;Any Town;NC;27654 +END:VCARD +The following example demonstrates how a vCard can be included as a +separate text/plain content portion within current MIME user agents. +Date: Fri, 26 Jan 1996 07:53:00 -0500 +From: smartin@host2.com +Subject: RE: Text/Plain MIME vCard Example +To: fdawson@VNET.IBM.COM +Mime-Version: 1.0 +Content-Type: multipart/mixed; boundary=vcard +Message-ID: + +--vcard +Content-Type:text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +John: I have looked over my material and feel that you may +have over looked a couple of appropriate pieces. Please give +me a call so that we can discuss further. +--vcard +Content-Type:text/plain; charset=us-ascii; name="MARTIN.VCF" + +BEGIN:VCARD +VERSION:2.1 +N:Martin;Stephen +TEL;HOME;VOICE:+1 (210) 555-1357 +TEL;HOME;FAX:+1 (210) 555-0864 +ADR;WORK;PARCEL;POSTAL;DOM:123 Cliff Ave.;Big Town;CA;97531 +END:VCARD +--vcard-- +Text/X-vCard Content Type +A vCard object may also be transferred in a (RFC 1521) MIME entity as +a non-standard "text/x-vCard" content-type. This (RFC 1521) MIME type +maybe useful in those cases where the MIME compliant messaging service +does not yet support the "application/directory" and +"multipart/related" MIME content-types and yet the specificity of a +calendaring and scheduling media type is required. +The following example demonstrates how a vCard can be included as a +separate non-standard text/x-vCard content portion within current MIME +user agents. +Date: Fri, 26 Jan 1996 07:53:00 +0000 +From: smartin@host2.com +Subject: RE: Text/x-vCard MIME vCard Example +To: fdawson@VNET.IBM.COM +Mime-Version: 1.0 +Content-Type: multipart/mixed; boundary=vcard +Message-ID: + +--vcard +Content-Type:text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +John: I have looked over my material and feel that you may +have over looked a couple of appropriate pieces. Please give +me a call so that we can discuss further. +--vcard +Content-Type:text/x-vCard; charset=us-ascii; name="MARTIN.VCF" + +BEGIN:VCARD +VERSION:2.1N:Martin;Stephen +TEL;HOME;VOICE:+1 (210) 555-1357 +TEL;HOME;FAX:+1 (210) 555-0864 +ADR;WORK;PARCEL;POSTAL;DOM:123 Cliff Ave.;Big Town;CA;97531 +END:VCARD +--vcard-- +Application/Directory Content Type +The Internet Engineering Task Force (IETF) Access and Searching of +Internet Directories (ASID) working group has produced an Internet +Draft defining the "application/directory" MIME content type. The +current draft name is draft-ietf-asid-mime-direct-01.txt. This +specification is intended to be aligned with this work. Internet +Drafts are working documents of an IETF working group, valid for at +most six months, and should be considered "works in progress". +This MIME content type was designed to be used to transport directory +information across MIME based electronic mail services. The internet +draft is directly applicable to the exchange of business card data, +such as that defined by the vCard specification. +The versit PDI Team has worked within the IETF ASID Working Group to +draft an application/directory profile that registers the method for +transporting a vCard as an application/directory Content-Type. The +current draft name is draft-ietf-asid-mime-vcard-00.txt. This work is +expected to be progressed to a Request For Comment after the +publication of this version of the vCard specification. In the +interim, the following guidelines are provided to describe how a vCard +might be conveyed using the application/directory draft specification. +A vCard should be included in a MIME message that has a Content-Type +header field value of "multipart/related". The vCard is included in +the message as the primary body part. The position of the body part +entity can also be specified with the "start=" parameter. This MIME +body part entity has a Content-Type body part header field value of +"application/directory" with a "profile" parameter value of "vcard". +Any vCard binary information, such as a logo, picture, or digital +audio pronunciation can be included inline within the vCard, as is +specified by the vCard specification. Preferably, the binary +information should be extracted from the vCard object and contained in +the MIME message as secondary body part entities. The binary content +in the secondary body part entities can be referenced from within the +vCard object through the use of the "VALUE=" property parameter. In +this latter case, the binary information should be transformed into a +content type nominally supported by MIME user agents. For image +content, this would be the Graphics Image Format (GIF) or Joint +Picture Encoding Group (JPEG) formats. For audio content, this would +be the 8-bit mu-law (PCM) format specified by the MIME specification. +The following example defines how this might be specified: +Date: Mon, 29 Jan 96 0830 EDT +From: john.smith@host.com +Subject: Re: MIME application/directory vCard Example +Sender: john.smith@host.com +To: smartin@host2.com +Message-ID: +Content-Type: multipart/related; boundary="vcard"; + type=application/directory; + start= +--vcard +Content-Type: application/directory; charset=us-ascii; + source="file://versit.or2"; profile="vcard" +Content-ID: < +BEGIN:VCARD +VERSION:2.1 +N:Smith;John;M.;Mr.;Esq. +TEL;WORK;VOICE;MSG:+1 (919) 555-1234 +TEL;CELL:+1 (919) 554-6758 +TEL;WORK;FAX:+1 (919) 555-9876 +PHOTO;GIF;MIME:< +ADR;WORK;PARCEL;POSTAL;DOM:Suite 101;1 Central St.;Any Town;NC;27654 +END:VCARD +--vcard +Content-Type: text/plain; charset=us-ascii +Content-ID: < +Steve: +I am not in the office today. You may want to try +reaching me either on my cellular telephone or fax your +new ideas to my office. +Let's setup a face-to-face meeting later this week, after I review +your updated material. I am including a picture in my business card +data, since we have not met yet. +-- John +--vcard +Content-Type: image/gif +Content-ID: < +...image data would go here... +--vcard-- +Recommended Practice with HTTP/HTML +A vCard object should be transferred over HTTP with the non-standard +MIME type/subtype value of "text/x-vCard". The non-standard subtype +should be used because the vCard has not been registered as a MIME +media type with the IANA. +The vCard information can be captured with a FORM type of HTML +document. Interoperability of of vCard information can be better +assured by following a common set of recommended practices for mapping +vCard information into and out of HTML documents. +Form Element Usage +The HTML FORM element is a useful method for capturing data intended +for input into individual vCard property values. The following +recommended practices are provided for such use. +Mapping To INPUT Element Attribute Names +An HTML form data set is a useful mechanism for capturing vCard data +within the Internet WWW. The use of a consistent naming scheme for the +name attributes within a form element will permit implementations to +support automatic fill-in of forms with existing vCard data. In +addition, such a consistent naming scheme will provide a greater +assurance of interoperability between HTML based applications that use +vCard data. +The following table provides a recommended mapping of vCard properties +and name attributes within a form element. +Identification Properties +Description +Attribute Name +Comment + +Formatted Name +FN + + +Name +N +Individual components of name property are captured as separate input +elements with the names N.Family, N.First, N.Middle, N.Prefix, +N.Suffix. + +Photograph +PHOTO +Only the URL based specification is supported by this mapping. Value +is the URL for the graphic. + +Photograph Format Type +PHOTO.Type +Where the value is one of the enumerated strings defined by the vCard +specification. + +Birthdate +BDAY + + + +Delivery Addressing Properties +Description +Attribute Name +Comment + +Delivery Address +ADR +TYPE=TEXTAREA + +Address Type +ADR.x +TYPE=CHECKBOX. Separate input elements are used to capture the +possible delivery types. The elements are named ADR.x, where x is one +of the enumerated strings defined by the vCard specification. + +Delivery Label +LABEL + + +Label Type +LABEL.x +TYPE=CHECKBOX. Separate input elements are used to capture the +possible delivery types. The elements are named LABEL.x, where x is +one of the enumerated strings defined by the vCard specification. + + +Telecommunications Addressing Properties +Description +Attribute Name +Comment + +Telephone Number +TEL + + +Telephone Type +TEL.x +TYPE=CHECKBOX. Separate input elements are used to capture the +possible telephone types. The elements are named TEL.x, where x is one +of the enumerated strings defined by the vCard specification. + +Electronic Mail Address +EMAIL + + +Electronic Mail Address Type +EMAIL.Type +Selection option from a list of alternatives. + +Mailer +MAILER + + + +Geographical Properties +Description +Attribute Name +Comment + +Time Zone +TZ + + +Geographic Position +GEO + + + +Organizational Properties +Description +Attribute Name +Comment + +Title +TITLE + + +Business Category +ROLE + + +Logo +LOGO +Only the URL based specification is supported by this mapping. Value +is the URL for the graphic. + +Logo Format Type +LOGO.Type +Where the value is one of the enumerated strings defined by the vCard +specification. + +Agent + +Captured through a separate form element using the mapping defined in +these tables. + +Organization +ORG +TYPE=TEXT. Separate input elements for the organizational name and +unit. The name ORG.Name is used to capture the organizational name. +The name ORG.UNIT is used to capture the organizational unit. If there +are multiple organizational units, it is captured in a form with name +attributes ORG.UNIT1, ORG.UNIT2, etc. + + +Explanatory Properties +Description +Attribute Name +Comment + +Comment +NOTE +TYPE=TEXT + +Last Revision +REV +A hidden field. + +Version +VERSION +A hidden field with the value set to the string ?2.1?. + +Language +LANG +A hidden field with the value set to the string associated with the +default language used in the form (e.g., US-eng). + +Sound +SOUND +TYPE=TEXT + +Sound Type +N/A + + +Uniform Resource Locator +URL +TYPE=TEXT + +Unique Identifier +UID +TYPE=TEXT + +Binary Encoding +BE.x +Where x is one of the enumerated encoding types defined by the vCard +specification. + + +Security Properties +Description +Attribute Name +Comment + +Public Key +KEY + + +Key Type +KEY.Type.x +Where x is one of the enumerated encoding types defined by the vCard +specification. + +MISCELLANEOUS PROPERTIES + + + +Extensions +X-x +Where x is a string defined by the extension author. + + +Where multiple properties (e.g., telephone numbers) appear, a label +prefix should be used. For example, telephone #1 might have a name +attribute of ?A.TEL?, telephone #2 might have a name attribute of +?B.TEL?, etc. +Example HTML Code +The following HTML code is an example of the use of the mapping of +INPUT element attributes names to vCard property names. The code can +be used to capture input data for creating a vCard on a Web homepage. + + +Create Your Own Versitcard + + +

Create Your Own Versitcard

+

Fill out this form and we'll +create a Versitcard for you and send it to the email address of +your choice, +along with more information on the Versitcard format.

+
+
+Formatted Name:
+Phoenetic Pronunciation:
+Company Name:
+Company Unit:
+Title: +
+Family Name:
+Given Name:
+Middle Name:
+Name Prefix:
+Name Suffix:
+
+Delivery Label:

+Post Office Address:
+Extended Address:
+Street Address:
+City: +Region: +Postal Code:
+Country Name: +Work +Home +Parcel +Postal
+
+TimeZone: +Location:
+
+ +Telephone #1:
+Work +Home +Voice +Msg Fax Preferred
+
+Telephone #2:
+Work Home +Voice Msg +Fax +Preferred
+
+Telephone #3:
+Work +Home Voice Msg +Fax Preferred
+
+EmailAddress: +Work +Home
+
+Send my Versitcard to this internet email address: +
+Press to send the form now. Or, press + to reset values to the form defaults. +
+ + + +Section 4 : UI Support Recommendations +[DS5] +When integrating vCard support into an application, an implementor +needs to consider a number of user interface (UI) implications. Most +appliss Type +ADR.x +TYPE=CHECKBOX. Separate input elements are used to capture the +possible delivery types. The elements are named ADR.x, where x is one +of the enumerated strings defined by the vCard specification. + +Delivery Label +LABEL + + +Label Type +LABEL.x +TYPE=CHECKBOX. Separate input elements are used to capture the +possible delivery types. The elements are named LABEL.x, where x is +one of the enumerated strings defined by the vCard specification. + + +Telecommunications Addressing Properties +Description +Attribute Name +Comment + +Telephone Number +TEL + + +Telephone Type +TEL.x +TYPE=CHECKBOX. Separate input elements are used to capture the +possible telephone types. The elements are named TEL.x, where x is one +of the enumerated strings defined by the vCard specification. + +Electronic Mail Address +EMAIL + + +Electronic Mail Address Type +EMAIL.Type +Selection option from a list of alternatives. + +Mailer +MAILER + + + +Geographical Properties +Description +Attribute Name +Comment + +Time Zone +TZ + + +Geographic Position +GEO + + + +Organizational Properties +Description +Attribute Name +Comment + +Title +TITLE + + +Business Category +ROLE + + +Logo +LOGO +Only the URL based specification is supported by this mapping. Value +is the URL for the graphic. + +Logo Format Type +LOGO.Type +Where the value is one of the enumerated strings defined by the vCard +specification. + +Agent + +Captured through a separate form element using the mapping defined in +these tables. + +Organization +ORG +TYPE=TEXT. Separate input elements for the organizational name and +unit. The name ORG.Name is used to capture the organizational name. +The name ORG.UNIT is used to capture the organizational unit. If there +are multiple organizational units, it is captured in a form with name +attributes ORG.UNIT1, ORG.UNIT2, etc. + + +Explanatory Properties +Description +Attribute Name +Comment + +Comment +NOTE +TYPE=TEXT + +Last Revision +REV +A hidden field. + +Version +VERSION +A hidden field with the value set to the string ?2.1?. + +Language +LANG +A hidden field with the value set to the string associated with the +default language used in the form (e.g., US-eng). + +Sound +SOUND +TYPE=TEXT + +Sound Type +N/A + + +Uniform Resource Locator +URL +TYPE=TEXT + +Unique Identifier +UID +TYPE=TEXT + +Binary Encoding +BE.x +Where x is one of the enumerated encoding types defined by the vCard +specification. + + +Security Properties +Description +Attribute Name +Comment + +Public Key +KEY + + +Key Type +KEY.Type.x +Where x is one of the enumerated encoding types defined by the vCard +specification. + +MISCELLANEOUS PROPERTIES + + + +Extensions +X-x +Where x is a string defined by the extension author. + + +Where multiple properties (e.g., telephone numbers) appear, a label +prefix should be used. For example, telephone #1 might have a name +attribute of ?A.TEL?, telephone #2 might have a name attribute of +?B.TEL?, etc. +Example HTML Code +The following HTML code is an example of the use of the mapping of +INPUT element attributes names to vCard property names. The code can +be used to capture input data for creating a vCard on a Web homepage. + + +Create Your Own Versitcard + + +

Create Your Own Versitcard

+

Fill out this form and we'll +create a Versitcard for you and send it to the email address of +your choice, +along with more information on the Versitcard format.

+
+
+Formatted Name:
+Phoenetic Pronunciation:
+Company Name:
+Company Unit:
+Title: +
+Family Name: