vCard
The Electronic Business Card
Version 2.0

A versit Consortium Specification
April 29, 1996

© 1995, 1996, Apple Computer, Inc., AT&T Corp., International Business Machines Corp., 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. Apple Computer, Inc., AT&T Corp., International Business Machines Corp., and Siemens retain all their intellectual property rights in the technology described in this publication. 
Even though Apple Computer, Inc., AT&T Corp., International Business Machines Corp., and Siemens have reviewed this specification, APPLE COMPUTER, INC., AT&T CORP., INTERNATIONAL BUSINESS MACHINES CORP., 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 APPLE COMPUTER, INC., AT&T CORP., INTERNATIONAL BUSINESS MACHINES CORP., 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, Bentogram and Simplegram are trademarks of Apple Computer, Inc., AT&T Corp., International Business Machines Corp., and Siemens.
Apple, the Apple Logo, AppleLink, Bento, eWorld, Macintosh, OpenDoc and PowerShare are 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 & Assoc.
Masanari Arai, Puma Technologies
Stephen W. Bartlett
Donal Carroll
Liang-Jye Chang, Starfish Software
Frank Dawson, IBM Corporation
Ken Dobson, IntelliLink Inc.
Anik Ganguly, Campbell Services Inc.
Beijing Goo, Microsoft
Arvind K. Goyal, Lotus Development Corp.
Gary Hand, IBM Corporation
Tim Howes, University of Michigan
Kerry Kelly, Now Software, Inc.
Phac Letuan, Apple Computer
Pat Megowan, Counterpoint Sytems Foundry Inc.
Tohri Mori, IBM Japan/Salutation
Ravi Pandya, NetManage, Inc.
Steven Rummel, AT&T
Michael Santullo, Four11 Corp.
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.
•	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 tmes, 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.
•	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.
•	CI Labs: Component Integration Laboratories, P.O. Box 61747, Sunnyvale, CA 94088-1747 (408) 864-0300, (408) 864-0380 [FAX], Internet: info@cilabs.org
•	Harris, Jed and Ira Ruben, Bento Specification, revision 1.0d5, Apple Computer, Inc., July, 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.
•	Tagged Image File Format, version 6.0, Aldus Corporation, 1992. Available from the Aldus Developer’s Desk, 411 First Avenue South, Seattle, WA 98104-2871, 
+1 (206) 628-6593, Compuserve: GO ALDSVC, Applelink: Aldus Developers’ Icon, 
FTP: <zamenhof.cs.rice.edu:/pub/graphics.formats>
•	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

Contents
Section 1 : Introduction	
1.1 Overview	
1.2 Scope	
1.3 Contents	
1.4 Definitions and Abbreviations	3
Section 2 : Functional Definition of vCard	5
2.1 Identification Properties	5
2.1.1 Formatted Name	5
2.1.2 Family Name	5
2.1.3 Given Name	5
2.1.4 Additional Names	5
2.1.5 Photograph	6
2.1.6 Birthdate	6
2.2 Delivery Addressing Properties	6
2.2.1 Post Office Address	6
2.2.2 Extended Address	6
2.2.3 Street Address	6
2.2.4 City	6
2.2.5 Region	6
2.2.6 Postal Code	7
2.2.7 Country Name	7
2.2.8 Delivery Label	7
2.2.9 Delivery Type	7
2.3 Telecommunications Addressing Properties	7
2.3.1 Telephone Number	7
2.3.1.1 Telephone Type	8
2.3.2 Electronic Mail	8
2.3.3 Mailer	8
2.4 Geographical Properties	8
2.4.1 Time Zone	8
2.4.2 Location	9
2.5 Organizational Properties	9
2.5.1 Title	9
2.5.2 Business Category	9
2.5.3 Logo	9
2.5.4 Agent	10
2.5.5 Organization Name	10
2.5.6 Organizational Unit	10
2.6 Explanatory Properties	10
2.6.1 Comment	10
2.6.2 Last Revision	10
2.6.3 Character Set	10
2.6.4 Language	11
2.6.5 Sound	11
2.6.6 Uniform Resource Locator	11
2.6.7 Unique Identifier	11
2.7 Security Properties	11
2.7.1 Public Key	11
Section 3 : Simplegram	13
3.1 Encoding Characteristics	13
3.1.1 Encodings	13
3.1.2 Character Set	13
3.1.3 Language	13
3.1.4 Value Location	13
3.1.5 vCard Object	14
3.1.6 Property	14
3.1.7 Delimiters	15
3.1.8 Grouping	15
3.1.8.1 vCard Grouping	15
3.1.8.2 Property Grouping	15
3.1.9 Binary Values	15
3.2 Identification Properties	16
3.2.1 Formatted Name	16
3.2.2 Name	16
3.2.3 Photograph	16
3.2.3.1 Photo Format Type	17
3.2.4 Birthdate	17
3.3 Delivery Addressing Properties	18
3.3.1 Address	18
3.3.1.1 Delivery Address Type	18
3.3.2 Address Delivery Label	18
3.3.2.1 Delivery Label Type	19
3.4 Telecommunications Addressing Properties	19
3.4.1 Telephone Number	19
3.4.1.1 Telephone Type	19
3.4.2 Electronic Mail	20
3.4.2.1 Electronic Mail Type	20
3.4.3 Mailer	21
3.4.4 Geographical Properties	21
3.4.5 Time Zone	21
3.4.6 Location	21
3.5 Organizational Properties	22
3.5.1 Title	22
3.5.2 Business Category	22
3.5.3 Logo	22
3.5.3.1 Logo Format Type	22
3.5.4 Agent	23
3.5.5 Organization	23
3.6 Explanatory Properties	24
3.6.1 Comment	24
3.6.2 Last Revision	24
3.6.3 Sound	24
3.6.3.1 Sound Digital Audio Type	25
3.6.4 Uniform Resource Locator	25
3.6.5 Unique Identifier	25
3.7 Security Properties	25
3.7.1 Public Key	25
3.7.2 Key Type	26
3.8 Miscellaneous Properties	26
3.8.1 Extensions	26
3.9 Formal Definition	27
Section 4 : Bentogram	29
4.1 Encoding Characteristics	29
4.1.1 Character Set	29
4.1.2 Objects	30
4.1.3 Grouping	31
4.1.4 Bit-Level Data Representation	31
4.2 Properties	32
4.2.1 VCRootObject Properties	32
4.2.1.1 VCBodyProp	32
4.2.1.2 VCUniqueStringProp	32
4.2.1.3 VCLastRevisedProp	33
4.2.1.4 VCMyReferenceProp and VCYourReferenceProp	33
4.2.1.5 VCMsgProp	34
4.2.1.6 VCLogoProp	34
4.2.1.7 VCPartProp	35
4.2.1.8 VCEncryptionProp	35
4.2.2 VCBodyObject Properties	35
4.2.2.1 VCNextObjectProp	36
4.2.2.2 VCDeliveryLabelProp	36
4.2.2.3 VCCountryNameProp	36
4.2.2.4 VCPostalCodeProp	36
4.2.2.5 VCRegionProp	37
4.2.2.6 VCCityProp	37
4.2.2.7 VCFormattedNameProp	37
4.2.2.8 VCTitleProp	38
4.2.2.9 VCOrgUnitProp	38
4.2.2.10 VCOrgNameProp	38
4.2.2.11 VCFamilyNameProp	39
4.2.2.12 VCGivenNameProp	39
4.2.2.13 VCSoundProp	39
4.2.2.14 VCLanguageProp	39
4.2.2.15 VCTelephoneProp	39
4.2.2.16 VCEmailAddressProp	40
4.2.2.17 VCMailerProp	40
4.2.2.18 VCURLProp	40
4.2.2.19 VCAgentProp	41
4.2.2.20 VCTimeZoneProp	41
4.2.2.21 VCLocationProp	41
4.2.2.22 VCCaptionProp	42
4.2.3 VCPartObject	42
4.2.3.1 VCCommentProp	43
Section 5 : Internet Recommendations	44
5.1 Recommended Practice With SMTP/MIME	44
5.1.1 Text/Plain Content Type	44
5.1.2 Application/Directory Content Type	45
5.2 Recommended Practice With HTTP/HTML	46
5.2.1 Form Element Usage	46
5.2.2 Mapping To INPUT Element Attribute Names	47
5.2.3 Example HTML Code	50
Section 6 : UI Support Recommendations	53
6.1 File System	53
6.2 Clipboard	53
6.3 Drag/Drop	53
Section 7 : Conformance	54

Section 1 : Introduction
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.
1.1	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 .
The format for this specification separates the definition of the vCard semantics from its syntax. The purpose of this is to provide a common semantic definition, independent of a particular transfer syntax. Additionally, such separation may facilitate the definition of other syntaxes as they are required. The rationale for multiple encodings or syntaxes is that “one size does NOT fit all” applications or platform requirements. This separation of semantics from syntax will greatly facilitate rendering of a common semantic definition in multiple syntaxes. This is desirable in order to permit the transformation of one data stream syntax into another (e.g., clear-text to/from binary). The specification also includes a formal grammar for the clear-text encoding to aid in the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the specification.
This specification provides for a clear-text or Simplegram and a binary or Bentogram encoding.
The clear-text 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.
The binary encoding of this specification can be used in environments which have requirements for supporting more robust data structures than that offered by the clear-text encoding. In addition, the binary encoding provides a more generalized container for encapsulating a mix of different objects. The format is designed to facilitate the editing and update of components within the vCard.
1.2	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.
1.3	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 : Functional Definition of vCard” defines the common semantics for an electronic business card, called vCard.
•	“Section 3 : Simplegram” defines the syntax for a clear-text encoding of the vCard.
•	“Section 4 : Bentogram” defines the syntax for a binary encoding of the vCard.
•	“Section 5 : 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 6 : 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 7 : Conformance” defines minimum conformance requirements to consider while developing support for this vCard specification.
1.4	Definitions and Abbreviations
Definitions and abbreviations used within this specification follow.
API: Application Programming Interface
Bentogram: A syntax for encoding the vCard in a binary encoding. Bentograms are based on Bento, the OpenDoc standard interchange format.
Electronic Business Card: Also know 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.).
Simplegram: A syntax for encoding the vCard in a clear-text encoding. Simplegrams are nominally, based on the ASCII, 7-bit character set.
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 : Functional Definition of vCard
This section defines the semantics or functional definition of the vCard. The semantics are intended as a common set of the meta-data to be used in creating individual encodings or syntaxes.
Specific encodings may require additional functional elements to convey options relevant to that encoding (e.g., Binary Encoding property in the clear-text encoding). These properties are not specified in this section, but defined as a part of the particular encoding.
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 vCard can include other, nested vCard objects. This allows for the recording of information about a secondary person or object associated with a given person or object. Additionally, this allows for the specification of a distribution list or work group of multiple vCard objects.
2.1	Identification Properties
These property types are concerned with information associated with the identification and naming of the individual or resource associated with the vCard object.
2.1.1	Formatted Name
This property specifies the formatted name string associated with the vCard object. This is the way that the name is to be displayed. It can contain desired honorific prefixes, suffixes, titles, etc. For example, “Mr. John Q. Public, Jr.”, Dr. Ann Tyler, or Hon. Judge Blackwell. This property is based on the semantics of the X.520 Common Name attribute.
2.1.2	Family Name
This property specifies the family, last, or surname associated with the vCard object. For example, “Public”. This property is based on the semantics of the X.520 Surname attribute.
2.1.3	Given Name
This property specifies the given or first name associated with the vCard object. For example, “John”.
2.1.4	Additional Names
This property specifies any middle name or additional names associated with the vCard object. For example, “Quinland” or “Q”.
2.1.5	Photograph
This property specifies an image or photograph of the individual associated with the vCard.
2.1.6	Birthdate
This property specifies the date of birth of the individual associated with the vCard. The value for this property is a calendar date in a complete representation consistent with ISO 8601.
2.2	Delivery Addressing Properties
These property types are concerned with information associated with the delivery addressing of the vCard object.
2.2.1	Post Office Address
This property defines the physical delivery address component assigned by the postal authority; such as a Post Office Box. This property is based on the X.500 Post Office Box attribute.
2.2.2	Extended Address
This property defines extended or additional local site details required for physical delivery to the vCard object. The property might include information about the P. O. Box, suite number, mail drop, etc. This property extends the semantics of the X.500 Post Office Box attribute.
2.2.3	Street Address
This property defines the local site associated with physical delivery to the vCard object. This property might include information about the street name, place, avenue, suite, apartment, or house number. This property is based on the X.520 Street Address geographical attribute.
2.2.4	City
This property defines the name of the locality or city associated with the postal addressing information for the vCard object. For example, “San Francisco”. This property is based on the X.520 Locality Name geographical attribute.
2.2.5	Region
This property defines the name of the region, state, or province associated with the postal addressing information for the vCard object. The property value may be abbreviated. For example, “CA” or “California”. This property is based on the X.520 State or Province Name geographical attribute.
2.2.6	Postal Code
This property defines the postal or ZIP code associated with the postal addressing information for the vCard object. This property is based on the X.520 Postal Code attribute.
2.2.7	Country Name
This property defines the name of the country associated with the postal addressing information for the vCard object. This property is based on the X.520 Country Name geographical attribute.
2.2.8	Delivery Label
This property specifies the addressing label for physical delivery to the person/object associated with the vCard. The property is intended to include the information necessary to create a formatted delivery address label. Typical information includes the name, street address, possibly a Post Office or mail drop, city, state or province, zip or postal code. An international delivery label would also include the country name. 
This property is based on the semantics of the X.520 Postal Address attribute. This specification has added semantics to those defined by the X.500 Series standard for differentiating Home, Work, Parcel, Postal, Domestic, and International delivery label types.
2.2.9	Delivery Type
This property specifies the sub-types of physical delivery that is associated with the label. For example, the label may need to be differentiated for Home, Work, Parcel, Postal, Domestic, and International physical delivery. One or more sub-types can be specified for a given delivery label.
2.3	Telecommunications Addressing Properties
These property types are concerned with information associated with the telecommunications addressing of the vCard object.
2.3.1	Telephone Number
This property specifies the telephone number for telephony communication with the vCard object. The value of this property is specified in a canonical form in order to specify an unambiguous representation of the globally unique telephony endpoint. This property is based on the X.520 Telephone Number attribute.
The canonical form cannot be dialed without first being transformed by a dialing algorithm. The dialing algorithm combines the canonical number string with knowledge of the local dialing procedures, in effect at the time of call placement to produce actual dialing instructions. The actual dialing algorithm is outside the scope of this specification.
Two important canonical forms allowed by this specification are:
•	Apple Computer’s Representation of a Canonical Static DeviceID in The Telephony Suite, version 1.0,
•	Microsoft TAPI in the Microsoft Windows 3.1 Telephony Programmer’s Guide, version 1.0.
Software which creates this property can store a string sourced from these allowed formats. Dialing software should be prepared to parse numbers from either of the supported formats; as neither format is considered to be technically costly to support.
2.3.1.1	Telephone Type
This property specifies the sub-type of telephone that is associated with the telephone number (e.g., Home, Work, Cellular, Facsimile, Video, Modem, Message Service, or Preferred). One or more sub-type values can be specified for a given telephone number.
2.3.2	Electronic Mail
This property specifies the address for electronic mail communication with the vCard object. The address is in the form of a specific addressing type. For example, the Internet mail address for John Public might be “John.Public@abc.com” or the CompuServe Information Service address might be “71234,5678”.
2.3.3	Mailer
This property specifies the type of electronic mail software that is in use by the individual associated with the vCard object. This information may provide assistance to a correspondent regarding the type of data representation which can be used, and how they may be packaged. This property is based on currently accepted practices within the Internet MIME community with the “X-Mailer” header field.
2.4	Geographical Properties
These property types are concerned with information associated with geographical positions or regions associated with the vCard object.
2.4.1	Time Zone
This property specifies information related to the time zone of the vCard object. The time zone is a string as specified in a manner consistent with ISO 8601. It is an offset from Coordinated Universal Time (UTC). An ISO 8601 UTC offset, in basic format, is specified as a positive or negative difference in units of hours and minutes (e.g., +hhmm). If minutes are zero, then they may be omitted and the format would be specified in units of hours (e.g., +hh). The time is specified as a 24-hour clock. Hour values are from 00 to 24, and minute values are from 00 through 59. Hour and minute values are 2-digits with high-order zeroes required to maintain digit count. The extended format for ISO 8601 makes use of a colon (i.e., “:”) character as a separator of the hour and minute substrings.
2.4.2	Location
This property specifies information related to the global positioning of the vCard object. The property specifies a longitude and latitude. The latitude represents the location north and south of the equator as a positive or negative number, respectively. The longitude represents the location east and west of the prime meridian as a positive or negative number, respectively.
The rationale behind providing support for this property is that it is relatively simple for a vCard object to provide this information compared with how difficult it would be for a receiver of a vCard to determine the global location through some other means.
2.5	Organizational Properties
These property types are concerned with information associated with characteristics of the organizations or organizational units associated with the vCard object.
2.5.1	Title
This property specifies the job title, functional position or function of the individual associated with the vCard object within an organization. This property is based on the X.520 Title attribute. For example, “Vice President, Research and Development”.
2.5.2	Business Category
This property specifies information concerning the role, occupation, or business category of the vCard object within an organization. This property is based on the X.520 Business Category  explanatory attribute. For example, “Programmer”. This property is included as an organizational property to avoid confusion with the Title property and to avoid incorrect use of the Title property to record Business Category information.
2.5.3	Logo
This property specifies an image or graphic of the logo of the organization that is associated with the individual the vCard belongs to.
2.5.4	Agent
This property specifies information about another person who will act on behalf of the vCard object. Typically this would be an area administrator, assistant, or secretary for the individual. A key characteristic of the Agent property is that it represents somebody or something which is separately addressable. For example, if all phone calls or e-mail messages are normally screened by an agent, this property may not be needed. On the other hand, if an agent can act as a proxy, and may otherwise need to be contacted separately, then an Agent property is useful.
This property is equivalent to nesting another vCard with the specified vCard.
2.5.5	Organization Name
This property specifies the name of the organization associated with the vCard object. This property is based on the X.520 Organization Name attribute. For example, “The AB Corporation”.
2.5.6	Organizational Unit
This property specifies the name of the organization unit associated with the vCard object. This property is based on the X.520 Organization Unit attribute. For example, “North American Division”.
2.6	Explanatory Properties
These property types are concerned with additional explanations, such as that related to national language support, or encoding specifics of  the vCard object.
2.6.1	Comment
This property specifies supplemental information or a comment that is associated with the vCard. With the use of property grouping, the association can be limited to a group of properties. The property is based on the X.520 Description attribute.
2.6.2	Last Revision
This property specifies the combination of the calendar date and time of day of the last update to the vCard object. The property value is a character string conforming to the basic or extended format of ISO 8601. The value can either be in terms of local time or UTC.
2.6.3	Character Set
This property specifies the character set used to encode the character data in the vCard object. The value is an ISO 9070-based Formal Public Identifier (FPI) for any registered character set.
2.6.4	Language
This property specifies the language used for information associated with the vCard object. This property is based on the Internet document RFC 1766, Tags for Identification of Languages. The values of this property are a string conforming to tag values defined in RFC 1766. For example, United States - English would be specified by the value “en-US”.
2.6.5	Sound
This property specifies a sound annotation for the vCard object. By default, if this property is not grouped with other properties it specifies the pronunciation of the Formatted Name property of the vCard object. Such information may be in the form of a string of characters representing a phonetic sound or in the form of a digitized sound, or both; subject to the limitations imposed by the encoding used to communicate the vCard.
2.6.6	Uniform Resource Locator
This property specifies a value that represents a Uniform Resource Locator (URL). An URL is a representation of an Internet location that can be used to obtain real-time information about the vCard object. Application of this property might be to specify the location of a publicly accessible directory where up-todate or additional information on the individual or resource associated with a vCard can be found.
2.6.7	Unique Identifier
This property specifies a value that represents a globally unique identifier associated with the object. The property can be used as a mechanism to relate different vCard objects. Some examples of valid forms of unique identifiers would include ISO 9070 formal public identifiers (FPI), X.500 distinguished names, machine-generated “random” numbers with a statistically high likelihood of being globally unique and Uniform Resource Locators (URL). If an URL is specified, it is suggested that the URL reference a service which will produce an updated version of the vCard.
2.7	Security Properties
These property types are concerned with the security of communication pathways or access to the vCard object.
2.7.1	Public Key
This property specifies the public encryption key associated with the vCard object.

Section 3 : Simplegram
This section defines the syntax for encoding the vCard in a simple, clear-text encoding.
3.1		Encoding Characteristics
The following characteristics are specific to this encoding.
3.1.1	Encodings
The default encoding for the vCard object is 7-Bit. Multiple line type values are not allowed for 7-Bit encoding. The default encoding can be overridden for an individual property by using the “ENCODING” property parameter. The parameter value can be reset to either “BASE64” or “QUOTED-PRINTABLE”. This property parameter may be used on any property.
3.1.2	Character Set
The default character set is US-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:...
3.1.3	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 not make sense. For example, Canadian French would be specified by:
ADR;LANGUAGE=fr-CA:...
3.1.4	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. 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 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
3.1.5	vCard Object
A vCard data stream may include one or more vCard objects. An individual vCard object is identified within a data stream by the appearance of the Begin vCard Delimiter:
BEGIN:vCard
The sentinel string must appear as the first characters in the data stream or the first characters on a line.
The vCard object is terminated with either the logical end of the data stream or the appearance of the End vCard Delimiter as the first character on a line:
END:vCard
3.1.6	Property
A property is the definition of an individual attribute describing the person/object associated with the vCard. A property takes the following form:
PropertyName [;‘] [PropertyParameters] ’:‘ PropertyValue
as shown in the following example:
TEL;HOME;VOICE;MSG;FAX:+1-213-555-1234
The property name can be one of a set of pre-defined strings. In the previous example, “T” is the name of the Telephone property. Property sub-types are specified as property parameters; providing additional information about the property value. Property values are specified as strings. In the previous example, “+1-213-555-1234” is the Telephone property value.
A property value can be further qualified with a property parameter expression. In the previous example, “HOME;VOICE;MSG;FAX” is the property parameter to specify that the telephone is for a home, voice, voice-mail, and facsimile number. Property parameter expressions are delimited from the property name with a Semi-colon character (ASCII 59). The property parameter expressions are specified as either a name=value or a value string. The value string can be specified alone in those cases where the value is unambiguous. The following example is of a complete property parameter expression:
NOTE;ENCODING=QUOTED-PRINTABLE:The fax machine is operational=
 only from 8am to 5:30pm
The following example is of a property expression with the value string only:
TEL;HOME:+1-213-555-1234
3.1.7	Delimiters
Individual property definitions within the vCard data stream are delimited by the Property Delimiter, specified by any valid line ending protocol. For example in 7-bit ASCII, Carriage Return character (ASCII decimal 13), Line Feed character(ASCII decimal 10), or Carriage Return character followed by Line Feed character, or the Property Delimiter.
Property parameter substrings are delimited by the Field Delimiter, specified by the Semi-Colon character (ASCII decimal 59).
3.1.8	Grouping
There are two forms of grouping or collections supported within the vCard clear-text encoding. A collection of vCard objects can be grouped and a collection of properties within an individual vCard can be grouped.
3.1.8.1	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 Delimiter. 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.
3.1.8.2	Property Grouping
A Property Grouping is the definition of a method for specifying a collection of 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.
3.1.9	Binary Values
The clear-text encoding for the vCard supports inclusion of binary information, such as computer graphic images, digital audio, or video graphic images. The binary information may either be referenced with a Uniform Reference Locator (URL) or  placed inline in the vCard as the value of a property. Inline binary information is included as a property value after being encoded into clear-text with a Base 64 (default) or Quoted-Printable encoding
3.2	Identification Properties
These property types are concerned with information associated with the identification and naming of the individual or resource associated with the vCard object.
3.2.1	Formatted Name
This property is identified by the property name FN. Support for this property is optional for vCard Writers conforming to this specification. The following is an example of the Formatted Name property:
FN:Mr. John Q. Public, Esq.
3.2.2	Name
This property is identified by the property name N. This property is defined within the clear-text encoding to encapsulate the individual components of an object’s name.. The property value consists of the components of the name specified as positional fields separated by the Field Delimiter character (ASCII decimal 59). The property value is a concatenation of the Family Name (first field), Given Name (second field), Additional Names (third field), Name Prefix (fourth field), and Name Suffix (fifth field) strings. Support for this property is mandatory for vCard Writers conforming to this specification. All vCard data streams should include this property to facilitate a common property for collating and sorting of vCard objects. The following is an example of the Name property:
N:Public;John;Quinlan;Mr.;Esq.
3.2.3	Photograph
The property is identified by the property name PHOTO. Support for this property is optional for vCard Writers conforming to this specification. For example, the following syntax is an example of a referenced image file:
PHOTO:file://jqpublic.gif
 The following example is the syntax for including an inline GIF image file, using the Base 64 encoding:
PHOTO;ENCODING=BASE64;TYPE=GIF:
    R0lGODdhfgA4AOYAAAAAAK+vr62trVIxa6WlpZ+fnzEpCEpzlAha/0Kc74+PjyGM
    SuecKRhrtX9/fzExORBSjCEYCGtra2NjYyF7nDGE50JrhAg51qWtOTl7vee1MWu1
    50o5e3PO/3sxcwAx/4R7GBgQOcDAwFoAQt61hJyMGHuUSpRKIf8A/wAY54yMjHtz
...
3.2.3.1	Photo Format Type
This property parameter is provided in the clear-text encoding to specify the graphics format for the Photo property value. Support for this property is optional for vCard Writers conforming to this specification. This property is specified as a property parameter of the Photo property. The property parameter includes the following values:

Description	Property Parameter Value	
TYPE=		
Indicates Graphics Interchange Format	GIF	
Indicates ISO Computer Graphics Metafile	CGM	
Indicates MS Windows Metafile	WMF	
Indicates MS Windows Bitmap	BMP	
Indicates IBM PM Metafile	MET	
Indicates IBM PM Bitmap	PMB	
Indicates MS Windows DIB	DIB	
Indicates an Apple Picture format	PICT	
Indicates a Tagged Image File Format	TIFF	
Indicates Adobe PostScript format	PS	
Indicates Adobe Page Description Format	PDF	
Indicates ISO JPEG format	JPEG	
Indicates ISO MPEG format	MPEG	
Indicates ISO MPEG version 2 format	MPEG2	
Indicates Intel AVI format	AVI	
 Indicates Apple QuickTime format	QTIME	

3.2.4	Birthdate
This property is identified by the property name BDAY. The property value is a string conforming to the ISO 8601 calendar date, complete representation, in either basic or extended format. Support for this property is optional for vCard Writers conforming to this specification. The following example is in the basic format of ISO 8601:
BDAY:19950415
The following example is in the extended format of ISO 8601:
BDAY:1995-04-15
3.3	Delivery Addressing Properties
3.3.1	Address
This property is identified by the property name ADR. The property value consists of components of the address specified as positional fields separated by the Field Delimiter character (ASCII decimal 59). The property value is a concatenation of the Post Office Address (first field) Extended Address (second field), Street (third field), Locality (fourth field), Region (fifth field), Postal Code (six field), and Country (seventh field) strings. Support for this property is optional for vCard Writers conforming to this specification. An example of this property follows:
ADR;DOM;HOME:P.O. Box 101;Suite 101;123 Main Street;Any Town;CA;91921-1234;
3.3.1.1	Delivery Address Type
This property is specified as a property parameter to the Address property. Support for this property is optional for vCard Writers conforming to this specification. The property parameter can have one or more of the following values:

Description	Property Parameter Value	
TYPE=		
Indicates a domestic address	DOM	
Indicates an international address (Default)	INTL	
Indicates a postal delivery address  (Default)	POSTAL	
Indicates a parcel delivery address  (Default)	PARCEL	
Indicates a home delivery address	HOME	
Indicates a work delivery address  (Default)	WORK	

3.3.2	Address Delivery Label
This property is identified by the property name LABEL. This property specifies the formatted delivery address label for the vCard object. Support for this property is optional for vCard Writers conforming to this specification. A vCard Reader supporting this property and conforming to this specification should support four lines of text for this property. An example of a domestic delivery label follows:
LABEL;DOM;POSTAL;ENCODING=QUOTED-PRINTABLE:P. O. Box 456=0A=
123 Main Street=0A=
Any Town, CA 91921-1234
An example of an international delivery label follows:
LABEL;INTL;PARCEL,ENCODING=QUOTED-PRINTABLE:Suite 101=0A=
123 Main Street=0A=
Any Town, CA 91921-1234=0A=
U.S.A.
3.3.2.1	Delivery Label Type
This property is specified as a property parameter to the Delivery Label property. Support for this property is optional for vCard Writers conforming to this specification. The property parameter can have one or more of the following values:

Description	Property Parameter Value	
TYPE=		
Indicates a domestic address	DOM	
Indicates an international address  (Default)	INTL	
Indicates a postal delivery address  (Default)	POSTAL	
Indicates a parcel delivery address  (Default)	PARCEL	
Indicates a home delivery address	HOME	
Indicates a work delivery address  (Default)	WORK	

3.4	Telecommunications Addressing Properties
These property types are concerned with information associated with the telecommunications addressing of the vCard object.
3.4.1	Telephone Number
This property is identified by the property name TEL. Support for this property is optional for vCard Writers conforming to this specification. An example of this property follows:
TEL;PREF;WORK;MSG;FAX:+1-800-555-1234
3.4.1.1	Telephone Type
This property is specified as a property parameter of the Telephone property. Support for this property is optional for vCard Writers conforming to this specification. The property parameter can have one or more of the following values:

Description	Property Parameter Value	
TYPE=		
Indicates preferred number	PREF	
Indicates a work number	WORK	
Indicates a home number	HOME	
Indicates a voice number (Default)	VOICE	
Indicates a facsimile number	FAX	
Indicates a messaging service on the number	MSG	
Indicates a cellular number	CELL	
Indicates a pager number	PAGER	
Indicates a bulletin board service number	BBS	
Indicates a MODEM number	MODEM	
Indicates a car-phone number	CAR	
Indicates an ISDN number	ISDN	
Indicates a video-phone number	VIDEO	

3.4.2	Electronic Mail
This property is identified by the property name EMAIL. Support for this property is optional for vCard Writers conforming to this specification. An example of this property follows:
EMAIL;INTERNET:john.public@abc.com
3.4.2.1	Electronic Mail Type
This property is specified as a property parameter of the Electronic Mail property. Support for this property is optional for vCard Writers conforming to this specification. The following are some example values for this property:

Description	Property Parameter Value	
TYPE=		
Indicates America On-Line	AOL	
Indicates AppleLink	AppleLink	
Indicates AT&T Mail	ATTMail	
Indicates CompuServe Information Service	CIS	
Indicates eWorld	eWorld	
Indicates Internet SMTP	INTERNET	
Indicates IBM Mail	IBMMail	
Indicates MCI Mail	MCIMail	
Indicates PowerShare	POWERSHARE	
Indicates Prodigy information service	PRODIGY	
Indicates Telex number	TLX	
Indicates X.400 service	X400	

3.4.3	Mailer
This property is identified by the property name MAILER. Support for this property is optional for vCard Writers conforming to this specification. An example of this property follows:
MAILER:ccMail 2.2
3.4.4	Geographical Properties
These property types are concerned with information associated with location objects within the vCard object.
3.4.5	Time Zone
This property is identified by the property name TZ. This property is specified in a manner consistent with ISO 8601. The property value is a signed numeric indicating the number of hours and possibly minutes from UTC. Time zones east of UTC are positive numbers. Time zones west of UTC are negative numbers. Support for this property is optional for vCard Writers conforming to this specification. An example of the EST value for this property follows:
TZ:-05
3.4.6	Location
This property is identified by the property name GEO. Support for this property is optional for vCard Writers conforming to this specification. An example of this property follows:
GEO:37.24,-17.87
3.5	Organizational Properties
These property types are concerned with information associated with characteristics of the organizations or organizational unites associated with the vCard object.
3.5.1	Title
This property is identified by the property name TITLE. Support for this property is optional for vCard Writers conforming to this specification. An example of this property follows:
TITLE:V.P., Research and Development
3.5.2	Business Category
This property is identified by the property name ROLE. Support for this property is optional for vCard Writers conforming to this specification. An example of this property follows:
ROLE:Executive
3.5.3	Logo
This property is identified by the property name LOGO. Support for this property is optional for vCard Writers conforming to this specification. An example of a value for a GIF formatted image of a logo in Base 64 encoding for this property follows:
LOGO;ENCODE=BASE64;TYPE=GIF:
    R0lGODdhfgA4AOYAAAAAAK+vr62trVIxa6WlpZ+fnzEpCEpzlAha/0Kc74+PjyGM
    SuecKRhrtX9/fzExORBSjCEYCGtra2NjYyF7nDGE50JrhAg51qWtOTl7vee1MWu1
    50o5e3PO/3sxcwAx/4R7GBgQOcDAwFoAQt61hJyMGHuUSpRKIf8A/wAY54yMjHtz
...
3.5.3.1	Logo Format Type
This property is provided in the clear-text encoding to specify the graphics format for the Logo property value, if it is different than the default value for the vCard object. Support for this property is optional for vCard Writers conforming to this specification. This property is specified as a property parameter of the Logo property. The property parameter includes the following values:

Description	Property Parameter Value	
TYPE=		
Indicates Graphics Interchange Format	GIF	
Indicates ISO Computer Graphics Metafile	CGM	
Indicates MS Windows Metafile	WMF	
Indicates MS Windows Bitmap	BMP	
Indicates IBM PM Metafile	MET	
Indicates IBM PM Bitmap	PMB	
Indicates MS Windows DIB	DIB	
Indicates an Apple Picture format	PICT	
Indicates Tagged Image File Format	TIFF	
Indicates Adobe Page Description Format	PDF	
Indicates Adobe PostScript	PS	
Indicates ISO JPEG format	JPEG	
Indicates ISO MPEG format	MPEG	
Indicates ISO MPEG version 2 format	MPEG2	
Indicates Intel AVI format	AVI	
Indicates Apple QuickTime format	QTIME	

3.5.4	Agent
This property is identified by the property name AGENT. The value of this property is a string containing another vCard object. Support for this property is optional for vCard Writers conforming to this specification. An example of this property follows:
AGENT:
BEGIN:vCard
N:Friday;Fred
TEL;WORK,VOICE:+1-213-555-1234
TEL;WORK,FAX:+1-213-555-5678
END:vCard
3.5.5	Organization
This property is identified by the property name ORG. This property is defined within the clear-text encoding to encapsulate the Organization Name and Organization Unit properties as sub-properties. Support for this property is optional for vCard Writers conforming to this specification. The property value consists of the components of the organization specified as positional fields separated by the Field Delimiter (ASCII decimal 59). The property value is a concatenation of the Organization Name (first field), Organizational Unit (second field) strings. Additional positional fields, if specified, contain additional Organizational Units. The following is an example of the Organization property:
ORG:ABC, Inc.;North American Division;Marketing
3.6	Explanatory Properties
These property types are concerned with additional explanations, such as that related to national language support, annotation, or encoding of binary information about the vCard object.
3.6.1	Comment
This property is identified by the property name NOTE. Support for this property is optional for vCard Writers conforming to this specification. An example of this property follows:
NOTE;ENCODING=QUOTED-PRINTABLE:This facsimile machine if operational=
 0830 to 1715 hours=0A=
Monday through Friday. Call +1-213-555-1234 if you have problems=0A=
with access to the machine.
3.6.2	Last Revision
This property is identified by the property name REV. Support for this property is optional for vCard Writers conforming to this specification. Valid values for this property are a character string representing a combination of the calendar date and time of day conforming to the basic or extended format of ISO 8601. The time of day can be either local time or UTC. The following example is in the basic format and local time of ISO 8601:
REV:19951031T222710
The following example is in the extended format and UTC time of ISO 8601:
REV:1995-10-31T22:27:10Z
3.6.3	Sound
This property is identified by the property name SOUND. Support for this property is optional for vCard Writers conforming to this specification. Valid values for this property are either a string representation, a reference to a digital audio representation, or an inline digital audio representation of the phonetic pronunciation of the Formatted Name property. The following example shows the string based phonetic representation:
SOUND:JON Q PUBLIK
The following example shows the digtial sound representation and URL based value:
SOUND;WAV:file//multimed/audio/jqpublic.wav
The following example shows the digtial sound representation and INLINE value:
SOUND;WAV,BASE64:	
    UklGRhAsAABXQVZFZm10IBAAAAABAAEAESsAABErAAABAAgAZGF0YesrAACAg4eC
    eXR4e3uAhoiIiYmKjIiDfnx5eX6CgoKEhYWDenV5fH6BhISGiIiDfHZ2eXt/hIiK
    jY2IhH12d3Vyc3uDiIiFf3l7fn18eXl+houFf319fnyAgHl5eoCIiISChIeAfnt2
...

3.6.3.1	Sound Digital Audio Type
This property is provided in the clear-text encoding to specify the type of the digital audio Pronunciation for the vCard object. Support for this property is optional for vCard Writers conforming to this specification. This property is specified as a property parameter of the Sound property. The property parameter can have the following values:

Description	Property Parameter Value	
TYPE=		
Indicates Wave format	WAVE	
Indicates MIME basic audio type	PCM	
Indicates AIFF format	AIFF	

3.6.4	Uniform Resource Locator
This property is identified by the property name URL. Valid values for this property are a string conforming to the IETF RFC 1738, Uniform Resource Locators. Support for this property is optional for vCard Writers conforming to this specification. The following is an example of this property:
URL=http://abc.com/pub/directory/northam/jpublic.ecd
3.6.5	Unique Identifier
This property is identified by the property name UID. The clear-text encoding provides this property to enable a vCard Reader and Writer to uniquely identify either a vCard object instance or properties within a vCard object. Valid values for this property are a unique character string. Support for this property is optional for vCard Writers conforming to this specification. The following is an example of this property:
UID:19950401-080045-40000F192713-0052
3.7	Security Properties
These property types are concerned with the security of the information in the vCard object.
3.7.1	Public Key
This property is identified by the property name KEY. Valid values for this property are a public key that conforms to a bilaterally agreed to representation. If the representation is a binary format, then the public key must be further encoded into one of the supported packed binary formats. The default format is clear-text. If a packed binary format is used, then it is specified by the property parameter. Support for this property is optional for vCard Writers conforming to this specification.
3.7.2	Key Type
This property is provided in the clear-text encoding to specify the type of the public key for the vCard object. Support for this property is optional for vCard Writers conforming to this specification. This property is specified as a property parameter of the Sound property. The property parameter can have the following values:

Description	Property Parameter Value	
TYPE=		
Indicates a X.509 public key certificate type of key	X509	
Indicates an IETF PGP type of key	PGP	
3.8	Miscellaneous Properties
3.8.1	Extensions
The clear-text encoding provides a “standard mechanism for doing non-standard things”. This extension support is provided for implementors to “push the envelope” on the existing version of the specification. Extension properties are specified by property and/or property parameter names that have the initial sub-string of X- (the two character sequence: Capital X character followed by the Dash character. It is recommended that vendors concatenate onto this sentinel an added short sub-string to identify the vendor. This will facilitate readability of the extensions and minimize possible collision of names between different vendors. All vCard Readers are expected to be able to interpret the extension properties and property parameters but may ignore them. For example, the following might be the ABC vendor’s extension for a video-clip form of identification property:
X-ABC-VIDEO;MPEG2:http://lonestar.bubbas.org/billibob.mpg
or, the following example might be an extension for grouping vCard objects into a distribution list for the Design Work Group. 
BEGIN:vCard
X-DL;Design Work Group:List Item 1, List Item 2, List Item 3
BEGIN:vCard
UID:List Item 1
N:John Smith
TEL:+1-213-555-1111
END:vCard
BEGIN:vcard
UID:List Item 2
N:I. M. Big
TEL:+1-213-555-9999
END:vCard
BEGIN:vCard
UID:List Item 3
N:Jane Doe
TEL:+1-213-555-5555
END:vCard
END:vCard
At present, there is no registration authority for names of extension properties.
3.9	Formal Definition
The following modified Backus-Naur Notation (BNF) is provided to assist developers in building parsers for the clear-text encoding.
This syntax is written according to the form described in RFC 822, but it references just this small subset of RFC 822 literals:
  CR			=  <ASCII CR, carriage return>  ; (     15,      13.)
  LF			=  <ASCII LF, linefeed>         ; (     12,      10.)
  CRLF		=  CR LF
  SPACE		=  <ASCII SP, space>            ; (     40,      32.)
  HTAB		=  <ASCII HT, horizontal-tab>   ; (     11,       9.)
All literal property names are valid as upper, lower, or mixed case.
vcard_file	= [wsls] vcard [wsls]
vcard		= "BEGIN:VCARD" [ws 7bit] 1*CRLF items *CRLF "END:VCARD"
	; the optional 7bit indicates the version
ws		= 1*(SPACE / HTAB)
	; "whitespace," one or more spaces or tabs
wsls		= 1*(SPACE / HTAB / CRLF)
	; whitespace with line separators
items		= items *CRLF item
		/ item
item		= [ws] [groups "."] name
		  [params] ":" value CRLF
		/ [ws] [groups "."] "ADR"
		  [params] ":" addressparts CRLF
		/ [ws] [groups "."] "ORG"
		  [params] ":" orgparts CRLF
		/ [ws] [groups "."] "N"
		  [params] ":" nameparts CRLF
		/ [ws] [groups "."] "AGENT"
		  [params] ":" vcard CRLF
value		= 7bit / quoted-printable / base64
7bit		= <7bit us-ascii printable chars, excluding CR LF>
quoted-printable = <MIME RFC 1521 quoted-printable text>
base64		= <MIME RFC 1521 base64 text>
	; the end of the text is marked with two CRLF sequences
	; this results in one blank line before the start of the next property
groups		= groups "." word
		/ word
word		= <any printable 7bit us-ascii except []=:., >
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" / "X-" word
pencodingval 	= "7BIT" / "QUOTED-PRINTABLE" / "BASE64" / "X-" word
charsetval	= <a character set string as defined in Section 7.1 of 
		RFC 1521>
langval		= <a language string as defined in RFC 1766>
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		= <any non-control ASCII except ";">
name		= "LOGO" / "PHOTO" / "LABEL" / "FN" / "TITLE"
		/ "SOUND" / "LANG" / "TEL" / "EMAIL" / "TZ" / "GEO" / "NOTE"
		/ "URL" / "BDAY" / "ROLE" / "REV" / "UID" / "KEY"
		/ "MAILER" / "X-" word 
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 4 : Bentogram
This section defines the syntax for encoding the vCard in a robust, binary encoding. The binary format is based on the use of the Apple Computer software container format, called Bento. There exists software in the form of an application programming interface (API) for creating and parsing a Bento container. It is available from the Component Integration Labs (CI Labs).
Some aspects of this encoding are presented with examples in the C programming language. The use of the C language is for illustrative purposes only and is not intended to limit the use of this encoding. All example C language identifiers are prefixed by VC, for vCard. Identifiers from the Bento API are prefixed with CM, for container manager.
4.1	Encoding Characteristics
The following characteristics are specific to this encoding
4.1.1	Character Set
Within a Bentogram, all PDI string data uses Unicode 16-bit character encoding as described in The Unicode Standard by The Unicode Consortium.  Unicode was selected because it provides for broad internationalization in a single character set.
Implementations should be prepared to receive and parse strings stored in the Bentogram VCStrIdxType of up to 2*16-1 Unicodes in length.
All Unicode string data required by objects in a Bentogram is aggregated into one logical block. This logical block is physically stored as two separate blocks; one contains the most significant bytes of the Unicode data, the other contains the least significant bytes. The purpose of this representation is to make the most significant bytes into contiguous storage. Since these bytes will often be the value zero (and are expected to change slowly), conventional compression algorithms can be highly effective. Neither block of storage is compressed. It is assumed that the transport layer will transparently compress and decompress the entire Bentogram if required. This arrangement of the string data is intended to ensure that such compression is as effective as possible.
The blocks are stored in two properties of the VCStringDataObject object:  VCStringDataLSBProp and VCStringDataMSBProp. The property VCStringDataLSBProp contains the least significant bytes of the Unicode; the property VCStringDataMSBProp contains the most significant bytes.
Strings are referenced by VCStrIdxType, which is a simple offset+length structure. For this reason, strings need not be terminated by U+0000. Strings can, however, contain the Unicode characters for paragraph separator, U+2029, or line separator, U+2028. 
Since all string references within a single Bentogram share the same VCStringDataProp, a storage space optimization is possible. Multiple instances of a VCStrIdxType can reference the same string data. For example, the string JOHN H. DOE may be referenced by the property VCFullNameProp; the substring JOHN by the VCGivenNameProp and SMITH by the VCFamilyNameProp. 
Applications should check to see if a string is already present in the VCStringDataObject before adding a new copy. While this means that removing a particular reference becomes more problematic (because of the need to garbage collect the table), in practice, this should not present much of a problem. This practice will optimize the reuse of strings. For example, a bilingual business card with two VCBodyObjec(s) for different languages would share strings such as telephone numbers and company names that are not usually translated. A package of vCards representing several employees of the same company would probably share many strings in common.
In some instances the property VCStringDataLSBProp or VCStringDataMSBProp may contain nothing but zeros. If this is the case, it can be omitted entirely. Receivers should be prepared for Bentograms which are missing either property (or both) and should construct whole Unicodes using zero as the value of the missing data.
4.1.2	Objects
Before going into detail of vCard container elements, it is appropriate to first discuss how Bentogram object and property structures are used by vCards. 
VCards are composed of three kinds of objects: VCRootObject, VCBodyObject, and VCPartObject. These objects hold properties which can hold one or more values of differing types.
Each vCard in a Bentogram begins with a VCRootObject. The Bento API provides functions which allow a Bentogram to be searched for an object which contains a specific property. A vCard root object is ÒmarkedÓ by the fact that it contains the VCRootObject. A simple or ÒflatÓ vCard may consist of only a VCRootObject with a collection of properties.
4.1.3	Grouping
A VCBodyObject is an object which forms a first level grouping of vCard data. The primary purpose of VCBodyObjects is to support a vCard with more than one language, such as an English and French version.
The logical organization is realized by references (pointers). For example, the value of the VCBodyProp attached to VCRootObject can be a reference (CMReference) to the first VCBodyObject (French) which has a property VCNextObjectProp with a reference for the second VCBodyObject (English).
The facility provided by VCBodyObject is similar to that which might be provided by storing multiple VCRootObjects in a single Bento container. However, if more than one VCRootObject is in a single Bentogram, they are assumed to refer to different people. There may be a relationship between the two people that have their vCards in the same container, but this specification does not define that relationship. Because such a relationship may logically exist at the application level, transports should preserve the fact that a set of vCards arrived together in one Bentogram and communicate this relation to the application layer.
In contrast, two VCBodyObjects referenced by the same VCRootObject do have a defined relationship. They can share common properties, and they are assumed to represent multiple sets of data which apply to the same person, in French and English, for example.
VCPartObjects are used to group a collection of related properties, and to structure repeating collections of properties into lists. Related properties are bound to a VCPartObject, which can then be referenced using a value of CMReference. 
4.1.4	Bit-Level Data Representation
Within a byte, the bit ordering is from least significant to most significant; i.e., when the bits of a byte are emitted serially, the least significant bit is transmitted first.
Within a double-byte, or word, the ordering is least significant byte at the lowest storage address and the most significant byte at the highest storage address. Within a double-word, the ordering is least significant word at the lowest storage address and the most significant word at the highest storage address. This byte ordering convention is called Òlittle endianÓ or ÒIntelÓ order.
Floating point numbers use the IEEE 754 standard representation.
Within aggregate structures, such as arrays or structures declared with the C LanguageÒstructÓ keyword, the first entity in the declaration occupies the lowest storage address; successive data occupies successive contiguous storage addresses. This ordering is commonly known as Òpacked alignment.Ó
When multi-byte or aggregate data is emitted serially, the byte stored at the lowest storage address is transmitted first.
4.2	Properties
The vCard properties are bound to one of the three object types defined by this encoding, the VCRootObject, VCBodyObject, and VCPartObject. The relationship of each Bentogram property to the common vCard semantics is defined in the description of each property.
4.2.1	VCRootObject Properties
The properties bound to the VCRootObject define characteristics that apply to the vCard as a whole. These properties include the some of the vCard Organizational, Explanatory and Security properties.
4.2.1.1	VCBodyProp
This property is specific to this encoding.
VCBodyProp contains a value of type CMReference, which groups two or more VCBodyObject objects. A list of VCBodyObject(s) is defined when a vCard contains alternative forms of data, such as different data for multiple translations. Most vCard viewers, however, will only display one VCBodyObject at a time.
Support for this property is optional for implementations conforming to this encoding.
4.2.1.2	VCUniqueStringProp
This property provides support for the vCard Unique Identifier explanatory property. 
VCUniqueStringProp contains a value of type VCStrIdxType. The string should contain a globally unique identifier (GUID) which defines a vCard to unique-person association. The purpose of each vCard having a GUID is to distinguish between updates/replacements and additions when adding new vCards into a database. If every vCard has a GUID, vCard updates can be partially automated.
Support for this property is optional for implementations conforming to this encoding.
The GUID can be sourced from any protocol capable of representing GUIDs in string form. ISO 9070 Formal Public Identifiers and X.500 Òdistinguished namesÓ are two examples of protocols which are capable of generating globally unique identifiers. 
If vCard data is extracted from a source where a sufficiently unique identifier has already been assigned, then VCUniqueStringProp would normally take on the existing value. This allows the vCard to relate back to the original source of data. 
A GUID should be generated only once when a vCard is created. Any change to a vCard which should logically propagate to all outstanding instances of that vCard should preserve the existing GUID (even changes to those data items used to construct the GUID). Only if the user explicitly wants to change identity, or be known by two or more separate identities, should a new GUID be generated. 
In general only the originator of the string should create/edit the string, and only the originator knows for sure what the GUID system is, if any, that the string follows. Receivers should be prepared to compare strings up to 2*16-1 Unicodes in length.
There exists the possibility that identical GUIDs could be independently generated. Therefore, it is recommended that application software allow for human intervention or appropriate backup when a GUID match implies the destructive overwrite of vCard data. 
4.2.1.3	VCLastRevisedProp
This property provides support for the vCard Last Revision explanatory property. 
VCLastRevisedProp contains a value of type VCStrIdxType that contains the date and time that the vCard was created or updated by its author. By evaluating the values in VCLastRevisedProp and VCUniqueStringProp, the vCard recipient can determine whether the received vCard should update an existing vCard.
Support for this property is optional for implementations conforming to this encoding.
VCLastRevisedProp string can be an ISO 8601 date and time string in basic format that is formatted as follows:
CCYYMMDDThhmmssZ
for UTC time and:
CCYYMMDDThhmmss
for local time. CC is the century, YY is the year, MM is the month, DD is the day of the month, T is a separator, hh is the hour, mm is the minute within the hour, ss is the seconds within the minute and the terminating Z means the value is Coordinated Universal Time (UTC).
Month values are from 01 through 12, and day values are from 01 through 31.
The time is a 24-hour clock. Hour values are from 00 through 24, and minute and second values are from 00 through 59. Month, day, hour, minute and second values are 2-digits with 
high-order zeros required to maintain digit count.
4.2.1.4	VCMyReferenceProp and VCYourReferenceProp
This property is specific to this encoding.
Both of these properties contain a value of type VCReferenceType, which is an unsigned 32-bit number. VCMyReferenceProp is used to maintain a linkage between a vCard and the identity of the person to which it is transmitted. VCYourReferenceProp is used to transmit a received VCMyReferenceProp back to the sender.
Support for this property is optional for implementations conforming to this encoding.
For example, if Bob is about to give Sue his vCard, he can first create an identity record for Sue and place a value in VCMyReferenceProp which will tie the vCard back to that record.
Should Sue call Bob, her telephone might transmit BobÕs VCMyReferenceProp to BobÕs voicemail system. In turn, BobÕs voicemail system could then use the VCMyReferenceProp to reestablish the linkage back to the identity record for Sue; the system would then have a machine readable representation of information about the caller.
If Sue wants to send her vCard to Bob, she might first create an identity record for Bob and place a value in VCMyReferenceProp referencing it. She would then place the value VCMyReferenceProp from BobÕs vCard into VCYourReferenceProp and transmit the vCard to Bob. BobÕs copy of SueÕs vCard now contains BobÕs reference for Sue, and SueÕs reference for Bob.
These references do not need to be tied to identity records for individuals; they can reference any information that users find useful. For example, vCards which were distributed at a meeting could use the VCMyReferenceProp to tie them back to a memo or calendar entry related to the meeting.
4.2.1.5	VCMsgProp
This property is specific to this encoding. 
VCMsgProp contains a value of type VCStrIdxType that is used to add an arbitrary string to a vCard prior to transmission. It is usually a one-time message for the current transmission, in addition to the vCard being transmitted. 
Support for this property is optional for implementations conforming to this encoding.
For example, suppose Jack asks Jane to recommend an insurance agency. Jane later looks up the vCard of her agent and sends it to Jack with the message ÒThese are the people we talked about.Ó 
4.2.1.6	VCLogoProp
This property provides support for the vCard Logo organizational property. 
The VCLogoProp is used to represent a company logo or other art to represent the vCard owner. Because of the diversity of graphic interchange standards VCLogoProp can contain a value of any type, or it can hold multiple values of different types, as necessary to support graphic interchange of logo data. 
Support for this property is optional for implementations conforming to this encoding.
This specification defines VCLogoType as the identifier for logo graphics in the form of TIFF data. For maximum interoperability the following guidelines are recommended:
¥	Logos should be 32 x 32 x 8 gray-valued samples in TIFF uncompressed format. The overhead for such an image is approximately 1340 bytes. If extra detail is necessary, increase the number of samples as required. (For instance, 64 x 64 samples will increase the size to approximately 4400 bytes.)
¥	The LZW compression option may be used, but it places a burden on the receiver. If a general purpose compression will be applied across the communications link, that should be used instead.
¥	If a logo contains color, the RGB model is recommended .
The intention of these guidelines is to promote a subset of TIFF for describing vCard logos, such that the overhead of a fully conforming TIFF reader is not required. Application developers may use other features of TIFF, such as color separations, color corrections, etc. However, usage of such features is discouraged because they will impede, rather than promote, the exchange of vCards.
While VCLogoType is TIFF, developers are free to introduce other graphic formats and either assign new private identifiers for them for use by cooperating applications, or use other formal public identifiers which have been assigned by CI Labs. For maximum interoperability, a value of type VCLogoType should be present, even if other types are also supported.
VCLogoProp should be a property of the VCRootObject object so it can be shared among all VCBodyObject presentations. If the logo needs to change for each VCBodyObject, then use multiple VCLogoProp properties for separate VCBodyObject(s) instead.
4.2.1.7	VCPartProp
This property is specific to this encoding.
VCPartProp contains a value of type CMReference that references an object of type VCPartObject. The VCPartObject objectÕs purpose is to structure the collections of related properties that are bound to a given VCPartObject.
Support for this property is optional for implementations conforming to this encoding.
4.2.1.8	VCEncryptionProp
This property provides support for the vCard Public Key security property. 
VCEncryptionProp is used to store a public key that correspondents use to encrypt or decrypt communications. At this time, there is no encryption standard in common use for PDI applications. Lack of a simple and secure key distribution mechanism is one reason for this. The distribution of keys via vCards during reasonably secure interpersonal communication sessions (such as face-to-face communication via IR or point-to-point telephone calls) is a mechanism in which users could have confidence. 
Support for this property is optional for implementations conforming to this encoding.
Because there is no encryption standard in common use for PDI applications, this specification does not standardize the representation of this property at this time. The type of this property must be established by bilateral agreement.
4.2.2	VCBodyObject Properties
The majority of the vCard properties are bound to the VCBodyObject. These properties include the Identification, Delivery Addressing, Telecommunications Addressing, Geographical, Organizational, and Explanatory properties.
4.2.2.1	VCNextObjectProp
This property is specific to this encoding.
VCNextObjectProp contains a value of type CMReference, which references objects of type VCBodyObject or VCPartObject.
Support for this property is optional for implementations conforming to this encoding.
In Bento, an object can only contain one property of a given type, so when there are several instances of the property, each instance is modeled as an object. The objects are organized into a list singly-linked by the VCNextObjectProp
4.2.2.2	VCDeliveryLabelProp
This property provides support for the vCard Delivery Label delivery addressing property. 
VCDeliveryLabelProp contains a value of type VCStrIdxType, which is the vCard ownerÕs formatted name, company name, and delivery address for mail. Line breaks should be marked with the Unicode line separator character U+2028. For international labels, the last line in the VCDeliveryLabelProp string should contain the country name only.
Support for this property is optional for implementations conforming to this encoding.
The storage size of this property is 256 characters. The formatting of this property is not to exceed 5 lines for domestic labels and 6 lines for international labels. The nominal size of each line is 30 characters.
4.2.2.3	VCCountryNameProp
This property provides support for the vCard Country Name delivery addressing property. 
VCCountryNameProp could contain a value of type VCStrIdxType that references the last line of VCDeliveryLabelProp; or, VCCountryNameProp could contain a value of type VCISO3166Typen that contains a 2-octet value holding an ISO 3166 country code.
Support for this property is optional for implementations conforming to this encoding.
The storage size of this property is 64 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 30 characters.
If a value of type VCISO3166Type is present, it should be emitted as a 2-character string surrounded by square brackets and concatenated to the end of the VCStrIdxType value (if present). For example: 
Turks and Caicos Islands [TC]
A space character can be used before the Ò[Ó character to separate the text string from the ISO 3166 value when both are present.
4.2.2.4	VCPostalCodeProp
This property provides support for the vCard Postal Code delivery addressing property. 
VCPostalCodeProp contains a value of type VCStrIdxType that references a substring of VCDeliveryLabelProp and/or VCPostalLabelDomProp. In the United States, the term postal code is otherwise known as a zipcode. 
Support for this property is optional for implementations conforming to this encoding.
The storage size of this property is 40 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 20 characters.
4.2.2.5	VCRegionProp
This property provides support for the vCard Region delivery addressing property. 
VCRegionProp contains a value of type VCStrIdxType that references a substring of VCDeliveryLabelProp and/or VCPostalLabelDomProp. In the United States, the term region is otherwise known as a state or province.
Support for this property is optional for implementations conforming to this encoding.
The storage size of this property is 128 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 32 characters.
4.2.2.6	VCCityProp
This property provides support for the vCard City delivery addressing property. 
VCCityProp contains a value of type VCStrIdxType that references a substring of VCDeliveryLabelProp and/or VCPostalLabelDomProp. The term city is meant to be inclusive of other terms for a locality such as a town, suburb, or village. 
The storage size of this property is 128 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 32 characters.
4.2.2.7	VCFormattedNameProp
This property provides support for the vCard Formatted Name identification property. 
VCFullNameProp contains a value of type VCStrIdxType that references a substring of VCDeliveryLabelProp and/or VCPostalLabelDomProp. This string should hold the vCard ownerÕs formatted name, including any honorific prefixes, such as Dr., Mr., Ms., etc., and suffixes, such as Ph.D., J.D., etc. with which the vCard owner wishes to embellish his or her name. 
Support for this property is optional for implementations conforming to this encoding.
When multiple VCBodyObject(s) support different language translations, the location of this property can be significant. If VCFullNameProp is the same for all translations, it can be bound to the VCRootObject object and appear only once in the vCard. If VCFullNameProp is translated, it should be bound to separate instances of VCBodyObject and each property will refer to a different string.
The storage size of this property is 128 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 64 characters.
4.2.2.8	VCTitleProp
This property provides support for the vCard Title organizational property. 
VCTitleProp contains a value of type VCStrIdxType that references a substring of VCDeliveryLabelProp and/or VCPostalLabelDomProp. It is the job title or organizational role of the vCard owner.
Support for this property is optional for implementations conforming to this encoding.
When multiple VCBodyObject(s) support different language translations, the location of this property can be significant. If VCTitleProp is the same for all translations, it can be bound to the VCRootObject object and appear only once in the vCard. If VCTitleProp is translated, it should be bound to separate instances of VCBodyObject and each property will refer to a different string.
The storage size of this property is 128 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 64 characters.
4.2.2.9	VCOrgUnitProp
This property provides support for the vCard Organizational Unit organizational property. 
VCOrgUnitProp contains a value of type VCStrIdxType that references a substring of VCDeliveryLabelProp and/or VCPostalLabelDomProp. It is the organizational unit where the vCard owner holds the position described by VCTitleProp.
Support for this property is optional for implementations conforming to this encoding.
When multiple VCBodyObject(s) support different language translations, the location of this property can be significant. If VCOrgUnitProp is the same for all translations, it can be bound to the VCRootObject object and appear only once in the vCard. If VCOrgUnitProp is translated, it should be bound to separate instances of VCBodyObject and each property will refer to a different string.
The storage size of this property is 128 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 64 characters.
4.2.2.10	VCOrgNameProp
This property provides support for the vCard Organization Name organizational property. 
VCOrgNameProp contains a value of type VCStrIdxType that references a substring of VCDeliveryLabelProp and/or VCPostalLabelDomProp. It is the organizational (or company) name for which the person works.
Support for this property is optional for implementations conforming to this encoding.
When multiple VCBodyObject(s) support different language translations, the location of this property can be significant. If VCOrgNameProp is the same for all translations, it can be bound to the VCRootObject object and appear only once in the vCard. If VCOrgNameProp is translated, it should be bound to separate instances of VCBodyObject and each property will refer to a different string.
The storage size of this property is 128 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 64 characters.
4.2.2.11	VCFamilyNameProp
This property provides support for the vCard Family Name identification property. 
VCFamilyNameProp contains a value of type VCStrIdxType that references a substring of VCFullNameProp. It is the vCard ownerÕs surname (last name).
Support for this property is mandatory for implementations conforming to this encoding.
The storage size of this property is 128 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 64 characters.
4.2.2.12	VCGivenNameProp
This property provides support for the vCard Given Name identification property. 
VCGivenNameProp contains a value of type VCStrIdxType that references a substring of VCFullNameProp. It is the vCard ownerÕs first name.
Support for this property is mandatory for implementations conforming to this encoding.
The storage size of this property is 64 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 32 characters.
4.2.2.13	VCSoundProp
This property provides support for the vCard Sound explanatory property. 
By default, the VCSoundProp property is a pronunciation of VCFormattedlNameProp that may have multiple values. The value for type VCStrIdxType is a string with a phonetic spelling. The value for type VCSoundType is a single array (mono) of bytes in IMA 4-bit ADPCM, 8 kHz sample rate.
Support for this property is optional for implementations conforming to this encoding.
The storage size of this property with a value of type VCStrIdxType is 128 characters. The storage size of this property with a value of type VCSoundType is 2048 octets. The formatting of this property is not to exceed 1 line. The nominal size of this property is 64 characters.
4.2.2.14	VCLanguageProp
This property provides support for the vCard Language explanatory property. 
VCLanguageProp contains a value of type VCStrIdxType that contains a string conforming to the tag values defined in RFC 1766.
Support for this property is optional for implementations conforming to this encoding.
4.2.2.15	VCTelephoneProp
This property provides support for the vCard Telephone telecommunications addressing property. 
VCTelephoneProp contains a value of type VCStrIdxType that represents a telephone number in canonical form. The purpose of the canonical form is to provide a representation which unambiguously represents a globally unique endpoint. 
Support for this property is optional for implementations conforming to this encoding.
Most telephone numbers will be bound to a VCPartObject so they may be grouped with a VCCaptionProp (and possibly a VCCommentProp).
The storage size of this property is 40 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 20 characters. 
4.2.2.16	VCEmailAddressProp
This property provides support for the vCard Electronic Mail telecommunications addressing property. 
VCEmailAddressProp contains a value of type VCStrIdxType that represents an electronic mail address in canonical written form as follows:
email_address ::= [label_string:value_string]
label_string ::= [standard_label | printable_string]
standard_label ::= [string]
printable_string ::= [U+0020..U+007E | U+00A0..U+00FF...]
value_string ::= [  ]
label_string identifies an e-mail standard, the colon is a separator, and value_string is the e-mail address in a string form defined by the standard
Support for this property is optional for implementations conforming to this encoding.
VCEmailAddressProp should not exceed 64 Unicode characters.
4.2.2.17	VCMailerProp
This property provides support for the vCard Mailer telecommunications addressing property. 
VCMailerProp contains a value of type VCStrIdxType that represents one or more strings that could appear in the header field of a SMTP message. This information helps to inform correspondents about what type of e-mail software is in use, so an application can determine what type of data representation can be used, transferred, and how it should be packaged.
Support for this property is optional for implementations conforming to this encoding.
The storage size of this property is 1024 characters. The formatting of this property is an unknown number of lines separated by the Unicode line separator character U+2028. The nominal size of this property is 80 characters by 1 line. 
4.2.2.18	VCURLProp
This property provides support for the vCard URL explanatory property. 
VCURLProp contains a value of type VCStrIdxType that represents a Uniform Resource Locator (URL
Support for this property is optional for implementations conforming to this encoding.
The storage size of this property is 128 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 64 characters. 
4.2.2.19	VCAgentProp
This property provides support for the vCard Agent organizational property. 
VCAgentProp contains a value of type CMReference that references either a VCPartObject, VCBodyObject, or other data types as defined by a bilateral agreement. 
Support for this property is optional for implementations conforming to this encoding.
When the VCAgentProp references a VCBodyObject, the application should display the VCBodyObject (agentÕs vCard). If the agent is an addressable software entity, then its definition is outside the scope of this specification and will be determined by bilateral agreements. 
4.2.2.20	VCTimeZoneProp
This property provides support for the vCard Time Zone geographical property. 
VCTimeZoneProp contains a value of type VCStrIdxType that encodes the time zone of a (possibly implied) location.
Support for this property is optional for implementations conforming to this encoding.
VCTimeZoneProp string is an ISO 8601 UTC offset string in basic format. VCTimeZoneProp should not exceed 5 characters, based on ISO 8601.
4.2.2.21	VCLocationProp
This property provides support for the vCard Location geographical property. 
VCLocationProp contains a value of type VCLocationType, which is two floating point numbers containing the latitude and longitude of a physical location. 
Support for this property is optional for implementations conforming to this encoding.
Declaration of VCLocationType must evaluate to a 32-bit IEEE 754 floating point number. The structure is represented as follows:
typedef float  VC_FLOAT;

typedef struct {
  VC_FLOAT       latitude,
                  longitude;
} VC_LOCATION, * VC_PTR_LOCATION;
latitude represents locations north and south of the equator as positive and negative numbers, respectively. longitude represents locations east and west of the prime meridian as positive and negative numbers, respectively. 
4.2.2.22	VCCaptionProp
This property is specific to this encoding. The property provides the capability of specifying qualifiers for individual properties.
Support for this property is optional for implementations conforming to this encoding.
VCCaptionProp contains a value of type VCFlagsType, VCStrIdxType, or CMReference. Most often, however, VCCaptionProp is a VCFlagsType, which is an enumeration of attributes as follows: 
#define	VC_VOICE_CALL	((VC_FLAGS)0x00000001)
#define	VC_VOICE_MESSAGE	((VC_FLAGS)0x00000002)
#define	VC_VIDEO_CALL	((VC_FLAGS)0x00000004)
#define	VC_VIDEO_MESSAGE	((VC_FLAGS)0x00000008)
#define	VC_EMAIL	((VC_FLAGS)0x00000010)
#define	VC_BBS	((VC_FLAGS)0x00000020)
#define	VC_FAX	((VC_FLAGS)0x00000040)
#define	VC_CELLULAR	((VC_FLAGS)0x00000080)
#define	VC_PAGER	((VC_FLAGS)0x00000100)
#define	VC_HOME	((VC_FLAGS)0x00000200)
#define	VC_WORK	((VC_FLAGS)0x00000400)
#define	VC_MOBILE	((VC_FLAGS)0x00000800)
#define	VC_PARCEL	((VC_FLAGS)0x00001000)
#define	VC_POSTAL	((VC_FLAGS)0x00002000)
#define	VC_PREFERRED	((VC_FLAGS)0x00004000) 
#define	VC_DOMESTIC	((VC_FLAGS)0x00008000) 
#define	VC_INTERNATIONAL	((VC_FLAGS)0x00010000)
The type VC_FLAGS is an unsigned 32-bits.
Display software applications should synthesize a caption string by analyzing these flags and the type of the value to which they are bound. To allow the vCard creator to override this display behavior, VCCaptionProp could also have a value of type VCStrIdxType. Still, the VCFlagsType value should also be provided so that the software can perform machine analysis of the vCard. For example, the caption ÒFax at vacation homeÓ in VCStrIdxType format should be accompanied by a VC_FAX flag so that fax sending software can find and present the option to the user. Captions like ÒFax at homeÓ and ÒFax at officeÓ can be synthesized from the VCFlagsType values alone. 
When a VCCaptionProp is a VCStrIdxType value, the following guidelines apply: 
The storage size of this property is 128 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 32 characters. 
4.2.3		VCPartObject
The purpose of VCPartObject properties is to add grouping structure to properties and to allow the groups to be organized hierarchically. vCards can be represented as a flat, sequential set of properties or as a hierarchical set of properties.
Properties which are bound to the VCPartObject follow. Detailed definition of each property can be found on the pages referenced in Table 1.
4.2.3.1	VCCommentProp
This property provides support for the vCard Comment explanatory property. 
VCCommentProp contains a value of type VCStrIdxType that is used to add an ad hoc comment to an object, such as a telephone number or postal address, but different than that of a VCCaptionProp. A VCCaptionProp can be machine readable and it describes what a data item is. The VCCommentProp contains only informal information that a vCard owner would like to communicate to a receiver. 
Support for this property is optional for implementations conforming to this encoding.
The storage size of this property is 128 characters. The formatting of this property is not to exceed 1 line. The nominal size of this property is 32 characters. 

Section 5 : Internet Recommendations
5.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.
5.1.1	Text/Plain Content Type
Without any change to existing SMTP or MIME compliant user agents, a Simplegram 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 Simplegram 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: <JOHNSMITH.960125T091020.xyzMail@host3.com>

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
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 Simplegram vCard can be included as a separate text/plain content portion within current MIME user agents.
Date: Fri, 26 Jan 1996 07:53:00 +0000
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: <ABC-1.00-Note-martin-steve-0824475754>

--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
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--
5.1.2	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 and is aligned with the vCard Simplegram encoding format. 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 is working with the authors of this draft to produce an application/directory profile that registers the method for transporting a vCard as an application/directory Content-Type. This work is expected to be completed after the publication of this version of the vCard specification. In the interim, the following guidelines are provided to describe how a vCard Simplegram might be conveyed using the application/directory draft specification.
A Simplegram should be included in a MIME message that has a Content-Type header field value of “multipart/related”. The Simplegram 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. Alternatively, the binary information can be extracted from the vCard object and contained in the MIME message as secondary body part entities. 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: <JOHNSMITH.960129T083020.xyzMail@host3.com>
Content-Type: multipart/related; boundary=“vcard”; 
			type=application/directory;
			start=<JOHNSMITH.part1.960129T083020.xyzMail@host3.com>
--vcard
Content-Type: application/directory; charset=us-ascii;
			source=“file://versit.or2”; profile=“vcard”
Content-ID: <<JOHNSMITH.part1.960129T083020.xyzMail@host3.com>
BEGIN:vCard
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:<<JOHNSMITH.part3.960129T083020.xyzMail@host3.com>
ADR;WORK;PARCEL;POSTAL;DOM:Suite 101;1 Central St.;Any Town;NC;27654
END:vCard
--vcard
Content-Type: text/plan; charset=us-ascii
Content-ID: <<JOHNSMITH.part2.960129T083020.xyzMail@host3.com>
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: <<JOHNSMITH.part3.960129T083020.xyzMail@host3.com>
...image data would go here...
--vcard--
5.2	Recommended Practice With HTTP/HTML
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.
5.2.1	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.
5.2.2	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	
Address	ADR	TYPE=TEXTAREA	
Delivery 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		
Delivery 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		
Location	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.	
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.
5.2.3	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.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<head>
<title>Create Your Own Versitcard</title>
</head>
<IMG src="versit.gif">
<h1>Create Your Own Versitcard</h1>
<P> Fill out this form and we'll
create a <b>Versitcard</b> for you and send it to the email address of your choice,
along with more information on the Versitcard format.</P>
<hr><!-- Identification And Organizational Properties -->
<FORM METHOD="POST" ACTION="/cgi-bin/vcard-maker">
Formatted Name:<INPUT name="FN" type=text size=32 maxlength=64
value=""><br>
Phoenetic Pronunciation:<INPUT name="SOUND" type=text size=32 maxlength=128 value=""><br>
Company Name:<INPUT name="ORG.Name" type=text  size=32 maxlength=64
value=""><br>
Company Unit:<INPUT name="ORG.Unit" type=text size=32
maxlength=64 value=""><br>
Title:<INPUT name="TITLE" type=text size=32 maxlength=64
value="">
<hr><!-- Name Property Component Values -->
Family Name:<INPUT name="N.Family" type=text size=32 maxlength=64
value=""><br>
Given Name:<INPUT name="N.Given" type=text size=32
maxlength=64 value=""><br>
Middle Name:<INPUT name="N.Middle" type=type size=32
maxlength=64 value=""><br>
Name Prefix:<INPUT name="N.Prefix" type=type size=32
maxlength=64 value=""><br>
Name Suffix:<INPUT name="N.Suffix" type=type size=32
maxlength=64 value=""><br>
<hr><!-- Delivery Addressing Properties -->
Delivery Label:<TEXTAREA name="LABEL" cols=64 ROWS=5>
</TEXTAREA><br><br>
Post Office Address:<INPUT name="ADR.POAddr" type=text size=32
maxlength=64 value=""><br>
Extended Address:<INPUT name="ADR.ExtAddr" type=text size=32
maxlength=64 value=""><br>
Street Address:<INPUT name="ADR.Street" type=text size=62
maxlength=128 value=""><br>
City:<INPUT name="ADR.Locality" type=text size=16 maxlength=32
value="">
Region:<INPUT name="ADR.Region" type=text size=16 maxlength=32
value="">
Postal Code:<INPUT name="ADR.PostalCode" type=text size=16 maxlength=32
value=""><br>
Country Name:<INPUT name="ADR.CountryName" type=text size=16 maxlength=32 value="USA">
<INPUT type=checkbox name="ADR.Work" value=WORK checked>Work
<INPUT type=checkbox name="ADR.Home" value=HOME>Home
<INPUT type=checkbox name="ADR.Parcel" value=PARCEL checked>Parcel <INPUT type=checkbox name="ADR.Postal" value=POSTAL checked>Postal<br>
<hr><!-- Geographical Properties -->
TimeZone:<INPUT name="TZ" type=text size=3 maxlength=8
value="-06">
Location:<INPUT name="GEO" type=text size=16 maxlength=32 value=""><br>
<hr><!-- Telephony Addressing Properties -->
<!-- Telephone #1 -->
Telephone #1:<INPUT type=text name="A.TEL" size=20 maxlength=40 value="+1 (000) 000-0000"><br>
<INPUT type=checkbox name="A.TEL.Work" value=WORK checked>Work
<INPUT type=checkbox name="A.TEL.Home" value=HOME>Home
<INPUT type=checkbox name="A.TEL.Voice" value=VOICE checked>Voice
<INPUT type=checkbox name="A.TEL.Msg" value=MSG checked>Msg <INPUT type=checkbox name="A.TEL.Fax" value=FAX>Fax <INPUT type=checkbox name="A.TEL.Prefer" value=PREFER checked>Preferred<br>
<hr><!-- Telephone #2 -->
Telephone #2:<INPUT type=text name="B.TEL" size=20 maxlength=40 value="+1 (000) 000-0000"><br>
<INPUT type=checkbox name="B.TEL.Work" value=WORK checked>Work <INPUT type=checkbox name="B.TEL.Home" value=HOME>Home
<INPUT type=checkbox name="B.TEL.Voice" value=VOICE>Voice <INPUT type=checkbox name="B.TEL.Msg" value=MSG>Msg 
<INPUT type=checkbox name="B.TEL.Fax" value=FAX checked>Fax
<INPUT type=checkbox name="B.TEL.Prefer" value=PREFER>Preferred<br>
<hr><!-- Telephone #3 -->
Telephone #3:<INPUT type=text name= "C.TEL" size=20 maxlength=40 value="+1 (000) 000-0000"><br>
<INPUT type=checkbox name="C.TEL.Work" value=WORK>Work
<INPUT type=checkbox name="C.TEL.Home" value=HOME checked>Home <INPUT type=checkbox name="C.TEL.Voice" value=VOICE checked>Voice <INPUT type=checkbox name="C.TEL.Msg" value=MSG checked>Msg
<INPUT type=checkbox name="C.TEL.Fax" value=FAX checked>Fax <INPUT type=checkbox name="D.Prefer" value=PREFER>Preferred<br>
<hr><!-- Email D -->
EmailAddress: <select name="D.EMAILTYPE">
<option selected>INTERNET:
<option>CompuServe:
<option>AOL:
<option>Prodigy:
<option>eWorld:
<option>AppleLink:
<option>AppleTalk:
<option>PowerShare:
<option>IBMMail:
<option>ATTMail:
<option>MCIMail:
<option>X.400:
<option>TLX:
</select><INPUT type=text name="D.EMAIL" size=32 maxlength=64 value="">
<INPUT type=checkbox name="D.EMAIL.Work" value=WORK checked>Work <INPUT type=checkbox name="D.EMAIL.Home" value=HOME checked>Home<br>
<hr><!-- End of vCard Input -->
Send my Versitcard to this <b>internet</b> email address: 
<INPUT type=text name="SENDTOADDR" size=32 maxlength=64 value=""><br> Press <INPUT TYPE=SUBMIT value="Send"> to send the form now. Or, press <INPUT TYPE=RESET value="Reset"> to reset values to the form defaults.
</form>
</body>

Section 6 : UI Support Recommendations
When  integrating vCard support into an application, an implementor needs to consider a number of user interface (UI) implications. Most applications provide some levels of support for interacting with other applications. This is usually accomplished in three ways. These include the File System, Clipboard, and Drag/Drop. The full potential of the vCard technology can be better utilized if an application supports the vCard in each of these UI actions.
6.1	File System
It is recommended that applications integrating support for vCard specification provide support for importing and exporting vCard objects from the operating system’s file system. In operating systems that support file types, it is recommended that a file type of VCF be used to distinguish the vCard objects. Applications should make use of the file system capabilities to support the FileOpen and FileSaveAs, or their equivalent function, of a vCard object.
6.2	Clipboard
It is recommended that applications integrating support for the vCard specification provide UI capabilities for exchanging vCard objects through the operating system’s clipboard. In operating systems that provide support for registering clipboard format types, it is recommended that the vCard object be registered using the string +//ISBN 1-887687-00-9::versit::PDI//vCard. This string is an ISO 9070 Formal Public Identifier (FPI). Applications should make use of the operating system’s clipboard capability to support the Cut, Copy, and Paste, or their equivalent function, of a vCard object. Applications copying a vCard to the clipboard should put the vCard object on to the clipboard in both the vCard registered format and a plain text format.
6.3	Drag/Drop
It is recommended that applications integrating support for the vCard specification provide UI capabilities for exchanging vCard objects through the operating system’s drag/drop capability. In operating systems that provide support for registering drag/drop object types, it is recommended that the vCard object be registered using the string +//ISBN 1-887687-00-9::versit::PDI//vCard. This string is an ISO 9070 Formal Public Identifier (FPI). Applications should make use of the operating system’s drag/drop capability to enable the application to act as either a Drag Source and Drag Target, or their equivalent function, of a vcard object. Applications acting as a Drag Source should advertise their ability to render the vCard in both the vCard registered format and a plain text format.

Section 7 : Conformance
In order for a vCard Reader or Writer to conform to this specification it must meet the following criteria:
•	Implement at least one of the syntaxes defined by this specification.
•	All properties must be implemented as defined. Statements elsewhere in the specification which describe features as optional or with exceptions take precedence over this criterion.
•	Character set support is up to the underlying implementation. However, support for the default character set (i.e., US ASCII) is required. Optionally, other character sets may be supported.
•	All extensions are optional. It is requested that any vendor-specific extensions include the vendor identification sub-string in the extension name. For example, the extension name X-ABC- for an extension created by the ABC organization.
•	All vendor defined extensions must declare the minimum conformance for that extension.
Additionally, in order for a vCard Reader to conform to this specification it must meet the following additional criteria:
•	Must be able to parse all properties.
•	All forms of vCard Grouping must be able to be parsed and processed.
•	Property Grouping must be able to be parsed and processed.
Additionally, in order for a vCard Writer to conform to this specification it must meet the following additional criteria:
•	Must be able to send at least the Formatted Name, Name, Address,  Telephone, Email, and Mailer properties.