From b9c39f1f1365fc41e544ffd9f0687b35f36ae881 Mon Sep 17 00:00:00 2001 From: Miles Lott Date: Wed, 21 Mar 2001 05:19:00 +0000 Subject: [PATCH] Moving to doc dir --- addressbook/vcard-21.txt | 2335 -------------------------------------- 1 file changed, 2335 deletions(-) delete mode 100644 addressbook/vcard-21.txt diff --git a/addressbook/vcard-21.txt b/addressbook/vcard-21.txt deleted file mode 100644 index 85e08b7e90..0000000000 --- a/addressbook/vcard-21.txt +++ /dev/null @@ -1,2335 +0,0 @@ -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: