Vendor the vCard specs too
vcard.rb cites RFC 2426 section 2.6 for line folding, which the first vendoring pass missed; 6350 comes along for comparison though nothing implements it. Assisted-by: Claude Opus 5 via Claude Code
diff --git a/docs/rfcs/README.md b/docs/rfcs/README.md
index 0ba215d..a551e02 100644
--- a/docs/rfcs/README.md
+++ b/docs/rfcs/README.md
@@ -5,7 +5,8 @@ citations can be checked offline and so section numbers stay pinned to
the text they were verified against.
`lib/pro_tacts/web.rb` cites these by number and section next to the
-handler that implements each one.
+handler that implements each one, and `lib/pro_tacts/vcard.rb` cites RFC
+2426 for the card format.
| RFC | Title | What it governs here |
| --- | --- | --- |
@@ -15,6 +16,8 @@ handler that implements each one.
| [6764](rfc6764.txt) | Locating Services for CalDAV and CardDAV | The `/.well-known/carddav` bootstrap and its redirect |
| [5397](rfc5397.txt) | WebDAV Current Principal Extension | `current-user-principal` |
| [3253](rfc3253.txt) | Versioning Extensions to WebDAV (DeltaV) | `supported-report-set` only; no versioning is implemented |
+| [2426](rfc2426.txt) | vCard 3.0 | The card format itself; the version Apple clients speak |
+| [6350](rfc6350.txt) | vCard 4.0 | Nothing here implements it; kept for comparison |
One property the server sends has no RFC. `getctag` is an Apple
CalendarServer extension in the `http://calendarserver.org/ns/`
diff --git a/docs/rfcs/rfc2426.txt b/docs/rfcs/rfc2426.txt
new file mode 100644
index 0000000..a393a67
--- /dev/null
+++ b/docs/rfcs/rfc2426.txt
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group F. Dawson
+Request for Comments: 2426 Lotus Development Corporation
+Category: Standards Track T. Howes
+ Netscape Communications
+ September 1998
+
+
+ vCard MIME Directory Profile
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ This memo defines the profile of the MIME Content-Type [MIME-DIR] for
+ directory information for a white-pages person object, based on a
+ vCard electronic business card. The profile definition is independent
+ of any particular directory service or protocol. The profile is
+ defined for representing and exchanging a variety of information
+ about an individual (e.g., formatted and structured name and delivery
+ addresses, email address, multiple telephone numbers, photograph,
+ logo, audio clips, etc.). The directory information used by this
+ profile is based on the attributes for the person object defined in
+ the X.520 and X.521 directory services recommendations. The profile
+ also provides the method for including a [VCARD] representation of a
+ white-pages directory entry within the MIME Content-Type defined by
+ the [MIME-DIR] document.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Howes Standards Track [Page 1]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+Table of Contents
+
+ Overview.........................................................3
+ 1. THE VCARD MIME DIRECTORY PROFILE REGISTRATION.................4
+ 2. MIME DIRECTORY FEATURES.......................................5
+ 2.1 PREDEFINED TYPE USAGE ......................................5
+ 2.1.1 BEGIN and END Type ......................................5
+ 2.1.2 NAME Type ...............................................5
+ 2.1.3 PROFILE Type ............................................5
+ 2.1.4 SOURCE Type .............................................5
+ 2.2 PREDEFINED TYPE PARAMETER USAGE ............................6
+ 2.3 PREDEFINED VALUE TYPE USAGE ................................6
+ 2.4 EXTENSIONS TO THE PREDEFINED VALUE TYPES ...................6
+ 2.4.1 BINARY ..................................................6
+ 2.4.2 VCARD ...................................................6
+ 2.4.3 PHONE-NUMBER ............................................7
+ 2.4.4 UTC-OFFSET ..............................................7
+ 2.5 STRUCTURED TYPE VALUES .....................................7
+ 2.6 LINE DELIMITING AND FOLDING ................................8
+ 3. VCARD PROFILE FEATURES........................................8
+ 3.1 IDENTIFICATION TYPES .......................................8
+ 3.1.1 FN Type Definition ......................................8
+ 3.1.2 N Type Definition .......................................9
+ 3.1.3 NICKNAME Type Definition ................................9
+ 3.1.4 PHOTO Type Definition ..................................10
+ 3.1.5 BDAY Type Definition ...................................11
+ 3.2 DELIVERY ADDRESSING TYPES .................................11
+ 3.2.1 ADR Type Definition ....................................11
+ 3.2.2 LABEL Type Definition ..................................13
+ 3.3 TELECOMMUNICATIONS ADDRESSING TYPES .......................13
+ 3.3.1 TEL Type Definition ....................................14
+ 3.3.2 EMAIL Type Definition ..................................15
+ 3.3.3 MAILER Type Definition .................................15
+ 3.4 GEOGRAPHICAL TYPES ........................................16
+ 3.4.1 TZ Type Definition .....................................16
+ 3.4.2 GEO Type Definition ....................................16
+ 3.5 ORGANIZATIONAL TYPES ......................................17
+ 3.5.1 TITLE Type Definition ..................................17
+ 3.5.2 ROLE Type Definition ...................................18
+ 3.5.3 LOGO Type Definition ...................................18
+ 3.5.4 AGENT Type Definition ..................................19
+ 3.5.5 ORG Type Definition ....................................20
+ 3.6 EXPLANATORY TYPES .........................................20
+ 3.6.1 CATEGORIES Type Definition .............................20
+ 3.6.2 NOTE Type Definition ...................................21
+ 3.6.3 PRODID Type Definition .................................21
+ 3.6.4 REV Type Definition ....................................22
+ 3.6.5 SORT-STRING Type Definition ............................22
+
+
+
+Dawson & Howes Standards Track [Page 2]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ 3.6.6 SOUND Type Definition ..................................23
+ 3.6.7 UID Type Definition ....................................24
+ 3.6.8 URL Type Definition ....................................25
+ 3.6.9 VERSION Type Definition ................................25
+ 3.7 SECURITY TYPES ............................................25
+ 3.7.1 CLASS Type Definition ..................................26
+ 3.7.2 KEY Type Definition ....................................26
+ 3.8 EXTENDED TYPES ............................................27
+ 4. FORMAL GRAMMAR...............................................27
+ 5. DIFFERENCES FROM VCARD V2.1..................................37
+ 6. ACKNOWLEDGEMENTS.............................................39
+ 7. AUTHORS' ADDRESSES...........................................39
+ 8. SECURITY CONSIDERATIONS......................................39
+ 9. REFERENCES...................................................40
+ 10. FULL COPYRIGHT STATEMENT....................................42
+
+Overview
+
+ The [MIME-DIR] document defines a MIME Content-Type for holding
+ different kinds of directory information. The directory information
+ can be based on any of a number of directory schemas. This document
+ defines a [MIME-DIR] usage profile for conveying directory
+ information based on one such schema; that of the white-pages type of
+ person object.
+
+ The schema is based on the attributes for the person object defined
+ in the X.520 and X.521 directory services recommendations. The schema
+ has augmented the basic attributes defined in the X.500 series
+ recommendation in order to provide for an electronic representation
+ of the information commonly found on a paper business card. This
+ schema was first defined in the [VCARD] document. Hence, this [MIME-
+ DIR] profile is referred to as the vCard MIME Directory Profile.
+
+ A directory entry based on this usage profile can include traditional
+ directory, white-pages information such as the distinguished name
+ used to uniquely identify the entry, a formatted representation of
+ the name used for user-interface or presentation purposes, both the
+ structured and presentation form of the delivery address, various
+ telephone numbers and organizational information associated with the
+ entry. In addition, traditional paper business card information such
+ as an image of an organizational logo or identify photograph can be
+ included in this person object.
+
+ The vCard MIME Directory Profile also provides support for
+ representing other important information about the person associated
+ with the directory entry. For instance, the date of birth of the
+ person; an audio clip describing the pronunciation of the name
+ associated with the directory entry, or some other application of the
+
+
+
+Dawson & Howes Standards Track [Page 3]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ digital sound; longitude and latitude geo-positioning information
+ related to the person associated with the directory entry; date and
+ time that the directory information was last updated; annotations
+ often written on a business card; Uniform Resource Locators (URL) for
+ a website; public key information. The profile also provides support
+ for non-standard extensions to the schema. This provides the
+ flexibility for implementations to augment the current capabilities
+ of the profile in a standardized way. More information about this
+ electronic business card format can be found in [VCARD].
+
+1. The vCard Mime Directory Profile Registration
+
+ This profile is identified by the following [MIME-DIR] registration
+ template information. Subsequent sections define the profile
+ definition.
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME profile VCARD
+
+ Profile name: VCARD
+
+ Profile purpose: To hold person object or white-pages type of
+ directory information. The person schema captured in the directory
+ entries is that commonly found in an electronic business card.
+
+ Predefined MIME Directory value specifications used: uri, date,
+ date-time, float
+
+ New value specifications: This profile places further constraints on
+ the [MIME-DIR] text value specification. In addition, it adds a
+ binary, phone-number, utc-offset and vcard value specifications.
+
+ Predefined MIME Directory types used: SOURCE, NAME, PROFILE, BEGIN,
+ END.
+
+ Predefined MIME Directory parameters used: ENCODING, VALUE, CHARSET,
+ LANGUAGE, CONTEXT.
+
+ New types: FN, N, NICKNAME, PHOTO, BDAY, ADR, LABEL, TEL, EMAIL,
+ MAILER, TZ, GEO, TITLE, ROLE, LOGO, AGENT, ORG, CATEGORIES, NOTE,
+ PRODID, REV, SORT-STRING, SOUND, URL, UID, VERSION, CLASS, KEY
+
+ New parameters: TYPE
+
+ Profile special notes: The vCard object MUST contain the FN, N and
+ VERSION types. The type-grouping feature of [MIME-DIR] is supported
+ by this profile to group related vCard properties about a directory
+
+
+
+Dawson & Howes Standards Track [Page 4]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ entry. For example, vCard properties describing WORK or HOME related
+ characteristics can be grouped with a unique group label.
+
+ The profile permits the use of non-standard types (i.e., those
+ identified with the prefix string "X-") as a flexible method for
+ implementations to extend the functionality currently defined within
+ this profile.
+
+2. MIME Directory Features
+
+ The vCard MIME Directory Profile makes use of many of the features
+ defined by [MIME-DIR]. The following sections either clarify or
+ extend the content-type definition of [MIME-DIR].
+
+2.1 Predefined Type Usage
+
+ The vCard MIME Directory Profile uses the following predefined types
+ from [MIME-DIR].
+
+2.1.1 BEGIN and END Type
+
+ The content entity MUST begin with the BEGIN type with a value of
+ "VCARD". The content entity MUST end with the END type with a value
+ of "VCARD".
+
+2.1.2 NAME Type
+
+ If the NAME type is present, then its value is the displayable,
+ presentation text associated with the source for the vCard, as
+ specified in the SOURCE type.
+
+2.1.3 PROFILE Type
+
+ If the PROFILE type is present, then its value MUST be "VCARD".
+
+2.1.4 SOURCE Type
+
+ If the SOURCE type is present, then its value provides information
+ how to find the source for the vCard.
+
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Howes Standards Track [Page 5]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+2.2 Predefined Type Parameter Usage
+
+ The vCard MIME Directory Profile uses the following predefined type
+ parameters as defined by [MIME-DIR].
+
+ - LANGUAGE
+
+ - ENCODING
+
+ - VALUE
+
+2.3 Predefined VALUE Type Usage
+
+ The predefined data type values specified in [MIME-DIR] MUST NOT be
+ repeated in COMMA separated value lists except within the N,
+ NICKNAME, ADR and CATEGORIES value types.
+
+ The text value type defined in [MIME-DIR] is further restricted such
+ that any SEMI-COLON character (ASCII decimal 59) in the value MUST be
+ escaped with the BACKSLASH character (ASCII decimal 92).
+
+2.4 Extensions To The Predefined VALUE Types
+
+ The predefined data type values specified in [MIME-DIR] have been
+ extended by the vCard profile to include a number of value types that
+ are specific to this profile.
+
+2.4.1 BINARY
+
+ The "binary" value type specifies that the type value is inline,
+ encoded binary data. This value type can be specified in the PHOTO,
+ LOGO, SOUND, and KEY types.
+
+ If inline encoded binary data is specified, the ENCODING type
+ parameter MUST be used to specify the encoding format. The binary
+ data MUST be encoded using the "B" encoding format. Long lines of
+ encoded binary data SHOULD BE folded to 75 characters using the
+ folding method defined in [MIME-DIR].
+
+ The value type is defined by the following notation:
+
+ binary = <A "B" binary encoded string as defined by [RFC 2047].>
+
+2.4.2 VCARD
+
+ The "vcard" value type specifies that the type value is another
+ vCard. This value type can be specified in the AGENT type. The value
+ type is defined by this specification. Since each of the type
+
+
+
+Dawson & Howes Standards Track [Page 6]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ declarations with in the vcard value type are being specified within
+ a text value themselves, they MUST be terminated with the backslash
+ escape sequence "\n" or "\N", instead of the normal newline character
+ sequence CRLF. In addition, any COMMA character (ASCII decimal 44),
+ SEMI-COLON character (ASCII decimal 59) and COLON character (ASCII
+ decimal 58) MUST be escaped with the BACKSLASH character (ASCII
+ decimal 92). For example, with the AGENT type a value would be
+ specified as:
+
+ AGENT:BEGIN:VCARD\nFN:Joe Friday\nTEL:+1-919-555-7878\n
+ TITLE:Area Administrator\, Assistant\n EMAIL\;TYPE=INTERN\n
+ ET:jfriday@host.com\nEND:VCARD\n
+
+2.4.3 PHONE-NUMBER
+
+ The "phone-number" value type specifies that the type value is a
+ telephone number. This value type can be specified in the TEL type.
+ The value type is a text value that has the special semantics of a
+ telephone number as defined in [CCITT E.163] and [CCITT X.121].
+
+2.4.4 UTC-OFFSET
+
+ The "utc-offset" value type specifies that the type value is a signed
+ offset from UTC. This value type can be specified in the TZ type.
+
+ The value type is an offset from Coordinated Universal Time (UTC). It
+ is specified as a positive or negative difference in units of hours
+ and minutes (e.g., +hh:mm). The time is specified as a 24-hour clock.
+ Hour values are from 00 to 23, and minute values are from 00 to 59.
+ Hour and minutes are 2-digits with high order zeroes required to
+ maintain digit count. The extended format for ISO 8601 UTC offsets
+ MUST be used. The extended format makes use of a colon character as a
+ separator of the hour and minute text fields.
+
+ The value is defined by the following notation:
+
+ time-hour = 2DIGIT ;00-23
+ time-minute = 2DIGIT ;00-59
+ utc-offset = ("+" / "-") time-hour ":" time-minute
+
+2.5 Structured Type Values
+
+ Compound type values are delimited by a field delimiter, specified by
+ the SEMI-COLON character (ASCII decimal 59). A SEMI-COLON in a
+ component of a compound property value MUST be escaped with a
+ BACKSLASH character (ASCII decimal 92).
+
+
+
+
+
+Dawson & Howes Standards Track [Page 7]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Lists of values are delimited by a list delimiter, specified by the
+ COMMA character (ASCII decimal 44). A COMMA character in a value MUST
+ be escaped with a BACKSLASH character (ASCII decimal 92).
+
+ This profile supports the type grouping mechanism defined in [MIME-
+ DIR]. Grouping of related types is a useful technique to communicate
+ common semantics concerning the properties of a vCard.
+
+2.6 Line Delimiting and Folding
+
+ This profile supports the same line delimiting and folding methods
+ defined in [MIME-DIR]. Specifically, when parsing a content line,
+ folded lines must first be unfolded according to the unfolding
+ procedure described in [MIME-DIR]. After generating a content line,
+ lines longer than 75 characters SHOULD be folded according to the
+ folding procedure described in [MIME DIR].
+
+ Folding is done after any content encoding of a type value. Unfolding
+ is done before any decoding of a type value in a content line.
+
+3. vCard Profile Features
+
+ The vCard MIME Directory Profile Type contains directory information,
+ typically pertaining to a single directory entry. The information is
+ described using an attribute schema that is tailored for capturing
+ personal contact information. The vCard can include attributes that
+ describe identification, delivery addressing, telecommunications
+ addressing, geographical, organizational, general explanatory and
+ security and access information about the particular object
+ associated with the vCard.
+
+3.1 Identification Types
+
+ These types are used in the vCard profile to capture information
+ associated with the identification and naming of the person or
+ resource associated with the vCard.
+
+3.1.1 FN Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type FN
+
+ Type name:FN
+
+ Type purpose: To specify the formatted text corresponding to the name
+ of the object the vCard represents.
+
+
+
+
+Dawson & Howes Standards Track [Page 8]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+ Type special notes: This type is based on the semantics of the X.520
+ Common Name attribute. The property MUST be present in the vCard
+ object.
+
+ Type example:
+
+ FN:Mr. John Q. Public\, Esq.
+
+3.1.2 N Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type N
+
+ Type name: N
+
+ Type purpose: To specify the components of the name of the object the
+ vCard represents.
+
+ Type encoding: 8bit
+
+ Type value: A single structured text value. Each component can have
+ multiple values.
+
+ Type special note: The structured type value corresponds, in
+ sequence, to the Family Name, Given Name, Additional Names, Honorific
+ Prefixes, and Honorific Suffixes. The text components are separated
+ by the SEMI-COLON character (ASCII decimal 59). Individual text
+ components can include multiple text values (e.g., multiple
+ Additional Names) separated by the COMMA character (ASCII decimal
+ 44). This type is based on the semantics of the X.520 individual name
+ attributes. The property MUST be present in the vCard object.
+
+ Type example:
+
+ N:Public;John;Quinlan;Mr.;Esq.
+
+ N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
+
+3.1.3 NICKNAME Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type NICKNAME
+
+
+
+Dawson & Howes Standards Track [Page 9]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type name: NICKNAME
+
+ Type purpose: To specify the text corresponding to the nickname of
+ the object the vCard represents.
+
+ Type encoding: 8bit
+
+ Type value: One or more text values separated by a COMMA character
+ (ASCII decimal 44).
+
+ Type special note: The nickname is the descriptive name given instead
+ of or in addition to the one belonging to a person, place, or thing.
+ It can also be used to specify a familiar form of a proper name
+ specified by the FN or N types.
+
+ Type example:
+
+ NICKNAME:Robbie
+
+ NICKNAME:Jim,Jimmie
+
+3.1.4 PHOTO Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type PHOTO
+
+ Type name: PHOTO
+
+ Type purpose: To specify an image or photograph information that
+ annotates some aspect of the object the vCard represents.
+
+ Type encoding: The encoding MUST be reset to "b" using the ENCODING
+ parameter in order to specify inline, encoded binary data. If the
+ value is referenced by a URI value, then the default encoding of 8bit
+ is used and no explicit ENCODING parameter is needed.
+
+ Type value: A single value. The default is binary value. It can also
+ be reset to uri value. The uri value can be used to specify a value
+ outside of this MIME entity.
+
+ Type special notes: The type can include the type parameter "TYPE" to
+ specify the graphic image format type. The TYPE parameter values MUST
+ be one of the IANA registered image formats or a non-standard image
+ format.
+
+
+
+
+
+
+Dawson & Howes Standards Track [Page 10]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type example:
+
+ PHOTO;VALUE=uri:http://www.abc.com/pub/photos
+ /jqpublic.gif
+
+
+ PHOTO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
+ AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
+ ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+ <...remainder of "B" encoded binary data...>
+
+3.1.5 BDAY Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type BDAY
+
+ Type name: BDAY
+
+ Type purpose: To specify the birth date of the object the vCard
+ represents.
+
+ Type encoding: 8bit
+
+ Type value: The default is a single date value. It can also be reset
+ to a single date-time value.
+
+ Type examples:
+
+ BDAY:1996-04-15
+
+ BDAY:1953-10-15T23:10:00Z
+
+ BDAY:1987-09-27T08:30:00-06:00
+
+3.2 Delivery Addressing Types
+
+ These types are concerned with information related to the delivery
+ addressing or label for the vCard object.
+
+3.2.1 ADR Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type ADR
+
+ Type name: ADR
+
+
+
+
+Dawson & Howes Standards Track [Page 11]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type purpose: To specify the components of the delivery address for
+ the vCard object.
+
+ Type encoding: 8bit
+
+ Type value: A single structured text value, separated by the
+ SEMI-COLON character (ASCII decimal 59).
+
+ Type special notes: The structured type value consists of a sequence
+ of address components. The component values MUST be specified in
+ their corresponding position. The structured type value corresponds,
+ in sequence, to the post office box; the extended address; the street
+ address; the locality (e.g., city); the region (e.g., state or
+ province); the postal code; the country name. When a component value
+ is missing, the associated component separator MUST still be
+ specified.
+
+ The text components are separated by the SEMI-COLON character (ASCII
+ decimal 59). Where it makes semantic sense, individual text
+ components can include multiple text values (e.g., a "street"
+ component with multiple lines) separated by the COMMA character
+ (ASCII decimal 44).
+
+ The type can include the type parameter "TYPE" to specify the
+ delivery address type. The TYPE parameter values can include "dom" to
+ indicate a domestic delivery address; "intl" to indicate an
+ international delivery address; "postal" to indicate a postal
+ delivery address; "parcel" to indicate a parcel delivery address;
+ "home" to indicate a delivery address for a residence; "work" to
+ indicate delivery address for a place of work; and "pref" to indicate
+ the preferred delivery address when more than one address is
+ specified. These type parameter values can be specified as a
+ parameter list (i.e., "TYPE=dom;TYPE=postal") or as a value list
+ (i.e., "TYPE=dom,postal"). This type is based on semantics of the
+ X.520 geographical and postal addressing attributes. The default is
+ "TYPE=intl,postal,parcel,work". The default can be overridden to some
+ other set of values by specifying one or more alternate values. For
+ example, the default can be reset to "TYPE=dom,postal,work,home" to
+ specify a domestic delivery address for postal delivery to a
+ residence that is also used for work.
+
+ Type example: In this example the post office box and the extended
+ address are absent.
+
+ ADR;TYPE=dom,home,postal,parcel:;;123 Main
+ Street;Any Town;CA;91921-1234
+
+
+
+
+
+Dawson & Howes Standards Track [Page 12]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+3.2.2 LABEL Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type LABEL
+
+ Type name: LABEL
+
+ Type purpose: To specify the formatted text corresponding to delivery
+ address of the object the vCard represents.
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+ Type special notes: The type value is formatted text that can be used
+ to present a delivery address label for the vCard object. The type
+ can include the type parameter "TYPE" to specify delivery label type.
+ The TYPE parameter values can include "dom" to indicate a domestic
+ delivery label; "intl" to indicate an international delivery label;
+ "postal" to indicate a postal delivery label; "parcel" to indicate a
+ parcel delivery label; "home" to indicate a delivery label for a
+ residence; "work" to indicate delivery label for a place of work; and
+ "pref" to indicate the preferred delivery label when more than one
+ label is specified. These type parameter values can be specified as a
+ parameter list (i.e., "TYPE=dom;TYPE=postal") or as a value list
+ (i.e., "TYPE=dom,postal"). This type is based on semantics of the
+ X.520 geographical and postal addressing attributes. The default is
+ "TYPE=intl,postal,parcel,work". The default can be overridden to some
+ other set of values by specifying one or more alternate values. For
+ example, the default can be reset to "TYPE=intl,post,parcel,home" to
+ specify an international delivery label for both postal and parcel
+ delivery to a residential location.
+
+ Type example: A multi-line address label.
+
+ LABEL;TYPE=dom,home,postal,parcel:Mr.John Q. Public\, Esq.\n
+ Mail Drop: TNE QB\n123 Main Street\nAny Town\, CA 91921-1234
+ \nU.S.A.
+
+3.3 Telecommunications Addressing Types
+
+ These types are concerned with information associated with the
+ telecommunications addressing of the object the vCard represents.
+
+
+
+
+
+
+
+Dawson & Howes Standards Track [Page 13]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+3.3.1 TEL Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type TEL
+
+ Type name: TEL
+
+ Type purpose: To specify the telephone number for telephony
+ communication with the object the vCard represents.
+
+ Type encoding: 8bit
+
+ Type value: A single phone-number value.
+
+ Type special notes: The value of this type is specified in a
+ canonical form in order to specify an unambiguous representation of
+ the globally unique telephone endpoint. This type is based on the
+ X.500 Telephone Number attribute.
+
+ The type can include the type parameter "TYPE" to specify intended
+ use for the telephone number. The TYPE parameter values can include:
+ "home" to indicate a telephone number associated with a residence,
+ "msg" to indicate the telephone number has voice messaging support,
+ "work" to indicate a telephone number associated with a place of
+ work, "pref" to indicate a preferred-use telephone number, "voice" to
+ indicate a voice telephone number, "fax" to indicate a facsimile
+ telephone number, "cell" to indicate a cellular telephone number,
+ "video" to indicate a video conferencing telephone number, "pager" to
+ indicate a paging device telephone number, "bbs" to indicate a
+ bulletin board system telephone number, "modem" to indicate a MODEM
+ connected telephone number, "car" to indicate a car-phone telephone
+ number, "isdn" to indicate an ISDN service telephone number, "pcs" to
+ indicate a personal communication services telephone number. The
+ default type is "voice". These type parameter values can be specified
+ as a parameter list (i.e., "TYPE=work;TYPE=voice") or as a value list
+ (i.e., "TYPE=work,voice"). The default can be overridden to another
+ set of values by specifying one or more alternate values. For
+ example, the default TYPE of "voice" can be reset to a WORK and HOME,
+ VOICE and FAX telephone number by the value list
+ "TYPE=work,home,voice,fax".
+
+ Type example:
+
+ TEL;TYPE=work,voice,pref,msg:+1-213-555-1234
+
+
+
+
+
+
+Dawson & Howes Standards Track [Page 14]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+3.3.2 EMAIL Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type EMAIL
+
+ Type name: EMAIL
+
+ Type purpose: To specify the electronic mail address for
+ communication with the object the vCard represents.
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+ Type special notes: The type can include the type parameter "TYPE" to
+ specify the format or preference of the electronic mail address. The
+ TYPE parameter values can include: "internet" to indicate an Internet
+ addressing type, "x400" to indicate a X.400 addressing type or "pref"
+ to indicate a preferred-use email address when more than one is
+ specified. Another IANA registered address type can also be
+ specified. The default email type is "internet". A non-standard value
+ can also be specified.
+
+ Type example:
+
+ EMAIL;TYPE=internet:jqpublic@xyz.dom1.com
+
+ EMAIL;TYPE=internet:jdoe@isp.net
+
+ EMAIL;TYPE=internet,pref:jane_doe@abc.com
+
+3.3.3 MAILER Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type MAILER
+
+ Type name: MAILER
+
+ Type purpose: To specify the type of electronic mail software that is
+ used by the individual associated with the vCard.
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+
+
+
+
+Dawson & Howes Standards Track [Page 15]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type special notes: This information can provide assistance to a
+ correspondent regarding the type of data representation which can be
+ used, and how they can be packaged. This property is based on the
+ private MIME type X-Mailer that is generally implemented by MIME user
+ agent products.
+
+ Type example:
+
+ MAILER:PigeonMail 2.1
+
+3.4 Geographical Types
+
+ These types are concerned with information associated with
+ geographical positions or regions associated with the object the
+ vCard represents.
+
+3.4.1 TZ Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type TZ
+
+ Type name: TZ
+
+ Type purpose: To specify information related to the time zone of the
+ object the vCard represents.
+
+ Type encoding: 8bit
+
+ Type value: The default is a single utc-offset value. It can also be
+ reset to a single text value.
+
+ Type special notes: The type value consists of a single value.
+
+ Type examples:
+
+ TZ:-05:00
+
+ TZ;VALUE=text:-05:00; EST; Raleigh/North America
+ ;This example has a single value, not a structure text value.
+
+3.4.2 GEO Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type GEO
+
+ Type name: GEO
+
+
+
+Dawson & Howes Standards Track [Page 16]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type purpose: To specify information related to the global
+ positioning of the object the vCard represents.
+
+ Type encoding: 8bit
+
+ Type value: A single structured value consisting of two float values
+ separated by the SEMI-COLON character (ASCII decimal 59).
+
+ Type special notes: This type specifies information related to the
+ global position of the object associated with the vCard. The value
+ specifies latitude and longitude, in that order (i.e., "LAT LON"
+ ordering). The longitude represents the location east and west of the
+ prime meridian as a positive or negative real number, respectively.
+ The latitude represents the location north and south of the equator
+ as a positive or negative real number, respectively. The longitude
+ and latitude values MUST be specified as decimal degrees and should
+ be specified to six decimal places. This will allow for granularity
+ within a meter of the geographical position. The text components are
+ separated by the SEMI-COLON character (ASCII decimal 59). The simple
+ formula for converting degrees-minutes-seconds into decimal degrees
+ is:
+
+ decimal = degrees + minutes/60 + seconds/3600.
+
+ Type example:
+
+ GEO:37.386013;-122.082932
+
+3.5 Organizational Types
+
+ These types are concerned with information associated with
+ characteristics of the organization or organizational units of the
+ object the vCard represents.
+
+3.5.1 TITLE Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type TITLE
+
+ Type name: TITLE
+
+ Type purpose: To specify the job title, functional position or
+ function of the object the vCard represents.
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+
+
+Dawson & Howes Standards Track [Page 17]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type special notes: This type is based on the X.520 Title attribute.
+
+ Type example:
+
+ TITLE:Director\, Research and Development
+
+3.5.2 ROLE Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type ROLE
+
+ Type name: ROLE
+
+ Type purpose: To specify information concerning the role, occupation,
+ or business category of the object the vCard represents.
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+ Type special notes: This type is based on the X.520 Business Category
+ explanatory attribute. This property is included as an organizational
+ type to avoid confusion with the semantics of the TITLE type and
+ incorrect usage of that type when the semantics of this type is
+ intended.
+
+ Type example:
+
+ ROLE:Programmer
+
+3.5.3 LOGO Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type LOGO
+
+ Type name: LOGO
+
+ Type purpose: To specify a graphic image of a logo associated with
+ the object the vCard represents.
+
+ Type encoding: The encoding MUST be reset to "b" using the ENCODING
+ parameter in order to specify inline, encoded binary data. If the
+ value is referenced by a URI value, then the default encoding of 8bit
+ is used and no explicit ENCODING parameter is needed.
+
+
+
+
+
+Dawson & Howes Standards Track [Page 18]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type value: A single value. The default is binary value. It can also
+ be reset to uri value. The uri value can be used to specify a value
+ outside of this MIME entity.
+
+ Type special notes: The type can include the type parameter "TYPE" to
+ specify the graphic image format type. The TYPE parameter values MUST
+ be one of the IANA registered image formats or a non-standard image
+ format.
+
+ Type example:
+
+ LOGO;VALUE=uri:http://www.abc.com/pub/logos/abccorp.jpg
+
+ LOGO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
+ AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
+ ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+ <...the remainder of "B" encoded binary data...>
+
+3.5.4 AGENT Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type AGENT
+
+ Type name: AGENT
+
+ Type purpose: To specify information about another person who will
+ act on behalf of the individual or resource associated with the
+ vCard.
+
+ Type encoding: 8-bit
+
+ Type value: The default is a single vcard value. It can also be reset
+ to either a single text or uri value. The text value can be used to
+ specify textual information. The uri value can be used to specify
+ information outside of this MIME entity.
+
+ Type special notes: This type typically is used to specify an area
+ administrator, assistant, or secretary for the individual associated
+ with the vCard. A key characteristic of the Agent type is that it
+ represents somebody or something that is separately addressable.
+
+ Type example:
+
+ AGENT;VALUE=uri:
+ CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com
+
+
+
+
+
+Dawson & Howes Standards Track [Page 19]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ AGENT:BEGIN:VCARD\nFN:Susan Thomas\nTEL:+1-919-555-
+ 1234\nEMAIL\;INTERNET:sthomas@host.com\nEND:VCARD\n
+
+3.5.5 ORG Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type ORG
+
+ Type name: ORG
+
+ Type purpose: To specify the organizational name and units associated
+ with the vCard.
+
+ Type encoding: 8bit
+
+ Type value: A single structured text value consisting of components
+ separated the SEMI-COLON character (ASCII decimal 59).
+
+ Type special notes: The type is based on the X.520 Organization Name
+ and Organization Unit attributes. The type value is a structured type
+ consisting of the organization name, followed by one or more levels
+ of organizational unit names.
+
+ Type example: A type value consisting of an organizational name,
+ organizational unit #1 name and organizational unit #2 name.
+
+ ORG:ABC\, Inc.;North American Division;Marketing
+
+3.6 Explanatory Types
+
+ These types are concerned with additional explanations, such as that
+ related to informational notes or revisions specific to the vCard.
+
+3.6.1 CATEGORIES Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type CATEGORIES
+
+ Type name: CATEGORIES
+
+ Type purpose: To specify application category information about the
+ vCard.
+
+ Type encoding: 8bit
+
+
+
+
+
+Dawson & Howes Standards Track [Page 20]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type value: One or more text values separated by a COMMA character
+ (ASCII decimal 44).
+
+ Type example:
+
+ CATEGORIES:TRAVEL AGENT
+
+ CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
+
+3.6.2 NOTE Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type NOTE
+
+ Type name: NOTE
+
+ Type purpose: To specify supplemental information or a comment that
+ is associated with the vCard.
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+ Type special notes: The type is based on the X.520 Description
+ attribute.
+
+ Type example:
+
+ NOTE:This fax number is operational 0800 to 1715
+ EST\, Mon-Fri.
+
+3.6.3 PRODID Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type PRODID
+
+ Type name: PRODID
+
+ Type purpose: To specify the identifier for the product that created
+ the vCard object.
+
+ Type encoding: 8-bit
+
+ Type value: A single text value.
+
+
+
+
+
+Dawson & Howes Standards Track [Page 21]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type special notes: Implementations SHOULD use a method such as that
+ specified for Formal Public Identifiers in ISO 9070 to assure that
+ the text value is unique.
+
+ Type example:
+
+ PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
+
+3.6.4 REV Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type REV
+
+ Type name: REV
+
+ Type purpose: To specify revision information about the current
+ vCard.
+
+ Type encoding: 8-bit
+
+ Type value: The default is a single date-time value. Can also be
+ reset to a single date value.
+
+ Type special notes: The value distinguishes the current revision of
+ the information in this vCard for other renditions of the
+ information.
+
+ Type example:
+
+ REV:1995-10-31T22:27:10Z
+
+ REV:1997-11-15
+
+3.6.5 SORT-STRING Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type SORT-STRING
+
+ Type Name: SORT-STRING
+
+ Type purpose: To specify the family name or given name text to be
+ used for national-language-specific sorting of the FN and N types.
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+
+
+Dawson & Howes Standards Track [Page 22]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type special notes: The sort string is used to provide family name or
+ given name text that is to be used in locale- or national-language-
+ specific sorting of the formatted name and structured name types.
+ Without this information, sorting algorithms could incorrectly sort
+ this vCard within a sequence of sorted vCards. When this type is
+ present in a vCard, then this family name or given name value is used
+ for sorting the vCard.
+
+ Type examples: For the case of family name sorting, the following
+ examples define common sort string usage with the FN and N types.
+
+ FN:Rene van der Harten
+ N:van der Harten;Rene;J.;Sir;R.D.O.N.
+ SORT-STRING:Harten
+
+ FN:Robert Pau Shou Chang
+ N:Pau;Shou Chang;Robert
+ SORT-STRING:Pau
+
+ FN:Osamu Koura
+ N:Koura;Osamu
+ SORT-STRING:Koura
+
+ FN:Oscar del Pozo
+ N:del Pozo Triscon;Oscar
+ SORT-STRING:Pozo
+
+ FN:Chistine d'Aboville
+ N:d'Aboville;Christine
+ SORT-STRING:Aboville
+
+3.6.6 SOUND Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type SOUND
+
+ Type name: SOUND
+
+ Type purpose: To specify a digital sound content information that
+ annotates some aspect of the vCard. By default this type is used to
+ specify the proper pronunciation of the name type value of the vCard.
+
+ Type encoding: The encoding MUST be reset to "b" using the ENCODING
+ parameter in order to specify inline, encoded binary data. If the
+ value is referenced by a URI value, then the default encoding of 8bit
+ is used and no explicit ENCODING parameter is needed.
+
+
+
+
+Dawson & Howes Standards Track [Page 23]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type value: A single value. The default is binary value. It can also
+ be reset to uri value. The uri value can be used to specify a value
+ outside of this MIME entity.
+
+ Type special notes: The type can include the type parameter "TYPE" to
+ specify the audio format type. The TYPE parameter values MUST be one
+ of the IANA registered audio formats or a non-standard audio format.
+
+ Type example:
+
+ SOUND;TYPE=BASIC;VALUE=uri:CID:JOHNQPUBLIC.part8.
+ 19960229T080000.xyzMail@host1.com
+
+ SOUND;TYPE=BASIC;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
+ AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
+ ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+ <...the remainder of "B" encoded binary data...>
+
+3.6.7 UID Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type UID
+
+ Type name: UID
+
+ Type purpose: To specify a value that represents a globally unique
+ identifier corresponding to the individual or resource associated
+ with the vCard.
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+ Type special notes: The type is used to uniquely identify the object
+ that the vCard represents.
+
+ The type can include the type parameter "TYPE" to specify the format
+ of the identifier. The TYPE parameter value should be an IANA
+ registered identifier format. The value can also be a non-standard
+ format.
+
+ Type example:
+
+ UID:19950401-080045-40000F192713-0052
+
+
+
+
+
+
+Dawson & Howes Standards Track [Page 24]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+3.6.8 URL Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type URL
+
+ Type name: URL
+
+ Type purpose: To specify a uniform resource locator associated with
+ the object that the vCard refers to.
+
+ Type encoding: 8bit
+
+ Type value: A single uri value.
+
+ Type example:
+
+ URL:http://www.swbyps.restaurant.french/~chezchic.html
+
+3.6.9 VERSION Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type VERSION
+
+ Type name: VERSION
+
+ Type purpose: To specify the version of the vCard specification used
+ to format this vCard.
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+ Type special notes: The property MUST be present in the vCard object.
+ The value MUST be "3.0" if the vCard corresponds to this
+ specification.
+
+ Type example:
+
+ VERSION:3.0
+
+3.7 Security Types
+
+ These types are concerned with the security of communication pathways
+ or access to the vCard.
+
+
+
+
+
+Dawson & Howes Standards Track [Page 25]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+3.7.1 CLASS Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type CLASS
+
+ Type name: CLASS
+
+ Type purpose: To specify the access classification for a vCard
+ object.
+
+ Type encoding: 8bit
+
+ Type value: A single text value.
+
+ Type special notes: An access classification is only one component of
+ the general security model for a directory service. The
+ classification attribute provides a method of capturing the intent of
+ the owner for general access to information described by the vCard
+ object.
+
+ Type examples:
+
+ CLASS:PUBLIC
+
+ CLASS:PRIVATE
+
+ CLASS:CONFIDENTIAL
+
+3.7.2 KEY Type Definition
+
+ To: ietf-mime-directory@imc.org
+
+ Subject: Registration of text/directory MIME type KEY
+
+ Type name: KEY
+
+ Type purpose: To specify a public key or authentication certificate
+ associated with the object that the vCard represents.
+
+ Type encoding: The encoding MUST be reset to "b" using the ENCODING
+ parameter in order to specify inline, encoded binary data. If the
+ value is a text value, then the default encoding of 8bit is used and
+ no explicit ENCODING parameter is needed.
+
+ Type value: A single value. The default is binary. It can also be
+ reset to text value. The text value can be used to specify a text
+ key.
+
+
+
+Dawson & Howes Standards Track [Page 26]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ Type special notes: The type can also include the type parameter TYPE
+ to specify the public key or authentication certificate format. The
+ parameter type should specify an IANA registered public key or
+ authentication certificate format. The parameter type can also
+ specify a non-standard format.
+
+ Type example:
+
+ KEY;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
+ wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
+ Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+ ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
+ E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
+ VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
+ MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
+ Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
+ EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
+ dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
+ EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
+ +hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
+ mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
+ rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
+ UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
+
+3.8 Extended Types
+
+ The types defined by this document can be extended with private types
+ using the non-standard, private values mechanism defined in [RFC
+ 2045]. Non-standard, private types with a name starting with "X-" may
+ be defined bilaterally between two cooperating agents without outside
+ registration or standardization.
+
+4. Formal Grammar
+
+ The following formal grammar is provided to assist developers in
+ building parsers for the vCard.
+
+ This syntax is written according to the form described in RFC 2234,
+ but it references just this small subset of RFC 2234 literals:
+
+ ;*******************************************
+ ; Commonly Used Literal Definition
+ ;*******************************************
+
+ ALPHA = %x41-5A / %x61-7A
+ ; Latin Capital Letter A-Latin Capital Letter Z /
+ ; Latin Small Letter a-Latin Small Letter z
+
+
+
+
+Dawson & Howes Standards Track [Page 27]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ CHAR = %x01-7F
+ ; Any C0 Controls and Basic Latin, excluding NULL from
+ ; Code Charts, pages 7-6 through 7-9 in [UNICODE]
+
+ CR = %x0D
+ ; Carriage Return
+
+ LF = %0A
+ ; Line Feed
+
+ CRLF = CR LF
+ ; Internet standard newline
+
+ ;CTL = %x00-1F / %x7F
+ ; Controls. Not used, but referenced in comments.
+
+ DIGIT = %x30-39
+ ; Digit Zero-Digit Nine
+
+ DQUOTE = %x22
+ ; Quotation Mark
+
+ HTAB = %x09
+ ; Horizontal Tabulation
+
+ SP = %x20
+ ; space
+
+ VCHAR = %x21-7E
+ ; Visible (printing) characters
+
+ WSP = SP / HTAB
+ ; White Space
+
+ ;*******************************************
+ ; Basic vCard Definition
+ ;*******************************************
+
+ vcard_entity = 1*(vcard)
+
+ vcard = [group "."] "BEGIN" ":" "VCARD" 1*CRLF
+ 1*(contentline)
+ ;A vCard object MUST include the VERSION, FN and N types.
+ [group "."] "END" ":" "VCARD" 1*CRLF
+
+ contentline = [group "."] name *(";" param ) ":" value CRLF
+ ; When parsing a content line, folded lines must first
+ ; be unfolded according to the unfolding procedure
+
+
+
+Dawson & Howes Standards Track [Page 28]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ ; described above. When generating a content line, lines
+ ; longer than 75 characters SHOULD be folded according to
+ ; the folding procedure described in [MIME DIR].
+
+ group = 1*(ALPHA / DIGIT / "-")
+
+ name = iana-token / x-name
+ ; Parsing of the param and value is
+ ; based on the "name" or type identifier
+ ; as defined in ABNF sections below
+
+ iana-token = 1*(ALPHA / DIGIT / "-")
+ ; vCard type or parameter identifier registered with IANA
+
+ x-name = "X-" 1*(ALPHA / DIGIT / "-")
+ ; Reserved for non-standard use
+
+ param = param-name "=" param-value *("," param-value)
+
+ param-name = iana-token / x-name
+
+ param-value = ptext / quoted-string
+
+ ptext = *SAFE-CHAR
+
+ value = *VALUE-CHAR
+
+ quoted-string = DQUOTE QSAFE-CHAR DQUOTE
+
+ NON-ASCII = %x80-FF
+ ; Use is restricted by CHARSET parameter
+ ; on outer MIME object (UTF-8 preferred)
+
+ QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII
+ ; Any character except CTLs, DQUOTE
+
+ SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
+ ; Any character except CTLs, DQUOTE, ";", ":", ","
+
+ VALUE-CHAR = WSP / VCHAR / NON-ASCII
+ ; Any textual character
+
+ ;*******************************************
+ ; vCard Type Definition
+ ;
+ ; Provides type-specific definitions for how the
+ ; "value" and "param" are defined.
+ ;*******************************************
+
+
+
+Dawson & Howes Standards Track [Page 29]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ ;For name="NAME"
+ param = ""
+ ; No parameters allowed
+
+ value = text-value
+
+ ;For name="PROFILE"
+ param = ""
+ ; No parameters allowed
+
+ value = text-value
+ ; Value MUST be the case insensitive value "VCARD
+
+ ;For name="SOURCE"
+ param = source-param
+ ; No parameters allowed
+
+ value = uri
+
+ source-param = ("VALUE" "=" "uri")
+ / ("CONTEXT" "=" "word")
+ ; Parameter value specifies the protocol context
+ ; for the uri value.
+ / (x-name "=" *SAFE-CHAR)
+
+ ;For name="FN"
+ ;This type MUST be included in a vCard object.
+ param = text-param
+ ; Text parameters allowed
+
+ value = text-value
+
+ ;For name="N"
+ ;This type MUST be included in a vCard object.
+
+ param = text-param
+ ; Text parameters allowed
+
+ value = n-value
+
+ n-value = 0*4(text-value *("," text-value) ";")
+ text-value *("," text-value)
+ ; Family; Given; Middle; Prefix; Suffix.
+ ; Example: Public;John;Quincy,Adams;Reverend Dr. III
+
+ ;For name="NICKNAME"
+ param = text-param
+ ; Text parameters allowed
+
+
+
+Dawson & Howes Standards Track [Page 30]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ value = text-list
+
+ ;For name="PHOTO"
+ param = img-inline-param
+ ; Only image parameters allowed
+
+ param =/ img-refer-param
+ ; Only image parameters allowed
+
+ value = img-inline-value
+ ; Value and parameter MUST match
+
+ value =/ img-refer-value
+ ; Value and parameter MUST match
+
+ ;For name="BDAY"
+ param = ("VALUE" "=" "date")
+ ; Only value parameter allowed
+
+ param =/ ("VALUE" "=" "date-time")
+ ; Only value parameter allowed
+
+ value = date-value
+ ; Value MUST match value type
+
+ value =/ date-time-value
+ ; Value MUST match value type
+
+ ;For name="ADR"
+ param = adr-param / text-param
+ ; Only adr and text parameters allowed
+
+ value = adr-value
+
+ ;For name="LABEL"
+ param = adr-param / text-param
+ ; Only adr and text parameters allowed
+
+ value = text-value
+
+ ;For name="TEL"
+ param = tel-param
+ ; Only tel parameters allowed
+
+ value = phone-number-value
+
+ tel-param = "TYPE" "=" tel-type *("," tel-type)
+
+
+
+
+Dawson & Howes Standards Track [Page 31]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ tel-type = "HOME" / "WORK" / "PREF" / "VOICE" / "FAX" / "MSG"
+ / "CELL" / "PAGER" / "BBS" / "MODEM" / "CAR" / "ISDN"
+ / "VIDEO" / "PCS" / iana-token / x-name
+ ; Values are case insensitive
+
+ ;For name="EMAIL"
+ param = email-param
+ ; Only email parameters allowed
+
+ value = text-value
+
+ email-param = "TYPE" "=" email-type ["," "PREF"]
+ ; Value is case insensitive
+
+ email-type = "INTERNET" / "X400" / iana-token / "X-" word
+ ; Values are case insensitive
+
+ ;For name="MAILER"
+ param = text-param
+ ; Only text parameters allowed
+
+ value = text-value
+
+ ;For name="TZ"
+ param = ""
+ ; No parameters allowed
+
+ value = utc-offset-value
+
+ ;For name="GEO"
+ param = ""
+ ; No parameters allowed
+
+ value = float-value ";" float-value
+
+ ;For name="TITLE"
+ param = text-param
+ ; Only text parameters allowed
+
+ value = text-value
+
+ ;For name="ROLE"
+ param = text-param
+ ; Only text parameters allowed
+
+ value = text-value
+
+ ;For name="LOGO"
+
+
+
+Dawson & Howes Standards Track [Page 32]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ param = img-inline-param / img-refer-param
+ ; Only image parameters allowed
+
+ value = img-inline-value / img-refer-value
+ ; Value and parameter MUST match
+
+ ;For name="AGENT"
+ param = agent-inline-param
+
+ param =/ agent-refer-param
+
+ value = agent-inline-value
+ ; Value and parameter MUST match
+
+ value =/ agent-refer-value
+ ; Value and parameter MUST match
+
+ agent-inline-param = ""
+ ; No parameters allowed
+
+ agent-refer-param = "VALUE" "=" "uri"
+ ; Only value parameter allowed
+
+ agent-inline-value = text-value
+ ; Value MUST be a valid vCard object
+
+ agent-refer-value = uri
+ ; URI MUST refer to image content of given type
+
+ ;For name="ORG"
+
+ param = text-param
+ ; Only text parameters allowed
+
+ value = org-value
+
+ org-value = *(text-value ";") text-value
+ ; First is Organization Name, remainder are Organization Units.
+
+ ;For name="CATEGORIES"
+ param = text-param
+ ; Only text parameters allowed
+
+ value = text-list
+
+ ;For name="NOTE"
+ param = text-param
+ ; Only text parameters allowed
+
+
+
+Dawson & Howes Standards Track [Page 33]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ value = text-value
+
+ ;For name="PRODID"
+ param = ""
+ ; No parameters allowed
+
+ value = text-value
+
+ ;For name="REV"
+ param = ["VALUE" =" "date-time"]
+ ; Only value parameters allowed. Values are case insensitive.
+
+ param =/ "VALUE" =" "date"
+ ; Only value parameters allowed. Values are case insensitive.
+
+ value = date-time-value
+
+ value =/ date-value
+
+ ;For name="SORT-STRING"
+ param = text-param
+ ; Only text parameters allowed
+
+ value = text-value
+
+ ;For name="SOUND"
+ param = snd-inline-param
+ ; Only sound parameters allowed
+
+ param =/ snd-refer-param
+ ; Only sound parameters allowed
+
+ value = snd-line-value
+ ; Value MUST match value type
+
+ value =/ snd-refer-value
+ ; Value MUST match value type
+
+ snd-inline-value = binary-value CRLF
+ ; Value MUST be "b" encoded audio content
+
+ snd-inline-param = ("VALUE" "=" "binary"])
+ / ("ENCODING" "=" "b")
+ / ("TYPE" "=" *SAFE-CHAR)
+ ; Value MUST be an IANA registered audio type
+
+ snd-refer-value = uri
+ ; URI MUST refer to audio content of given type
+
+
+
+Dawson & Howes Standards Track [Page 34]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ snd-refer-param = ("VALUE" "=" "uri")
+ / ("TYPE" "=" word)
+ ; Value MUST be an IANA registered audio type
+
+ ;For name="UID"
+ param = ""
+ ; No parameters allowed
+
+ value = text-value
+
+ ;For name="URL"
+ param = ""
+ ; No parameters allowed
+
+ value = uri
+
+ ;For name="VERSION"
+ ;This type MUST be included in a vCard object.
+ param = ""
+ ; No parameters allowed
+
+ value = text-value
+ ; Value MUST be "3.0"
+
+ ;For name="CLASS"
+ param = ""
+ ; No parameters allowed
+
+ value = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL"
+ / iana-token / x-name
+ ; Value are case insensitive
+
+ ;For name="KEY"
+ param = key-txt-param
+ ; Only value and type parameters allowed
+
+ param =/ key-bin-param
+ ; Only value and type parameters allowed
+
+ value = text-value
+
+ value =/ binary-value
+
+ key-txt-param = "TYPE" "=" keytype
+
+ key-bin-param = ("TYPE" "=" keytype)
+ / ("ENCODING" "=" "b")
+ ; Value MUST be a "b" encoded key or certificate
+
+
+
+Dawson & Howes Standards Track [Page 35]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ keytype = "X509" / "PGP" / iana-token / x-name
+ ; Values are case insensitive
+
+ ;For name="X-" non-standard type
+ param = text-param / (x-name "=" param-value)
+ ; Only text or non-standard parameters allowed
+
+ value = text-value
+
+ ;*******************************************
+ ; vCard Commonly Used Parameter Definition
+ ;*******************************************
+
+ text-param = ("VALUE" "=" "ptext")
+ / ("LANGUAGE" "=" langval)
+ / (x-name "=" param-value)
+
+ langval = <a language string as defined in RFC 1766>
+
+ img-inline-value = binary-value
+ ;Value MUST be "b" encoded image content
+
+ img-inline-param
+
+ img-inline-param = ("VALUE" "=" "binary")
+ / ("ENCODING" "=" "b")
+ / ("TYPE" "=" param-value
+ ;TYPE value MUST be an IANA registered image type
+
+ img-refer-value = uri
+ ;URI MUST refer to image content of given type
+
+ img-refer-param = ("VALUE" "=" "uri")
+ / ("TYPE" "=" param-value)
+ ;TYPE value MUST be an IANA registered image type
+
+ adr-param = ("TYPE" "=" adr-type *("," adr-type))
+ / (text-param)
+
+ adr-type = "dom" / "intl" / "postal" / "parcel" / "home"
+ / "work" / "pref" / iana-type / x-name
+
+ adr-value = 0*6(text-value ";") text-value
+ ; PO Box, Extended Address, Street, Locality, Region, Postal
+ ; Code, Country Name
+
+
+
+
+
+
+Dawson & Howes Standards Track [Page 36]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ ;*******************************************
+ ; vCard Type Value Definition
+ ;*******************************************
+
+ text-value-list = 1*text-value *("," 1*text-value)
+
+ text-value = *(SAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)
+
+ ESCAPED-CHAR = "\\" / "\;" / "\," / "\n" / "\N")
+ ; \\ encodes \, \n or \N encodes newline
+ ; \; encodes ;, \, encodes ,
+
+ binary-value = <A "b" encoded text value as defined in [RFC 2047]>
+
+ date-value = <A single date value as defined in [MIME-DIR]>
+
+ time-value = <A single time value as defined in [MIME-DIR]>
+
+ date-time-value = <A single date-time value as defined in [MIME-DIR]
+
+ float-value = <A single float value as defined in [MIME-DIR]>
+
+ phone-number-value = <A single text value as defined in [CCITT
+ E.163] and [CCITT X.121]>
+
+ uri-value = <A uri value as defined in [MIME-DIR]>
+
+ utc-offset-value = ("+" / "-") time-hour ":" time-minute
+ time-hour = 2DIGIT ;00-23
+ time-minute = 2DIGIT ;00-59
+
+5. Differences From vCard v2.1
+
+ This specification has been reviewed by the IETF community. The
+ review process introduced a number of differences from the [VCARD]
+ version 2.1. These differences require that vCard objects conforming
+ to this specification have a different version number than a vCard
+ conforming to [VCARD]. The differences include the following:
+
+ . The QUOTED-PRINTABLE inline encoding has been eliminated.
+ Only the "B" encoding of [RFC 2047] is an allowed value for
+ the ENCODING parameter.
+
+ . The method for specifying CRLF character sequences in text
+ type values has been changed. The CRLF character sequence in
+ a text type value is specified with the backslash character
+ sequence "\n" or "\N".
+
+
+
+
+Dawson & Howes Standards Track [Page 37]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ . Any COMMA or SEMICOLON in a text type value must be backslash
+ escaped.
+
+ . VERSION value corresponding to this specification MUST be
+ "3.0".
+
+ . The [MIME-DIR] predefined types of SOURCE, NAME and PROFILE
+ are allowed.
+
+ . The [MIME-DIR] VALUE type parameter for value data typing is
+ allowed. In addition, there are extensions made to these type
+ values for additional value types used in this specification.
+
+ . The [VCARD] CHARSET type parameter has been eliminated.
+ Character set can only be specified on the CHARSET parameter
+ on the Content-Type MIME header field.
+
+ . The [VCARD] support for non-significant WSP character has
+ been eliminated.
+
+ . The "TYPE=" prefix to parameter values is required. In
+ [VCARD] this was optional.
+
+ . LOGO, PHOTO and SOUND multimedia formats MUST be either IANA
+ registered types or non-standard types.
+
+ . Inline binary content must be "B" encoded and folded. A blank
+ line after the encoded binary content is no longer required.
+
+ . TEL values can be identified as personal communication
+ services telephone numbers with the PCS type parameter value.
+
+ . The CATEGORIES, CLASS, NICKNAME, PRODID and SORT-STRING types
+ have been added.
+
+ . The VERSION, N and FN types MUST be specified in a vCard.
+ This identifies the version of the specification that the
+ object was formatted to. It also assures that every vCard
+ will include both a structured and formatted name that can be
+ used to identify the object.
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Howes Standards Track [Page 38]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+6. Acknowledgements
+
+ The many valuable comments contributed by members of the IETF ASID
+ working group are gratefully acknowledged, as are the contributions
+ by Roland Alden, Stephen Bartlett, Alec Dun, Patrik Faltstrom, Daniel
+ Gurney, Bruce Johnston, Daniel Klaussen, Pete Miller, Keith Moore,
+ Vinod Seraphin, Michelle Watkins. Chris Newman was especially helpful
+ in navigating the intricacies of ABNF lore.
+
+7. Authors' Addresses
+
+ BEGIN:vCard
+ VERSION:3.0
+ FN:Frank Dawson
+ ORG:Lotus Development Corporation
+ ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive
+ ;Raleigh;NC;27613-3502;U.S.A.
+ TEL;TYPE=VOICE,MSG,WORK:+1-919-676-9515
+ TEL;TYPE=FAX,WORK:+1-919-676-9564
+ EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
+ EMAIL;TYPE=INTERNET:fdawson@earthlink.net
+ URL:http://home.earthlink.net/~fdawson
+ END:vCard
+
+
+ BEGIN:vCard
+ VERSION:3.0
+ FN:Tim Howes
+ ORG:Netscape Communications Corp.
+ ADR;TYPE=WORK:;;501 E. Middlefield Rd.;Mountain View;
+ CA; 94043;U.S.A.
+ TEL;TYPE=VOICE,MSG,WORK:+1-415-937-3419
+ TEL;TYPE=FAX,WORK:+1-415-528-4164
+ EMAIL;TYPE=INTERNET:howes@netscape.com
+ END:vCard
+
+8. Security Considerations
+
+ vCards can carry cryptographic keys or certificates, as described in
+ Section 3.7.2.
+
+ Section 3.7.1 specifies a desired security classification policy for
+ a particular vCard. That policy is not enforced in any way.
+
+ The vCard objects have no inherent authentication or privacy, but can
+ easily be carried by any security mechanism that transfers MIME
+ objects with authentication or privacy. In cases where threats of
+ "spoofed" vCard information is a concern, the vCard SHOULD BE
+
+
+
+Dawson & Howes Standards Track [Page 39]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ transported using one of these secure mechanisms.
+
+ The information in a vCard may become out of date. In cases where the
+ vitality of data is important to an originator of a vCard, the "URL"
+ type described in section 3.6.8 SHOULD BE specified. In addition, the
+ "REV" type described in section 3.6.4 can be specified to indicate
+ the last time that the vCard data was updated.
+
+9. References
+
+ [ISO 8601] ISO 8601:1988 - Data elements and interchange formats -
+ Information interchange - Representation of dates and
+ times - The International Organization for
+ Standardization, June, 1988.
+
+ [ISO 8601 TC] ISO 8601, Technical Corrigendum 1 - Data elements and
+ interchange formats - Information interchange -
+ Representation of dates and times - The International
+ Organization for Standardization, May, 1991.
+
+ [ISO 9070] ISO 9070, Information Processing - SGML support
+ facilities - Registration Procedures for Public Text
+ Owner Identifiers, April, 1991.
+
+ [CCITT E.163] Recommendation E.163 - Numbering Plan for The
+ International Telephone Service, CCITT Blue Book,
+ Fascicle II.2, pp. 128-134, November, 1988.
+
+ [CCITT X.121] Recommendation X.121 - International Numbering Plan for
+ Public Data Networks, CCITT Blue Book, Fascicle VIII.3,
+ pp. 317-332, November, 1988.
+
+ [CCITT X.520] Recommendation X.520 - The Directory - Selected
+ Attribute Types, November 1988.
+
+ [CCITT X.521] Recommendation X.521 - The Directory - Selected Object
+ Classes, November 1988.
+
+ [MIME-DIR] Howes, T., Smith, M., and F. Dawson, "A MIME Content-
+ Type for Directory Information", RFC 2425, September
+ 1998.
+
+ [RFC 1738] Berners-Lee, T., Masinter, L., and M. McCahill,
+ "Uniform Resource Locators (URL)", RFC 1738, December
+ 1994.
+
+ [RFC 1766] Alvestrand, H., "Tags for the Identification of
+ Languages", RFC 1766, March 1995.
+
+
+
+Dawson & Howes Standards Track [Page 40]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+ [RFC 1872] Levinson, E., "The MIME Multipart/Related Content-
+ type", RFC 1872, December 1995.
+
+ [RFC 2045] Freed, N., and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) - Part One: Format of Internet
+ Message Bodies", RFC 2045, November 1996.
+
+ [RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet
+ Mail Extensions (MIME) - Part Two: Media Types", RFC
+ 2046, November 1996.
+
+ [RFC 2047] Moore, K., "Multipurpose Internet Mail Extensions
+ (MIME) - Part Three: Message Header Extensions for
+ Non-ASCII Text", RFC 2047, November 1996.
+
+ [RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
+ Internet Mail Extensions (MIME) - Part Four:
+ Registration Procedures", RFC 2048, January 1997.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC 2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [UNICODE] "The Unicode Standard - Version 2.0", The Unicode
+ Consortium, July 1996.
+
+ [VCARD] Internet Mail Consortium, "vCard - The Electronic
+ Business Card Version 2.1",
+ http://www.imc.org/pdi/vcard-21.txt, September 18,
+ 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Howes Standards Track [Page 41]
+
+RFC 2426 vCard MIME Directory Profile September 1998
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Howes Standards Track [Page 42]
+
diff --git a/docs/rfcs/rfc6350.txt b/docs/rfcs/rfc6350.txt
new file mode 100644
index 0000000..d853cbc
--- /dev/null
+++ b/docs/rfcs/rfc6350.txt
@@ -0,0 +1,4147 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Perreault
+Request for Comments: 6350 Viagenie
+Obsoletes: 2425, 2426, 4770 August 2011
+Updates: 2739
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ vCard Format Specification
+
+Abstract
+
+ This document defines the vCard data format for representing and
+ exchanging a variety of information about individuals and other
+ entities (e.g., formatted and structured name and delivery addresses,
+ email address, multiple telephone numbers, photograph, logo, audio
+ clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and
+ updates RFC 2739.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6350.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Perreault Standards Track [Page 1]
+
+RFC 6350 vCard August 2011
+
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. vCard Format Specification . . . . . . . . . . . . . . . . . . 5
+ 3.1. Charset . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Line Delimiting and Folding . . . . . . . . . . . . . . . 5
+ 3.3. ABNF Format Definition . . . . . . . . . . . . . . . . . . 6
+ 3.4. Property Value Escaping . . . . . . . . . . . . . . . . . 9
+ 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 9
+ 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 12
+ 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 13
+ 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14
+ 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.7. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 4.8. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16
+ 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 5.7. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.8. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 5.9. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 5.10. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 5.11. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+
+
+
+
+Perreault Standards Track [Page 2]
+
+RFC 6350 vCard August 2011
+
+
+ 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 23
+ 6.1. General Properties . . . . . . . . . . . . . . . . . . . . 23
+ 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 27
+ 6.2. Identification Properties . . . . . . . . . . . . . . . . 28
+ 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+ 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 29
+ 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 31
+ 6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 32
+ 6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 32
+ 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 32
+ 6.4. Communications Properties . . . . . . . . . . . . . . . . 34
+ 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 34
+ 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 36
+ 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 36
+ 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 37
+ 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 37
+ 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 37
+ 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 38
+ 6.6. Organizational Properties . . . . . . . . . . . . . . . . 39
+ 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 39
+ 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 39
+ 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 40
+ 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 40
+ 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 41
+ 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 42
+ 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 43
+ 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 43
+ 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 44
+ 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 44
+ 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 45
+ 6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 45
+ 6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 46
+ 6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 47
+ 6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 47
+ 6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 48
+ 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 48
+ 6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 48
+ 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 49
+ 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 49
+ 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 50
+ 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 50
+
+
+
+Perreault Standards Track [Page 3]
+
+RFC 6350 vCard August 2011
+
+
+ 6.10. Extended Properties and Parameters . . . . . . . . . . . . 51
+ 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 51
+ 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 51
+ 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 51
+ 7.1.2. Matching Property Instances . . . . . . . . . . . . . 52
+ 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 52
+ 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 53
+ 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 53
+ 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 53
+ 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 54
+ 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 54
+ 7.2.5. Global Context Simplification . . . . . . . . . . . . 56
+ 8. Example: Author's vCard . . . . . . . . . . . . . . . . . . . 56
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
+ 10.1. Media Type Registration . . . . . . . . . . . . . . . . . 58
+ 10.2. Registering New vCard Elements . . . . . . . . . . . . . . 59
+ 10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 59
+ 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 60
+ 10.2.3. Registration Template for Properties . . . . . . . . . 61
+ 10.2.4. Registration Template for Parameters . . . . . . . . . 61
+ 10.2.5. Registration Template for Value Data Types . . . . . . 62
+ 10.2.6. Registration Template for Values . . . . . . . . . . . 62
+ 10.3. Initial vCard Elements Registries . . . . . . . . . . . . 63
+ 10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 64
+ 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 65
+ 10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 65
+ 10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 66
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 69
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 71
+ Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 73
+ A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 73
+ A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 73
+ A.3. New Properties and Parameters . . . . . . . . . . . . . . 73
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 4]
+
+RFC 6350 vCard August 2011
+
+
+1. Introduction
+
+ Electronic address books have become ubiquitous. Their increased
+ presence on portable, connected devices as well as the diversity of
+ platforms that exchange contact data call for a standard. This memo
+ defines the vCard format, which allows the capture and exchange of
+ information normally stored within an address book or directory
+ application.
+
+ A high-level overview of the differences from RFCs 2425 and 2426 can
+ be found in Appendix A.
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+3. vCard Format Specification
+
+ The text/vcard MIME content type (hereafter known as "vCard"; see
+ Section 10.1) contains contact information, typically pertaining to a
+ single contact or group of contacts. The content consists of one or
+ more lines in the format given below.
+
+3.1. Charset
+
+ The charset (see [RFC3536] for internationalization terminology) for
+ vCard is UTF-8 as defined in [RFC3629]. There is no way to override
+ this. It is invalid to specify a value other than "UTF-8" in the
+ "charset" MIME parameter (see Section 10.1).
+
+3.2. Line Delimiting and Folding
+
+ Individual lines within vCard are delimited by the [RFC5322] line
+ break, which is a CRLF sequence (U+000D followed by U+000A). Long
+ logical lines of text can be split into a multiple-physical-line
+ representation using the following folding technique. Content lines
+ SHOULD be folded to a maximum width of 75 octets, excluding the line
+ break. Multi-octet characters MUST remain contiguous. The rationale
+ for this folding process can be found in [RFC5322], Section 2.1.1.
+
+ A logical line MAY be continued on the next physical line anywhere
+ between two characters by inserting a CRLF immediately followed by a
+ single white space character (space (U+0020) or horizontal tab
+ (U+0009)). The folded line MUST contain at least one character. Any
+ sequence of CRLF followed immediately by a single white space
+
+
+
+Perreault Standards Track [Page 5]
+
+RFC 6350 vCard August 2011
+
+
+ character is ignored (removed) when processing the content type. For
+ example, the line:
+
+ NOTE:This is a long description that exists on a long line.
+
+ can be represented as:
+
+ NOTE:This is a long description
+ that exists on a long line.
+
+ It could also be represented as:
+
+ NOTE:This is a long descrip
+ tion that exists o
+ n a long line.
+
+ The process of moving from this folded multiple-line representation
+ of a property definition to its single-line representation is called
+ unfolding. Unfolding is accomplished by regarding CRLF immediately
+ followed by a white space character (namely, HTAB (U+0009) or SPACE
+ (U+0020)) as equivalent to no characters at all (i.e., the CRLF and
+ single white space character are removed).
+
+ Note: It is possible for very simple implementations to generate
+ improperly folded lines in the middle of a UTF-8 multi-octet
+ sequence. For this reason, implementations SHOULD unfold lines in
+ such a way as to properly restore the original sequence.
+
+ Note: Unfolding is done differently than in [RFC5322]. Unfolding
+ in [RFC5322] only removes the CRLF, not the space following it.
+
+ Folding is done after any content encoding of a type value.
+ Unfolding is done before any decoding of a type value in a content
+ line.
+
+3.3. ABNF Format Definition
+
+ The following ABNF uses the notation of [RFC5234], which also defines
+ CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT.
+
+ vcard-entity = 1*vcard
+
+ vcard = "BEGIN:VCARD" CRLF
+ "VERSION:4.0" CRLF
+ 1*contentline
+ "END:VCARD" CRLF
+ ; A vCard object MUST include the VERSION and FN properties.
+ ; VERSION MUST come immediately after BEGIN:VCARD.
+
+
+
+Perreault Standards Track [Page 6]
+
+RFC 6350 vCard August 2011
+
+
+ contentline = [group "."] name *(";" param) ":" value CRLF
+ ; When parsing a content line, folded lines must first
+ ; be unfolded according to the unfolding procedure
+ ; described in Section 3.2.
+ ; When generating a content line, lines longer than 75
+ ; characters SHOULD be folded according to the folding
+ ; procedure described in Section 3.2.
+
+ group = 1*(ALPHA / DIGIT / "-")
+ name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME"
+ / "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / "TEL"
+ / "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE"
+ / "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES"
+ / "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP"
+ / "URL" / "KEY" / "FBURL" / "CALADRURI" / "CALURI" / "XML"
+ / iana-token / x-name
+ ; Parsing of the param and value is based on the "name" as
+ ; defined in ABNF sections below.
+ ; Group and name are case-insensitive.
+
+ iana-token = 1*(ALPHA / DIGIT / "-")
+ ; identifier registered with IANA
+
+ x-name = "x-" 1*(ALPHA / DIGIT / "-")
+ ; Names that begin with "x-" or "X-" are
+ ; reserved for experimental use, not intended for released
+ ; products, or for use in bilateral agreements.
+
+ param = language-param / value-param / pref-param / pid-param
+ / type-param / geo-parameter / tz-parameter / sort-as-param
+ / calscale-param / any-param
+ ; Allowed parameters depend on property name.
+
+ param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE
+
+ any-param = (iana-token / x-name) "=" param-value *("," param-value)
+
+ NON-ASCII = UTF8-2 / UTF8-3 / UTF8-4
+ ; UTF8-{2,3,4} are defined in [RFC3629]
+
+ QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII
+ ; Any character except CTLs, DQUOTE
+
+ SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII
+ ; Any character except CTLs, DQUOTE, ";", ":"
+
+ VALUE-CHAR = WSP / VCHAR / NON-ASCII
+ ; Any textual character
+
+
+
+Perreault Standards Track [Page 7]
+
+RFC 6350 vCard August 2011
+
+
+ A line that begins with a white space character is a continuation of
+ the previous line, as described in Section 3.2. The white space
+ character and immediately preceeding CRLF should be discarded when
+ reconstructing the original line. Note that this line-folding
+ convention differs from that found in [RFC5322], in that the sequence
+ <CRLF><WSP> found anywhere in the content indicates a continued line
+ and should be removed.
+
+ Property names and parameter names are case-insensitive (e.g., the
+ property name "fn" is the same as "FN" and "Fn"). Parameter values
+ MAY be case-sensitive or case-insensitive, depending on their
+ definition. Parameter values that are not explicitly defined as
+ being case-sensitive are case-insensitive. Based on experience with
+ vCard 3 interoperability, it is RECOMMENDED that property and
+ parameter names be upper-case on output.
+
+ The group construct is used to group related properties together.
+ The group name is a syntactic convention used to indicate that all
+ property names prefaced with the same group name SHOULD be grouped
+ together when displayed by an application. It has no other
+ significance. Implementations that do not understand or support
+ grouping MAY simply strip off any text before a "." to the left of
+ the type name and present the types and values as normal.
+
+ Property cardinalities are indicated using the following notation,
+ which is based on ABNF (see [RFC5234], Section 3.6):
+
+ +-------------+--------------------------------------------------+
+ | Cardinality | Meaning |
+ +-------------+--------------------------------------------------+
+ | 1 | Exactly one instance per vCard MUST be present. |
+ | *1 | Exactly one instance per vCard MAY be present. |
+ | 1* | One or more instances per vCard MUST be present. |
+ | * | One or more instances per vCard MAY be present. |
+ +-------------+--------------------------------------------------+
+
+ Properties defined in a vCard instance may have multiple values
+ depending on the property cardinality. The general rule for encoding
+ multi-valued properties is to simply create a new content line for
+ each value (including the property name). However, it should be
+ noted that some value types support encoding multiple values in a
+ single content line by separating the values with a comma ",". This
+ approach has been taken for several of the content types defined
+ below (date, time, integer, float).
+
+
+
+
+
+
+
+Perreault Standards Track [Page 8]
+
+RFC 6350 vCard August 2011
+
+
+3.4. Property Value Escaping
+
+ Some properties may contain one or more values delimited by a COMMA
+ character (U+002C). Therefore, a COMMA character in a value MUST be
+ escaped with a BACKSLASH character (U+005C), even for properties that
+ don't allow multiple instances (for consistency).
+
+ Some properties (e.g., N and ADR) comprise multiple fields delimited
+ by a SEMICOLON character (U+003B). Therefore, a SEMICOLON in a field
+ of such a "compound" property MUST be escaped with a BACKSLASH
+ character. SEMICOLON characters in non-compound properties MAY be
+ escaped. On input, an escaped SEMICOLON character is never a field
+ separator. An unescaped SEMICOLON character may be a field
+ separator, depending on the property in which it appears.
+
+ Furthermore, some fields of compound properties may contain a list of
+ values delimited by a COMMA character. Therefore, a COMMA character
+ in one of a field's values MUST be escaped with a BACKSLASH
+ character, even for fields that don't allow multiple values (for
+ consistency). Compound properties allowing multiple instances MUST
+ NOT be encoded in a single content line.
+
+ Finally, BACKSLASH characters in values MUST be escaped with a
+ BACKSLASH character. NEWLINE (U+000A) characters in values MUST be
+ encoded by two characters: a BACKSLASH followed by either an 'n'
+ (U+006E) or an 'N' (U+004E).
+
+ In all other cases, escaping MUST NOT be used.
+
+4. Property Value Data Types
+
+ Standard value types are defined below.
+
+ value = text
+ / text-list
+ / date-list
+ / time-list
+ / date-time-list
+ / date-and-or-time-list
+ / timestamp-list
+ / boolean
+ / integer-list
+ / float-list
+ / URI ; from Section 3 of [RFC3986]
+ / utc-offset
+ / Language-Tag
+ / iana-valuespec
+ ; Actual value type depends on property name and VALUE parameter.
+
+
+
+Perreault Standards Track [Page 9]
+
+RFC 6350 vCard August 2011
+
+
+ text = *TEXT-CHAR
+
+ TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII
+ / %x21-2B / %x2D-5B / %x5D-7E
+ ; Backslashes, commas, and newlines must be encoded.
+
+ component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII
+ / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E
+ list-component = component *("," component)
+
+ text-list = text *("," text)
+ date-list = date *("," date)
+ time-list = time *("," time)
+ date-time-list = date-time *("," date-time)
+ date-and-or-time-list = date-and-or-time *("," date-and-or-time)
+ timestamp-list = timestamp *("," timestamp)
+ integer-list = integer *("," integer)
+ float-list = float *("," float)
+
+ boolean = "TRUE" / "FALSE"
+ integer = [sign] 1*DIGIT
+ float = [sign] 1*DIGIT ["." 1*DIGIT]
+
+ sign = "+" / "-"
+
+ year = 4DIGIT ; 0000-9999
+ month = 2DIGIT ; 01-12
+ day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year
+ hour = 2DIGIT ; 00-23
+ minute = 2DIGIT ; 00-59
+ second = 2DIGIT ; 00-58/59/60 depending on leap second
+ zone = utc-designator / utc-offset
+ utc-designator = %x5A ; uppercase "Z"
+
+ date = year [month day]
+ / year "-" month
+ / "--" month [day]
+ / "--" "-" day
+ date-noreduc = year month day
+ / "--" month day
+ / "--" "-" day
+ date-complete = year month day
+
+ time = hour [minute [second]] [zone]
+ / "-" minute [second] [zone]
+ / "-" "-" second [zone]
+ time-notrunc = hour [minute [second]] [zone]
+ time-complete = hour minute second [zone]
+
+
+
+Perreault Standards Track [Page 10]
+
+RFC 6350 vCard August 2011
+
+
+ time-designator = %x54 ; uppercase "T"
+ date-time = date-noreduc time-designator time-notrunc
+ timestamp = date-complete time-designator time-complete
+
+ date-and-or-time = date-time / date / time-designator time
+
+ utc-offset = sign hour [minute]
+
+ Language-Tag = <Language-Tag, defined in [RFC5646], Section 2.1>
+
+ iana-valuespec = <value-spec, see Section 12>
+ ; a publicly defined valuetype format, registered
+ ; with IANA, as defined in Section 12 of this
+ ; document.
+
+4.1. TEXT
+
+ "text": The "text" value type should be used to identify values that
+ contain human-readable text. As for the language, it is controlled
+ by the LANGUAGE property parameter defined in Section 5.1.
+
+ Examples for "text":
+
+ this is a text value
+ this is one value,this is another
+ this is a single value\, with a comma encoded
+
+ A formatted text line break in a text value type MUST be represented
+ as the character sequence backslash (U+005C) followed by a Latin
+ small letter n (U+006E) or a Latin capital letter N (U+004E), that
+ is, "\n" or "\N".
+
+ For example, a multiple line NOTE value of:
+
+ Mythical Manager
+ Hyjinx Software Division
+ BabsCo, Inc.
+
+ could be represented as:
+
+ NOTE:Mythical Manager\nHyjinx Software Division\n
+ BabsCo\, Inc.\n
+
+ demonstrating the \n literal formatted line break technique, the
+ CRLF-followed-by-space line folding technique, and the backslash
+ escape technique.
+
+
+
+
+
+Perreault Standards Track [Page 11]
+
+RFC 6350 vCard August 2011
+
+
+4.2. URI
+
+ "uri": The "uri" value type should be used to identify values that
+ are referenced by a Uniform Resource Identifier (URI) instead of
+ encoded in-line. These value references might be used if the value
+ is too large, or otherwise undesirable to include directly. The
+ format for the URI is as defined in Section 3 of [RFC3986]. Note
+ that the value of a property of type "uri" is what the URI points to,
+ not the URI itself.
+
+ Examples for "uri":
+
+ http://www.example.com/my/picture.jpg
+ ldap://ldap.example.com/cn=babs%20jensen
+
+4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP
+
+ "date", "time", "date-time", "date-and-or-time", and "timestamp":
+ Each of these value types is based on the definitions in
+ [ISO.8601.2004]. Multiple such values can be specified using the
+ comma-separated notation.
+
+ Only the basic format is supported.
+
+4.3.1. DATE
+
+ A calendar date as specified in [ISO.8601.2004], Section 4.1.2.
+
+ Reduced accuracy, as specified in [ISO.8601.2004], Sections 4.1.2.3
+ a) and b), but not c), is permitted.
+
+ Expanded representation, as specified in [ISO.8601.2004], Section
+ 4.1.4, is forbidden.
+
+ Truncated representation, as specified in [ISO.8601.2000], Sections
+ 5.2.1.3 d), e), and f), is permitted.
+
+ Examples for "date":
+
+ 19850412
+ 1985-04
+ 1985
+ --0412
+ ---12
+
+
+
+
+
+
+
+Perreault Standards Track [Page 12]
+
+RFC 6350 vCard August 2011
+
+
+ Note the use of YYYY-MM in the second example above. YYYYMM is
+ disallowed to prevent confusion with YYMMDD. Note also that
+ YYYY-MM-DD is disallowed since we are using the basic format instead
+ of the extended format.
+
+4.3.2. TIME
+
+ A time of day as specified in [ISO.8601.2004], Section 4.2.
+
+ Reduced accuracy, as specified in [ISO.8601.2004], Section 4.2.2.3,
+ is permitted.
+
+ Representation with decimal fraction, as specified in
+ [ISO.8601.2004], Section 4.2.2.4, is forbidden.
+
+ The midnight hour is always represented by 00, never 24 (see
+ [ISO.8601.2004], Section 4.2.3).
+
+ Truncated representation, as specified in [ISO.8601.2000], Sections
+ 5.3.1.4 a), b), and c), is permitted.
+
+ Examples for "time":
+
+ 102200
+ 1022
+ 10
+ -2200
+ --00
+ 102200Z
+ 102200-0800
+
+4.3.3. DATE-TIME
+
+ A date and time of day combination as specified in [ISO.8601.2004],
+ Section 4.3.
+
+ Truncation of the date part, as specified in [ISO.8601.2000], Section
+ 5.4.2 c), is permitted.
+
+ Examples for "date-time":
+
+ 19961022T140000
+ --1022T1400
+ ---22T14
+
+
+
+
+
+
+
+Perreault Standards Track [Page 13]
+
+RFC 6350 vCard August 2011
+
+
+4.3.4. DATE-AND-OR-TIME
+
+ Either a DATE-TIME, a DATE, or a TIME value. To allow unambiguous
+ interpretation, a stand-alone TIME value is always preceded by a "T".
+
+ Examples for "date-and-or-time":
+
+ 19961022T140000
+ --1022T1400
+ ---22T14
+ 19850412
+ 1985-04
+ 1985
+ --0412
+ ---12
+ T102200
+ T1022
+ T10
+ T-2200
+ T--00
+ T102200Z
+ T102200-0800
+
+4.3.5. TIMESTAMP
+
+ A complete date and time of day combination as specified in
+ [ISO.8601.2004], Section 4.3.2.
+
+ Examples for "timestamp":
+
+ 19961022T140000
+ 19961022T140000Z
+ 19961022T140000-05
+ 19961022T140000-0500
+
+4.4. BOOLEAN
+
+ "boolean": The "boolean" value type is used to express boolean
+ values. These values are case-insensitive.
+
+ Examples:
+
+ TRUE
+ false
+ True
+
+
+
+
+
+
+Perreault Standards Track [Page 14]
+
+RFC 6350 vCard August 2011
+
+
+4.5. INTEGER
+
+ "integer": The "integer" value type is used to express signed
+ integers in decimal format. If sign is not specified, the value is
+ assumed positive "+". Multiple "integer" values can be specified
+ using the comma-separated notation. The maximum value is
+ 9223372036854775807, and the minimum value is -9223372036854775808.
+ These limits correspond to a signed 64-bit integer using two's-
+ complement arithmetic.
+
+ Examples:
+
+ 1234567890
+ -1234556790
+ +1234556790,432109876
+
+4.6. FLOAT
+
+ "float": The "float" value type is used to express real numbers. If
+ sign is not specified, the value is assumed positive "+". Multiple
+ "float" values can be specified using the comma-separated notation.
+ Implementations MUST support a precision equal or better than that of
+ the IEEE "binary64" format [IEEE.754.2008].
+
+ Note: Scientific notation is disallowed. Implementers wishing to
+ use their favorite language's %f formatting should be careful.
+
+ Examples:
+
+ 20.30
+ 1000000.0000001
+ 1.333,3.14
+
+4.7. UTC-OFFSET
+
+ "utc-offset": The "utc-offset" value type specifies that the property
+ value is a signed offset from UTC. This value type can be specified
+ in the TZ property.
+
+ The value type is an offset from Coordinated Universal Time (UTC).
+ It is specified as a positive or negative difference in units of
+ hours and minutes (e.g., +hhmm). The time is specified as a 24-hour
+ clock. Hour values are from 00 to 23, and minute values are from 00
+ to 59. Hour and minutes are 2 digits with high-order zeroes required
+ to maintain digit count. The basic format for ISO 8601 UTC offsets
+ MUST be used.
+
+
+
+
+
+Perreault Standards Track [Page 15]
+
+RFC 6350 vCard August 2011
+
+
+4.8. LANGUAGE-TAG
+
+ "language-tag": A single language tag, as defined in [RFC5646].
+
+5. Property Parameters
+
+ A property can have attributes associated with it. These "property
+ parameters" contain meta-information about the property or the
+ property value. In some cases, the property parameter can be multi-
+ valued in which case the property parameter value elements are
+ separated by a COMMA (U+002C).
+
+ Property parameter value elements that contain the COLON (U+003A),
+ SEMICOLON (U+003B), or COMMA (U+002C) character separators MUST be
+ specified as quoted-string text values. Property parameter values
+ MUST NOT contain the DQUOTE (U+0022) character. The DQUOTE character
+ is used as a delimiter for parameter values that contain restricted
+ characters or URI text.
+
+ Applications MUST ignore x-param and iana-param values they don't
+ recognize.
+
+5.1. LANGUAGE
+
+ The LANGUAGE property parameter is used to identify data in multiple
+ languages. There is no concept of "default" language, except as
+ specified by any "Content-Language" MIME header parameter that is
+ present [RFC3282]. The value of the LANGUAGE property parameter is a
+ language tag as defined in Section 2 of [RFC5646].
+
+ Examples:
+
+ ROLE;LANGUAGE=tr:hoca
+
+ ABNF:
+
+ language-param = "LANGUAGE=" Language-Tag
+ ; Language-Tag is defined in section 2.1 of RFC 5646
+
+5.2. VALUE
+
+ The VALUE parameter is OPTIONAL, used to identify the value type
+ (data type) and format of the value. The use of these predefined
+ formats is encouraged even if the value parameter is not explicitly
+ used. By defining a standard set of value types and their formats,
+ existing parsing and processing code can be leveraged. The
+
+
+
+
+
+Perreault Standards Track [Page 16]
+
+RFC 6350 vCard August 2011
+
+
+ predefined data type values MUST NOT be repeated in COMMA-separated
+ value lists except within the N, NICKNAME, ADR, and CATEGORIES
+ properties.
+
+ ABNF:
+
+ value-param = "VALUE=" value-type
+
+ value-type = "text"
+ / "uri"
+ / "date"
+ / "time"
+ / "date-time"
+ / "date-and-or-time"
+ / "timestamp"
+ / "boolean"
+ / "integer"
+ / "float"
+ / "utc-offset"
+ / "language-tag"
+ / iana-token ; registered as described in section 12
+ / x-name
+
+5.3. PREF
+
+ The PREF parameter is OPTIONAL and is used to indicate that the
+ corresponding instance of a property is preferred by the vCard
+ author. Its value MUST be an integer between 1 and 100 that
+ quantifies the level of preference. Lower values correspond to a
+ higher level of preference, with 1 being most preferred.
+
+ When the parameter is absent, the default MUST be to interpret the
+ property instance as being least preferred.
+
+ Note that the value of this parameter is to be interpreted only in
+ relation to values assigned to other instances of the same property
+ in the same vCard. A given value, or the absence of a value, MUST
+ NOT be interpreted on its own.
+
+ This parameter MAY be applied to any property that allows multiple
+ instances.
+
+ ABNF:
+
+ pref-param = "PREF=" (1*2DIGIT / "100")
+ ; An integer between 1 and 100.
+
+
+
+
+
+Perreault Standards Track [Page 17]
+
+RFC 6350 vCard August 2011
+
+
+5.4. ALTID
+
+ The ALTID parameter is used to "tag" property instances as being
+ alternative representations of the same logical property. For
+ example, translations of a property in multiple languages generates
+ multiple property instances having different LANGUAGE (Section 5.1)
+ parameter that are tagged with the same ALTID value.
+
+ This parameter's value is treated as an opaque string. Its sole
+ purpose is to be compared for equality against other ALTID parameter
+ values.
+
+ Two property instances are considered alternative representations of
+ the same logical property if and only if their names as well as the
+ value of their ALTID parameters are identical. Property instances
+ without the ALTID parameter MUST NOT be considered an alternative
+ representation of any other property instance. Values for the ALTID
+ parameter are not globally unique: they MAY be reused for different
+ property names.
+
+ Property instances having the same ALTID parameter value count as 1
+ toward cardinality. Therefore, since N (Section 6.2.2) has
+ cardinality *1 and TITLE (Section 6.6.1) has cardinality *, these
+ three examples would be legal:
+
+ N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
+ N;ALTID=1;LANGUAGE=en:Yamada;Taro;;;
+ (<U+XXXX> denotes a UTF8-encoded Unicode character.)
+
+ TITLE;ALTID=1;LANGUAGE=fr:Patron
+ TITLE;ALTID=1;LANGUAGE=en:Boss
+
+ TITLE;ALTID=1;LANGUAGE=fr:Patron
+ TITLE;ALTID=1;LANGUAGE=en:Boss
+ TITLE;ALTID=2;LANGUAGE=en:Chief vCard Evangelist
+
+ while this one would not:
+
+ N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
+ N:Yamada;Taro;;;
+ (Two instances of the N property.)
+
+ and these three would be legal but questionable:
+
+ TITLE;ALTID=1;LANGUAGE=fr:Patron
+ TITLE;ALTID=2;LANGUAGE=en:Boss
+ (Should probably have the same ALTID value.)
+
+
+
+
+Perreault Standards Track [Page 18]
+
+RFC 6350 vCard August 2011
+
+
+ TITLE;ALTID=1;LANGUAGE=fr:Patron
+ TITLE:LANGUAGE=en:Boss
+ (Second line should probably have ALTID=1.)
+
+ N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
+ N;ALTID=1;LANGUAGE=en:Yamada;Taro;;;
+ N;ALTID=1;LANGUAGE=en:Smith;John;;;
+ (The last line should probably have ALTID=2. But that would be
+ illegal because N has cardinality *1.)
+
+ The ALTID property MAY also be used in may contexts other than with
+ the LANGUAGE parameter. Here's an example with two representations
+ of the same photo in different file formats:
+
+ PHOTO;ALTID=1:data:image/jpeg;base64,...
+ PHOTO;ALTID=1;data:image/jp2;base64,...
+
+ ABNF:
+
+ altid-param = "ALTID=" param-value
+
+5.5. PID
+
+ The PID parameter is used to identify a specific property among
+ multiple instances. It plays a role analogous to the UID property
+ (Section 6.7.6) on a per-property instead of per-vCard basis. It MAY
+ appear more than once in a given property. It MUST NOT appear on
+ properties that may have only one instance per vCard. Its value is
+ either a single small positive integer or a pair of small positive
+ integers separated by a dot. Multiple values may be encoded in a
+ single PID parameter by separating the values with a comma ",". See
+ Section 7 for more details on its usage.
+
+ ABNF:
+
+ pid-param = "PID=" pid-value *("," pid-value)
+ pid-value = 1*DIGIT ["." 1*DIGIT]
+
+5.6. TYPE
+
+ The TYPE parameter has multiple, different uses. In general, it is a
+ way of specifying class characteristics of the associated property.
+ Most of the time, its value is a comma-separated subset of a
+ predefined enumeration. In this document, the following properties
+ make use of this parameter: FN, NICKNAME, PHOTO, ADR, TEL, EMAIL,
+ IMPP, LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES,
+
+
+
+
+
+Perreault Standards Track [Page 19]
+
+RFC 6350 vCard August 2011
+
+
+ NOTE, SOUND, URL, KEY, FBURL, CALADRURI, and CALURI. The TYPE
+ parameter MUST NOT be applied on other properties defined in this
+ document.
+
+ The "work" and "home" values act like tags. The "work" value implies
+ that the property is related to an individual's work place, while the
+ "home" value implies that the property is related to an individual's
+ personal life. When neither "work" nor "home" is present, it is
+ implied that the property is related to both an individual's work
+ place and personal life in the case that the KIND property's value is
+ "individual", or to none in other cases.
+
+ ABNF:
+
+ type-param = "TYPE=" type-value *("," type-value)
+
+ type-value = "work" / "home" / type-param-tel
+ / type-param-related / iana-token / x-name
+ ; This is further defined in individual property sections.
+
+5.7. MEDIATYPE
+
+ The MEDIATYPE parameter is used with properties whose value is a URI.
+ Its use is OPTIONAL. It provides a hint to the vCard consumer
+ application about the media type [RFC2046] of the resource identified
+ by the URI. Some URI schemes do not need this parameter. For
+ example, the "data" scheme allows the media type to be explicitly
+ indicated as part of the URI [RFC2397]. Another scheme, "http",
+ provides the media type as part of the URI resolution process, with
+ the Content-Type HTTP header [RFC2616]. The MEDIATYPE parameter is
+ intended to be used with URI schemes that do not provide such
+ functionality (e.g., "ftp" [RFC1738]).
+
+ ABNF:
+
+ mediatype-param = "MEDIATYPE=" mediatype
+ mediatype = type-name "/" subtype-name *( ";" attribute "=" value )
+ ; "attribute" and "value" are from [RFC2045]
+ ; "type-name" and "subtype-name" are from [RFC4288]
+
+5.8. CALSCALE
+
+ The CALSCALE parameter is identical to the CALSCALE property in
+ iCalendar (see [RFC5545], Section 3.7.1). It is used to define the
+ calendar system in which a date or date-time value is expressed. The
+ only value specified by iCalendar is "gregorian", which stands for
+ the Gregorian system. It is the default when the parameter is
+ absent. Additional values may be defined in extension documents and
+
+
+
+Perreault Standards Track [Page 20]
+
+RFC 6350 vCard August 2011
+
+
+ registered with IANA (see Section 10.3.4). A vCard implementation
+ MUST ignore properties with a CALSCALE parameter value that it does
+ not understand.
+
+ ABNF:
+
+ calscale-param = "CALSCALE=" calscale-value
+
+ calscale-value = "gregorian" / iana-token / x-name
+
+5.9. SORT-AS
+
+ The "sort-as" parameter is used to specify the string to be used for
+ national-language-specific sorting. Without this information,
+ sorting algorithms could incorrectly sort this vCard within a
+ sequence of sorted vCards. When this property is present in a vCard,
+ then the given strings are used for sorting the vCard.
+
+ This parameter's value is a comma-separated list that MUST have as
+ many or fewer elements as the corresponding property value has
+ components. This parameter's value is case-sensitive.
+
+ ABNF:
+
+ sort-as-param = "SORT-AS=" sort-as-value
+
+ sort-as-value = param-value *("," param-value)
+
+ Examples: For the case of surname and given name sorting, the
+ following examples define common sort string usage with the N
+ property.
+
+ FN:Rene van der Harten
+ N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N.
+
+ FN:Robert Pau Shou Chang
+ N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;;
+
+ FN:Osamu Koura
+ N;SORT-AS="Koura,Osamu":Koura;Osamu;;
+
+ FN:Oscar del Pozo
+ N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;;
+
+ FN:Chistine d'Aboville
+ N;SORT-AS="Aboville,Christine":d'Aboville;Christine;;
+
+
+
+
+
+Perreault Standards Track [Page 21]
+
+RFC 6350 vCard August 2011
+
+
+ FN:H. James de Mann
+ N;SORT-AS="Mann,James":de Mann;Henry,James;;
+
+ If sorted by surname, the results would be:
+
+ Christine d'Aboville
+ Rene van der Harten
+ Osamu Koura
+ H. James de Mann
+ Robert Pau Shou Chang
+ Oscar del Pozo
+
+ If sorted by given name, the results would be:
+
+ Christine d'Aboville
+ H. James de Mann
+ Osamu Koura
+ Oscar del Pozo
+ Rene van der Harten
+ Robert Pau Shou Chang
+
+5.10. GEO
+
+ The GEO parameter can be used to indicate global positioning
+ information that is specific to an address. Its value is the same as
+ that of the GEO property (see Section 6.5.2).
+
+ ABNF:
+
+ geo-parameter = "GEO=" DQUOTE URI DQUOTE
+
+5.11. TZ
+
+ The TZ parameter can be used to indicate time zone information that
+ is specific to an address. Its value is the same as that of the TZ
+ property.
+
+ ABNF:
+
+ tz-parameter = "TZ=" (param-value / DQUOTE URI DQUOTE)
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 22]
+
+RFC 6350 vCard August 2011
+
+
+6. vCard Properties
+
+ What follows is an enumeration of the standard vCard properties.
+
+6.1. General Properties
+
+6.1.1. BEGIN
+
+ Purpose: To denote the beginning of a syntactic entity within a
+ text/vcard content-type.
+
+ Value type: text
+
+ Cardinality: 1
+
+ Special notes: The content entity MUST begin with the BEGIN property
+ with a value of "VCARD". The value is case-insensitive.
+
+ The BEGIN property is used in conjunction with the END property to
+ delimit an entity containing a related set of properties within a
+ text/vcard content-type. This construct can be used instead of
+ including multiple vCards as body parts inside of a multipart/
+ alternative MIME message. It is provided for applications that
+ wish to define content that can contain multiple entities within
+ the same text/vcard content-type or to define content that can be
+ identifiable outside of a MIME environment.
+
+ ABNF:
+
+ BEGIN-param = 0" " ; no parameter allowed
+ BEGIN-value = "VCARD"
+
+ Example:
+
+ BEGIN:VCARD
+
+6.1.2. END
+
+ Purpose: To denote the end of a syntactic entity within a text/vcard
+ content-type.
+
+ Value type: text
+
+ Cardinality: 1
+
+ Special notes: The content entity MUST end with the END type with a
+ value of "VCARD". The value is case-insensitive.
+
+
+
+
+Perreault Standards Track [Page 23]
+
+RFC 6350 vCard August 2011
+
+
+ The END property is used in conjunction with the BEGIN property to
+ delimit an entity containing a related set of properties within a
+ text/vcard content-type. This construct can be used instead of or
+ in addition to wrapping separate sets of information inside
+ additional MIME headers. It is provided for applications that
+ wish to define content that can contain multiple entities within
+ the same text/vcard content-type or to define content that can be
+ identifiable outside of a MIME environment.
+
+ ABNF:
+
+ END-param = 0" " ; no parameter allowed
+ END-value = "VCARD"
+
+ Example:
+
+ END:VCARD
+
+6.1.3. SOURCE
+
+ Purpose: To identify the source of directory information contained
+ in the content type.
+
+ Value type: uri
+
+ Cardinality: *
+
+ Special notes: The SOURCE property is used to provide the means by
+ which applications knowledgable in the given directory service
+ protocol can obtain additional or more up-to-date information from
+ the directory service. It contains a URI as defined in [RFC3986]
+ and/or other information referencing the vCard to which the
+ information pertains. When directory information is available
+ from more than one source, the sending entity can pick what it
+ considers to be the best source, or multiple SOURCE properties can
+ be included.
+
+ ABNF:
+
+ SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param
+ / mediatype-param / any-param
+ SOURCE-value = URI
+
+ Examples:
+
+ SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US
+
+
+
+
+
+Perreault Standards Track [Page 24]
+
+RFC 6350 vCard August 2011
+
+
+ SOURCE:http://directory.example.com/addressbooks/jdoe/
+ Jean%20Dupont.vcf
+
+6.1.4. KIND
+
+ Purpose: To specify the kind of object the vCard represents.
+
+ Value type: A single text value.
+
+ Cardinality: *1
+
+ Special notes: The value may be one of the following:
+
+ "individual" for a vCard representing a single person or entity.
+ This is the default kind of vCard.
+
+ "group" for a vCard representing a group of persons or entities.
+ The group's member entities can be other vCards or other types
+ of entities, such as email addresses or web sites. A group
+ vCard will usually contain MEMBER properties to specify the
+ members of the group, but it is not required to. A group vCard
+ without MEMBER properties can be considered an abstract
+ grouping, or one whose members are known empirically (perhaps
+ "IETF Participants" or "Republican U.S. Senators").
+
+ All properties in a group vCard apply to the group as a whole,
+ and not to any particular MEMBER. For example, an EMAIL
+ property might specify the address of a mailing list associated
+ with the group, and an IMPP property might refer to a group
+ chat room.
+
+ "org" for a vCard representing an organization. An organization
+ vCard will not (in fact, MUST NOT) contain MEMBER properties,
+ and so these are something of a cross between "individual" and
+ "group". An organization is a single entity, but not a person.
+ It might represent a business or government, a department or
+ division within a business or government, a club, an
+ association, or the like.
+
+ All properties in an organization vCard apply to the
+ organization as a whole, as is the case with a group vCard.
+ For example, an EMAIL property might specify the address of a
+ contact point for the organization.
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 25]
+
+RFC 6350 vCard August 2011
+
+
+ "location" for a named geographical place. A location vCard will
+ usually contain a GEO property, but it is not required to. A
+ location vCard without a GEO property can be considered an
+ abstract location, or one whose definition is known empirically
+ (perhaps "New England" or "The Seashore").
+
+ All properties in a location vCard apply to the location
+ itself, and not with any entity that might exist at that
+ location. For example, in a vCard for an office building, an
+ ADR property might give the mailing address for the building,
+ and a TEL property might specify the telephone number of the
+ receptionist.
+
+ An x-name. vCards MAY include private or experimental values for
+ KIND. Remember that x-name values are not intended for general
+ use and are unlikely to interoperate.
+
+ An iana-token. Additional values may be registered with IANA (see
+ Section 10.3.4). A new value's specification document MUST
+ specify which properties make sense for that new kind of vCard
+ and which do not.
+
+ Implementations MUST support the specific string values defined
+ above. If this property is absent, "individual" MUST be assumed
+ as the default. If this property is present but the
+ implementation does not understand its value (the value is an
+ x-name or iana-token that the implementation does not support),
+ the implementation SHOULD act in a neutral way, which usually
+ means treating the vCard as though its kind were "individual".
+ The presence of MEMBER properties MAY, however, be taken as an
+ indication that the unknown kind is an extension of "group".
+
+ Clients often need to visually distinguish contacts based on what
+ they represent, and the KIND property provides a direct way for
+ them to do so. For example, when displaying contacts in a list,
+ an icon could be displayed next to each one, using distinctive
+ icons for the different kinds; a client might use an outline of a
+ single person to represent an "individual", an outline of multiple
+ people to represent a "group", and so on. Alternatively, or in
+ addition, a client might choose to segregate different kinds of
+ vCards to different panes, tabs, or selections in the user
+ interface.
+
+ Some clients might also make functional distinctions among the
+ kinds, ignoring "location" vCards for some purposes and
+ considering only "location" vCards for others.
+
+
+
+
+
+Perreault Standards Track [Page 26]
+
+RFC 6350 vCard August 2011
+
+
+ When designing those sorts of visual and functional distinctions,
+ client implementations have to decide how to fit unsupported kinds
+ into the scheme. What icon is used for them? The one for
+ "individual"? A unique one, such as an icon of a question mark?
+ Which tab do they go into? It is beyond the scope of this
+ specification to answer these questions, but these are things
+ implementers need to consider.
+
+ ABNF:
+
+ KIND-param = "VALUE=text" / any-param
+ KIND-value = "individual" / "group" / "org" / "location"
+ / iana-token / x-name
+
+ Example:
+
+ This represents someone named Jane Doe working in the marketing
+ department of the North American division of ABC Inc.
+
+ BEGIN:VCARD
+ VERSION:4.0
+ KIND:individual
+ FN:Jane Doe
+ ORG:ABC\, Inc.;North American Division;Marketing
+ END:VCARD
+
+ This represents the department itself, commonly known as ABC
+ Marketing.
+
+ BEGIN:VCARD
+ VERSION:4.0
+ KIND:org
+ FN:ABC Marketing
+ ORG:ABC\, Inc.;North American Division;Marketing
+ END:VCARD
+
+6.1.5. XML
+
+ Purpose: To include extended XML-encoded vCard data in a plain
+ vCard.
+
+ Value type: A single text value.
+
+ Cardinality: *
+
+ Special notes: The content of this property is a single XML 1.0
+ [W3C.REC-xml-20081126] element whose namespace MUST be explicitly
+ specified using the xmlns attribute and MUST NOT be the vCard 4
+
+
+
+Perreault Standards Track [Page 27]
+
+RFC 6350 vCard August 2011
+
+
+ namespace ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies
+ that it cannot duplicate a standard vCard property.) The element
+ is to be interpreted as if it was contained in a <vcard> element,
+ as defined in [RFC6351].
+
+ The fragment is subject to normal line folding and escaping, i.e.,
+ replace all backslashes with "\\", then replace all newlines with
+ "\n", then fold long lines.
+
+ Support for this property is OPTIONAL, but implementations of this
+ specification MUST preserve instances of this property when
+ propagating vCards.
+
+ See [RFC6351] for more information on the intended use of this
+ property.
+
+ ABNF:
+
+ XML-param = "VALUE=text" / altid-param
+ XML-value = text
+
+6.2. Identification Properties
+
+ These types are used to capture information associated with the
+ identification and naming of the entity associated with the vCard.
+
+6.2.1. FN
+
+ Purpose: To specify the formatted text corresponding to the name of
+ the object the vCard represents.
+
+ Value type: A single text value.
+
+ Cardinality: 1*
+
+ Special notes: This property is based on the semantics of the X.520
+ Common Name attribute [CCITT.X520.1988]. The property MUST be
+ present in the vCard object.
+
+ ABNF:
+
+ FN-param = "VALUE=text" / type-param / language-param / altid-param
+ / pid-param / pref-param / any-param
+ FN-value = text
+
+ Example:
+
+ FN:Mr. John Q. Public\, Esq.
+
+
+
+Perreault Standards Track [Page 28]
+
+RFC 6350 vCard August 2011
+
+
+6.2.2. N
+
+ Purpose: To specify the components of the name of the object the
+ vCard represents.
+
+ Value type: A single structured text value. Each component can have
+ multiple values.
+
+ Cardinality: *1
+
+ Special note: The structured property value corresponds, in
+ sequence, to the Family Names (also known as surnames), Given
+ Names, Additional Names, Honorific Prefixes, and Honorific
+ Suffixes. The text components are separated by the SEMICOLON
+ character (U+003B). Individual text components can include
+ multiple text values separated by the COMMA character (U+002C).
+ This property is based on the semantics of the X.520 individual
+ name attributes [CCITT.X520.1988]. The property SHOULD be present
+ in the vCard object when the name of the object the vCard
+ represents follows the X.520 model.
+
+ The SORT-AS parameter MAY be applied to this property.
+
+ ABNF:
+
+ N-param = "VALUE=text" / sort-as-param / language-param
+ / altid-param / any-param
+ N-value = list-component 4(";" list-component)
+
+ Examples:
+
+ N:Public;John;Quinlan;Mr.;Esq.
+
+ N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
+
+6.2.3. NICKNAME
+
+ Purpose: To specify the text corresponding to the nickname of the
+ object the vCard represents.
+
+ Value type: One or more text values separated by a COMMA character
+ (U+002C).
+
+ Cardinality: *
+
+
+
+
+
+
+
+Perreault Standards Track [Page 29]
+
+RFC 6350 vCard August 2011
+
+
+ Special note: The nickname is the descriptive name given instead of
+ or in addition to the one belonging to the object the vCard
+ represents. It can also be used to specify a familiar form of a
+ proper name specified by the FN or N properties.
+
+ ABNF:
+
+ NICKNAME-param = "VALUE=text" / type-param / language-param
+ / altid-param / pid-param / pref-param / any-param
+ NICKNAME-value = text-list
+
+ Examples:
+
+ NICKNAME:Robbie
+
+ NICKNAME:Jim,Jimmie
+
+ NICKNAME;TYPE=work:Boss
+
+6.2.4. PHOTO
+
+ Purpose: To specify an image or photograph information that
+ annotates some aspect of the object the vCard represents.
+
+ Value type: A single URI.
+
+ Cardinality: *
+
+ ABNF:
+
+ PHOTO-param = "VALUE=uri" / altid-param / type-param
+ / mediatype-param / pref-param / pid-param / any-param
+ PHOTO-value = URI
+
+ Examples:
+
+ PHOTO:http://www.example.com/pub/photos/jqpublic.gif
+
+ PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv
+ AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
+ ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+ <...remainder of base64-encoded data...>
+
+6.2.5. BDAY
+
+ Purpose: To specify the birth date of the object the vCard
+ represents.
+
+
+
+
+Perreault Standards Track [Page 30]
+
+RFC 6350 vCard August 2011
+
+
+ Value type: The default is a single date-and-or-time value. It can
+ also be reset to a single text value.
+
+ Cardinality: *1
+
+ ABNF:
+
+ BDAY-param = BDAY-param-date / BDAY-param-text
+ BDAY-value = date-and-or-time / text
+ ; Value and parameter MUST match.
+
+ BDAY-param-date = "VALUE=date-and-or-time"
+ BDAY-param-text = "VALUE=text" / language-param
+
+ BDAY-param =/ altid-param / calscale-param / any-param
+ ; calscale-param can only be present when BDAY-value is
+ ; date-and-or-time and actually contains a date or date-time.
+
+ Examples:
+
+ BDAY:19960415
+ BDAY:--0415
+ BDAY;19531015T231000Z
+ BDAY;VALUE=text:circa 1800
+
+6.2.6. ANNIVERSARY
+
+ Purpose: The date of marriage, or equivalent, of the object the
+ vCard represents.
+
+ Value type: The default is a single date-and-or-time value. It can
+ also be reset to a single text value.
+
+ Cardinality: *1
+
+ ABNF:
+
+ ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text")
+ ANNIVERSARY-value = date-and-or-time / text
+ ; Value and parameter MUST match.
+
+ ANNIVERSARY-param =/ altid-param / calscale-param / any-param
+ ; calscale-param can only be present when ANNIVERSARY-value is
+ ; date-and-or-time and actually contains a date or date-time.
+
+ Examples:
+
+ ANNIVERSARY:19960415
+
+
+
+Perreault Standards Track [Page 31]
+
+RFC 6350 vCard August 2011
+
+
+6.2.7. GENDER
+
+ Purpose: To specify the components of the sex and gender identity of
+ the object the vCard represents.
+
+ Value type: A single structured value with two components. Each
+ component has a single text value.
+
+ Cardinality: *1
+
+ Special notes: The components correspond, in sequence, to the sex
+ (biological), and gender identity. Each component is optional.
+
+ Sex component: A single letter. M stands for "male", F stands
+ for "female", O stands for "other", N stands for "none or not
+ applicable", U stands for "unknown".
+
+ Gender identity component: Free-form text.
+
+ ABNF:
+
+ GENDER-param = "VALUE=text" / any-param
+ GENDER-value = sex [";" text]
+
+ sex = "" / "M" / "F" / "O" / "N" / "U"
+
+ Examples:
+
+ GENDER:M
+ GENDER:F
+ GENDER:M;Fellow
+ GENDER:F;grrrl
+ GENDER:O;intersex
+ GENDER:;it's complicated
+
+6.3. Delivery Addressing Properties
+
+ These types are concerned with information related to the delivery
+ addressing or label for the vCard object.
+
+6.3.1. ADR
+
+ Purpose: To specify the components of the delivery address for the
+ vCard object.
+
+ Value type: A single structured text value, separated by the
+ SEMICOLON character (U+003B).
+
+
+
+
+Perreault Standards Track [Page 32]
+
+RFC 6350 vCard August 2011
+
+
+ Cardinality: *
+
+ Special notes: The structured type value consists of a sequence of
+ address components. The component values MUST be specified in
+ their corresponding position. The structured type value
+ corresponds, in sequence, to
+ the post office box;
+ the extended address (e.g., apartment or suite number);
+ the street address;
+ the locality (e.g., city);
+ the region (e.g., state or province);
+ the postal code;
+ the country name (full name in the language specified in
+ Section 5.1).
+
+ When a component value is missing, the associated component
+ separator MUST still be specified.
+
+ Experience with vCard 3 has shown that the first two components
+ (post office box and extended address) are plagued with many
+ interoperability issues. To ensure maximal interoperability,
+ their values SHOULD be empty.
+
+ The text components are separated by the SEMICOLON character
+ (U+003B). Where it makes semantic sense, individual text
+ components can include multiple text values (e.g., a "street"
+ component with multiple lines) separated by the COMMA character
+ (U+002C).
+
+ The property can include the "PREF" parameter to indicate the
+ preferred delivery address when more than one address is
+ specified.
+
+ The GEO and TZ parameters MAY be used with this property.
+
+ The property can also include a "LABEL" parameter to present a
+ delivery address label for the address. Its value is a plain-text
+ string representing the formatted address. Newlines are encoded
+ as \n, as they are for property values.
+
+ ABNF:
+
+ label-param = "LABEL=" param-value
+
+ ADR-param = "VALUE=text" / label-param / language-param
+ / geo-parameter / tz-parameter / altid-param / pid-param
+ / pref-param / type-param / any-param
+
+
+
+
+Perreault Standards Track [Page 33]
+
+RFC 6350 vCard August 2011
+
+
+ ADR-value = ADR-component-pobox ";" ADR-component-ext ";"
+ ADR-component-street ";" ADR-component-locality ";"
+ ADR-component-region ";" ADR-component-code ";"
+ ADR-component-country
+ ADR-component-pobox = list-component
+ ADR-component-ext = list-component
+ ADR-component-street = list-component
+ ADR-component-locality = list-component
+ ADR-component-region = list-component
+ ADR-component-code = list-component
+ ADR-component-country = list-component
+
+ Example: In this example, the post office box and the extended
+ address are absent.
+
+ ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n
+ Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n
+ U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
+
+6.4. Communications Properties
+
+ These properties describe information about how to communicate with
+ the object the vCard represents.
+
+6.4.1. TEL
+
+ Purpose: To specify the telephone number for telephony communication
+ with the object the vCard represents.
+
+ Value type: By default, it is a single free-form text value (for
+ backward compatibility with vCard 3), but it SHOULD be reset to a
+ URI value. It is expected that the URI scheme will be "tel", as
+ specified in [RFC3966], but other schemes MAY be used.
+
+ Cardinality: *
+
+ Special notes: This property is based on the X.520 Telephone Number
+ attribute [CCITT.X520.1988].
+
+ The property can include the "PREF" parameter to indicate a
+ preferred-use telephone number.
+
+ The property can include the parameter "TYPE" to specify intended
+ use for the telephone number. The predefined values for the TYPE
+ parameter are:
+
+
+
+
+
+
+Perreault Standards Track [Page 34]
+
+RFC 6350 vCard August 2011
+
+
+ +-----------+-------------------------------------------------------+
+ | Value | Description |
+ +-----------+-------------------------------------------------------+
+ | text | Indicates that the telephone number supports text |
+ | | messages (SMS). |
+ | voice | Indicates a voice telephone number. |
+ | fax | Indicates a facsimile telephone number. |
+ | cell | Indicates a cellular or mobile telephone number. |
+ | video | Indicates a video conferencing telephone number. |
+ | pager | Indicates a paging device telephone number. |
+ | textphone | Indicates a telecommunication device for people with |
+ | | hearing or speech difficulties. |
+ +-----------+-------------------------------------------------------+
+
+ The default type is "voice". These type parameter values can be
+ specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a
+ value list (e.g., TYPE="text,voice"). The default can be
+ overridden to another set of values by specifying one or more
+ alternate values. For example, the default TYPE of "voice" can be
+ reset to a VOICE and FAX telephone number by the value list
+ TYPE="voice,fax".
+
+ If this property's value is a URI that can also be used for
+ instant messaging, the IMPP (Section 6.4.3) property SHOULD be
+ used in addition to this property.
+
+ ABNF:
+
+ TEL-param = TEL-text-param / TEL-uri-param
+ TEL-value = TEL-text-value / TEL-uri-value
+ ; Value and parameter MUST match.
+
+ TEL-text-param = "VALUE=text"
+ TEL-text-value = text
+
+ TEL-uri-param = "VALUE=uri" / mediatype-param
+ TEL-uri-value = URI
+
+ TEL-param =/ type-param / pid-param / pref-param / altid-param
+ / any-param
+
+ type-param-tel = "text" / "voice" / "fax" / "cell" / "video"
+ / "pager" / "textphone" / iana-token / x-name
+ ; type-param-tel MUST NOT be used with a property other than TEL.
+
+
+
+
+
+
+
+Perreault Standards Track [Page 35]
+
+RFC 6350 vCard August 2011
+
+
+ Example:
+
+ TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555
+ TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67
+
+6.4.2. EMAIL
+
+ Purpose: To specify the electronic mail address for communication
+ with the object the vCard represents.
+
+ Value type: A single text value.
+
+ Cardinality: *
+
+ Special notes: The property can include tye "PREF" parameter to
+ indicate a preferred-use email address when more than one is
+ specified.
+
+ Even though the value is free-form UTF-8 text, it is likely to be
+ interpreted by a Mail User Agent (MUA) as an "addr-spec", as
+ defined in [RFC5322], Section 3.4.1. Readers should also be aware
+ of the current work toward internationalized email addresses
+ [RFC5335bis].
+
+ ABNF:
+
+ EMAIL-param = "VALUE=text" / pid-param / pref-param / type-param
+ / altid-param / any-param
+ EMAIL-value = text
+
+ Example:
+
+ EMAIL;TYPE=work:jqpublic@xyz.example.com
+
+ EMAIL;PREF=1:jane_doe@example.com
+
+6.4.3. IMPP
+
+ Purpose: To specify the URI for instant messaging and presence
+ protocol communications with the object the vCard represents.
+
+ Value type: A single URI.
+
+ Cardinality: *
+
+ Special notes: The property may include the "PREF" parameter to
+ indicate that this is a preferred address and has the same
+ semantics as the "PREF" parameter in a TEL property.
+
+
+
+Perreault Standards Track [Page 36]
+
+RFC 6350 vCard August 2011
+
+
+ If this property's value is a URI that can be used for voice
+ and/or video, the TEL property (Section 6.4.1) SHOULD be used in
+ addition to this property.
+
+ This property is adapted from [RFC4770], which is made obsolete by
+ this document.
+
+ ABNF:
+
+ IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param
+ / mediatype-param / altid-param / any-param
+ IMPP-value = URI
+
+ Example:
+
+ IMPP;PREF=1:xmpp:alice@example.com
+
+6.4.4. LANG
+
+ Purpose: To specify the language(s) that may be used for contacting
+ the entity associated with the vCard.
+
+ Value type: A single language-tag value.
+
+ Cardinality: *
+
+ ABNF:
+
+ LANG-param = "VALUE=language-tag" / pid-param / pref-param
+ / altid-param / type-param / any-param
+ LANG-value = Language-Tag
+
+ Example:
+
+ LANG;TYPE=work;PREF=1:en
+ LANG;TYPE=work;PREF=2:fr
+ LANG;TYPE=home:fr
+
+6.5. Geographical Properties
+
+ These properties are concerned with information associated with
+ geographical positions or regions associated with the object the
+ vCard represents.
+
+6.5.1. TZ
+
+ Purpose: To specify information related to the time zone of the
+ object the vCard represents.
+
+
+
+Perreault Standards Track [Page 37]
+
+RFC 6350 vCard August 2011
+
+
+ Value type: The default is a single text value. It can also be
+ reset to a single URI or utc-offset value.
+
+ Cardinality: *
+
+ Special notes: It is expected that names from the public-domain
+ Olson database [TZ-DB] will be used, but this is not a
+ restriction. See also [IANA-TZ].
+
+ Efforts are currently being directed at creating a standard URI
+ scheme for expressing time zone information. Usage of such a
+ scheme would ensure a high level of interoperability between
+ implementations that support it.
+
+ Note that utc-offset values SHOULD NOT be used because the UTC
+ offset varies with time -- not just because of the usual daylight
+ saving time shifts that occur in may regions, but often entire
+ regions will "re-base" their overall offset. The actual offset
+ may be +/- 1 hour (or perhaps a little more) than the one given.
+
+ ABNF:
+
+ TZ-param = "VALUE=" ("text" / "uri" / "utc-offset")
+ TZ-value = text / URI / utc-offset
+ ; Value and parameter MUST match.
+
+ TZ-param =/ altid-param / pid-param / pref-param / type-param
+ / mediatype-param / any-param
+
+ Examples:
+
+ TZ:Raleigh/North America
+
+ TZ;VALUE=utc-offset:-0500
+ ; Note: utc-offset format is NOT RECOMMENDED.
+
+6.5.2. GEO
+
+ Purpose: To specify information related to the global positioning of
+ the object the vCard represents.
+
+ Value type: A single URI.
+
+ Cardinality: *
+
+ Special notes: The "geo" URI scheme [RFC5870] is particularly well
+ suited for this property, but other schemes MAY be used.
+
+
+
+
+Perreault Standards Track [Page 38]
+
+RFC 6350 vCard August 2011
+
+
+ ABNF:
+
+ GEO-param = "VALUE=uri" / pid-param / pref-param / type-param
+ / mediatype-param / altid-param / any-param
+ GEO-value = URI
+
+ Example:
+
+ GEO:geo:37.386013,-122.082932
+
+6.6. Organizational Properties
+
+ These properties are concerned with information associated with
+ characteristics of the organization or organizational units of the
+ object that the vCard represents.
+
+6.6.1. TITLE
+
+ Purpose: To specify the position or job of the object the vCard
+ represents.
+
+ Value type: A single text value.
+
+ Cardinality: *
+
+ Special notes: This property is based on the X.520 Title attribute
+ [CCITT.X520.1988].
+
+ ABNF:
+
+ TITLE-param = "VALUE=text" / language-param / pid-param
+ / pref-param / altid-param / type-param / any-param
+ TITLE-value = text
+
+ Example:
+
+ TITLE:Research Scientist
+
+6.6.2. ROLE
+
+ Purpose: To specify the function or part played in a particular
+ situation by the object the vCard represents.
+
+ Value type: A single text value.
+
+ Cardinality: *
+
+
+
+
+
+Perreault Standards Track [Page 39]
+
+RFC 6350 vCard August 2011
+
+
+ Special notes: This property is based on the X.520 Business Category
+ explanatory attribute [CCITT.X520.1988]. This property is
+ included as an organizational type to avoid confusion with the
+ semantics of the TITLE property and incorrect usage of that
+ property when the semantics of this property is intended.
+
+ ABNF:
+
+ ROLE-param = "VALUE=text" / language-param / pid-param / pref-param
+ / type-param / altid-param / any-param
+ ROLE-value = text
+
+ Example:
+
+ ROLE:Project Leader
+
+6.6.3. LOGO
+
+ Purpose: To specify a graphic image of a logo associated with the
+ object the vCard represents.
+
+ Value type: A single URI.
+
+ Cardinality: *
+
+ ABNF:
+
+ LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param
+ / type-param / mediatype-param / altid-param / any-param
+ LOGO-value = URI
+
+ Examples:
+
+ LOGO:http://www.example.com/pub/logos/abccorp.jpg
+
+ LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc
+ AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
+ ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+ <...the remainder of base64-encoded data...>
+
+6.6.4. ORG
+
+ Purpose: To specify the organizational name and units associated
+ with the vCard.
+
+ Value type: A single structured text value consisting of components
+ separated by the SEMICOLON character (U+003B).
+
+
+
+
+Perreault Standards Track [Page 40]
+
+RFC 6350 vCard August 2011
+
+
+ Cardinality: *
+
+ Special notes: The property is based on the X.520 Organization Name
+ and Organization Unit attributes [CCITT.X520.1988]. The property
+ value is a structured type consisting of the organization name,
+ followed by zero or more levels of organizational unit names.
+
+ The SORT-AS parameter MAY be applied to this property.
+
+ ABNF:
+
+ ORG-param = "VALUE=text" / sort-as-param / language-param
+ / pid-param / pref-param / altid-param / type-param
+ / any-param
+ ORG-value = component *(";" component)
+
+ Example: A property value consisting of an organizational name,
+ organizational unit #1 name, and organizational unit #2 name.
+
+ ORG:ABC\, Inc.;North American Division;Marketing
+
+6.6.5. MEMBER
+
+ Purpose: To include a member in the group this vCard represents.
+
+ Value type: A single URI. It MAY refer to something other than a
+ vCard object. For example, an email distribution list could
+ employ the "mailto" URI scheme [RFC6068] for efficiency.
+
+ Cardinality: *
+
+ Special notes: This property MUST NOT be present unless the value of
+ the KIND property is "group".
+
+ ABNF:
+
+ MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param
+ / mediatype-param / any-param
+ MEMBER-value = URI
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 41]
+
+RFC 6350 vCard August 2011
+
+
+ Examples:
+
+ BEGIN:VCARD
+ VERSION:4.0
+ KIND:group
+ FN:The Doe family
+ MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
+ MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
+ END:VCARD
+ BEGIN:VCARD
+ VERSION:4.0
+ FN:John Doe
+ UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af
+ END:VCARD
+ BEGIN:VCARD
+ VERSION:4.0
+ FN:Jane Doe
+ UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519
+ END:VCARD
+
+ BEGIN:VCARD
+ VERSION:4.0
+ KIND:group
+ FN:Funky distribution list
+ MEMBER:mailto:subscriber1@example.com
+ MEMBER:xmpp:subscriber2@example.com
+ MEMBER:sip:subscriber3@example.com
+ MEMBER:tel:+1-418-555-5555
+ END:VCARD
+
+6.6.6. RELATED
+
+ Purpose: To specify a relationship between another entity and the
+ entity represented by this vCard.
+
+ Value type: A single URI. It can also be reset to a single text
+ value. The text value can be used to specify textual information.
+
+ Cardinality: *
+
+ Special notes: The TYPE parameter MAY be used to characterize the
+ related entity. It contains a comma-separated list of values that
+ are registered with IANA as described in Section 10.2. The
+ registry is pre-populated with the values defined in [xfn]. This
+ document also specifies two additional values:
+
+ agent: an entity who may sometimes act on behalf of the entity
+ associated with the vCard.
+
+
+
+Perreault Standards Track [Page 42]
+
+RFC 6350 vCard August 2011
+
+
+ emergency: indicates an emergency contact
+
+ ABNF:
+
+ RELATED-param = RELATED-param-uri / RELATED-param-text
+ RELATED-value = URI / text
+ ; Parameter and value MUST match.
+
+ RELATED-param-uri = "VALUE=uri" / mediatype-param
+ RELATED-param-text = "VALUE=text" / language-param
+
+ RELATED-param =/ pid-param / pref-param / altid-param / type-param
+ / any-param
+
+ type-param-related = related-type-value *("," related-type-value)
+ ; type-param-related MUST NOT be used with a property other than
+ ; RELATED.
+
+ related-type-value = "contact" / "acquaintance" / "friend" / "met"
+ / "co-worker" / "colleague" / "co-resident"
+ / "neighbor" / "child" / "parent"
+ / "sibling" / "spouse" / "kin" / "muse"
+ / "crush" / "date" / "sweetheart" / "me"
+ / "agent" / "emergency"
+
+ Examples:
+
+ RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
+ RELATED;TYPE=contact:http://example.com/directory/jdoe.vcf
+ RELATED;TYPE=co-worker;VALUE=text:Please contact my assistant Jane
+ Doe for any inquiries.
+
+6.7. Explanatory Properties
+
+ These properties are concerned with additional explanations, such as
+ that related to informational notes or revisions specific to the
+ vCard.
+
+6.7.1. CATEGORIES
+
+ Purpose: To specify application category information about the
+ vCard, also known as "tags".
+
+ Value type: One or more text values separated by a COMMA character
+ (U+002C).
+
+ Cardinality: *
+
+
+
+
+Perreault Standards Track [Page 43]
+
+RFC 6350 vCard August 2011
+
+
+ ABNF:
+
+ CATEGORIES-param = "VALUE=text" / pid-param / pref-param
+ / type-param / altid-param / any-param
+ CATEGORIES-value = text-list
+
+ Example:
+
+ CATEGORIES:TRAVEL AGENT
+
+ CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
+
+6.7.2. NOTE
+
+ Purpose: To specify supplemental information or a comment that is
+ associated with the vCard.
+
+ Value type: A single text value.
+
+ Cardinality: *
+
+ Special notes: The property is based on the X.520 Description
+ attribute [CCITT.X520.1988].
+
+ ABNF:
+
+ NOTE-param = "VALUE=text" / language-param / pid-param / pref-param
+ / type-param / altid-param / any-param
+ NOTE-value = text
+
+ Example:
+
+ NOTE:This fax number is operational 0800 to 1715
+ EST\, Mon-Fri.
+
+6.7.3. PRODID
+
+ Purpose: To specify the identifier for the product that created the
+ vCard object.
+
+ Type value: A single text value.
+
+ Cardinality: *1
+
+ Special notes: Implementations SHOULD use a method such as that
+ specified for Formal Public Identifiers in [ISO9070] or for
+ Universal Resource Names in [RFC3406] to ensure that the text
+ value is unique.
+
+
+
+Perreault Standards Track [Page 44]
+
+RFC 6350 vCard August 2011
+
+
+ ABNF:
+
+ PRODID-param = "VALUE=text" / any-param
+ PRODID-value = text
+
+ Example:
+
+ PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
+
+6.7.4. REV
+
+ Purpose: To specify revision information about the current vCard.
+
+ Value type: A single timestamp value.
+
+ Cardinality: *1
+
+ Special notes: The value distinguishes the current revision of the
+ information in this vCard for other renditions of the information.
+
+ ABNF:
+
+ REV-param = "VALUE=timestamp" / any-param
+ REV-value = timestamp
+
+ Example:
+
+ REV:19951031T222710Z
+
+6.7.5. SOUND
+
+ Purpose: To specify a digital sound content information that
+ annotates some aspect of the vCard. This property is often used
+ to specify the proper pronunciation of the name property value of
+ the vCard.
+
+ Value type: A single URI.
+
+ Cardinality: *
+
+ ABNF:
+
+ SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param
+ / type-param / mediatype-param / altid-param
+ / any-param
+ SOUND-value = URI
+
+
+
+
+
+Perreault Standards Track [Page 45]
+
+RFC 6350 vCard August 2011
+
+
+ Example:
+
+ SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com
+
+ SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh
+ AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
+ ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
+ <...the remainder of base64-encoded data...>
+
+6.7.6. UID
+
+ Purpose: To specify a value that represents a globally unique
+ identifier corresponding to the entity associated with the vCard.
+
+ Value type: A single URI value. It MAY also be reset to free-form
+ text.
+
+ Cardinality: *1
+
+ Special notes: This property is used to uniquely identify the object
+ that the vCard represents. The "uuid" URN namespace defined in
+ [RFC4122] is particularly well suited to this task, but other URI
+ schemes MAY be used. Free-form text MAY also be used.
+
+ ABNF:
+
+ UID-param = UID-uri-param / UID-text-param
+ UID-value = UID-uri-value / UID-text-value
+ ; Value and parameter MUST match.
+
+ UID-uri-param = "VALUE=uri"
+ UID-uri-value = URI
+
+ UID-text-param = "VALUE=text"
+ UID-text-value = text
+
+ UID-param =/ any-param
+
+ Example:
+
+ UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 46]
+
+RFC 6350 vCard August 2011
+
+
+6.7.7. CLIENTPIDMAP
+
+ Purpose: To give a global meaning to a local PID source identifier.
+
+ Value type: A semicolon-separated pair of values. The first field
+ is a small integer corresponding to the second field of a PID
+ parameter instance. The second field is a URI. The "uuid" URN
+ namespace defined in [RFC4122] is particularly well suited to this
+ task, but other URI schemes MAY be used.
+
+ Cardinality: *
+
+ Special notes: PID source identifiers (the source identifier is the
+ second field in a PID parameter instance) are small integers that
+ only have significance within the scope of a single vCard
+ instance. Each distinct source identifier present in a vCard MUST
+ have an associated CLIENTPIDMAP. See Section 7 for more details
+ on the usage of CLIENTPIDMAP.
+
+ PID source identifiers MUST be strictly positive. Zero is not
+ allowed.
+
+ As a special exception, the PID parameter MUST NOT be applied to
+ this property.
+
+ ABNF:
+
+ CLIENTPIDMAP-param = any-param
+ CLIENTPIDMAP-value = 1*DIGIT ";" URI
+
+ Example:
+
+ TEL;PID=3.1,4.2;VALUE=uri:tel:+1-555-555-5555
+ EMAIL;PID=4.1,5.2:jdoe@example.com
+ CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b
+ CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5
+
+6.7.8. URL
+
+ Purpose: To specify a uniform resource locator associated with the
+ object to which the vCard refers. Examples for individuals
+ include personal web sites, blogs, and social networking site
+ identifiers.
+
+ Cardinality: *
+
+ Value type: A single uri value.
+
+
+
+
+Perreault Standards Track [Page 47]
+
+RFC 6350 vCard August 2011
+
+
+ ABNF:
+
+ URL-param = "VALUE=uri" / pid-param / pref-param / type-param
+ / mediatype-param / altid-param / any-param
+ URL-value = URI
+
+ Example:
+
+ URL:http://example.org/restaurant.french/~chezchic.html
+
+6.7.9. VERSION
+
+ Purpose: To specify the version of the vCard specification used to
+ format this vCard.
+
+ Value type: A single text value.
+
+ Cardinality: 1
+
+ Special notes: This property MUST be present in the vCard object,
+ and it must appear immediately after BEGIN:VCARD. The value MUST
+ be "4.0" if the vCard corresponds to this specification. Note
+ that earlier versions of vCard allowed this property to be placed
+ anywhere in the vCard object, or even to be absent.
+
+ ABNF:
+
+ VERSION-param = "VALUE=text" / any-param
+ VERSION-value = "4.0"
+
+ Example:
+
+ VERSION:4.0
+
+6.8. Security Properties
+
+ These properties are concerned with the security of communication
+ pathways or access to the vCard.
+
+6.8.1. KEY
+
+ Purpose: To specify a public key or authentication certificate
+ associated with the object that the vCard represents.
+
+ Value type: A single URI. It can also be reset to a text value.
+
+ Cardinality: *
+
+
+
+
+Perreault Standards Track [Page 48]
+
+RFC 6350 vCard August 2011
+
+
+ ABNF:
+
+ KEY-param = KEY-uri-param / KEY-text-param
+ KEY-value = KEY-uri-value / KEY-text-value
+ ; Value and parameter MUST match.
+
+ KEY-uri-param = "VALUE=uri" / mediatype-param
+ KEY-uri-value = URI
+
+ KEY-text-param = "VALUE=text"
+ KEY-text-value = text
+
+ KEY-param =/ altid-param / pid-param / pref-param / type-param
+ / any-param
+
+ Examples:
+
+ KEY:http://www.example.com/keys/jdoe.cer
+
+ KEY;MEDIATYPE=application/pgp-keys:ftp://example.com/keys/jdoe
+
+ KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE
+ UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
+ <... remainder of base64-encoded data ...>
+
+6.9. Calendar Properties
+
+ These properties are further specified in [RFC2739].
+
+6.9.1. FBURL
+
+ Purpose: To specify the URI for the busy time associated with the
+ object that the vCard represents.
+
+ Value type: A single URI value.
+
+ Cardinality: *
+
+ Special notes: Where multiple FBURL properties are specified, the
+ default FBURL property is indicated with the PREF parameter. The
+ FTP [RFC1738] or HTTP [RFC2616] type of URI points to an iCalendar
+ [RFC5545] object associated with a snapshot of the next few weeks
+ or months of busy time data. If the iCalendar object is
+ represented as a file or document, its file extension should be
+ ".ifb".
+
+
+
+
+
+
+Perreault Standards Track [Page 49]
+
+RFC 6350 vCard August 2011
+
+
+ ABNF:
+
+ FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param
+ / mediatype-param / altid-param / any-param
+ FBURL-value = URI
+
+ Examples:
+
+ FBURL;PREF=1:http://www.example.com/busy/janedoe
+ FBURL;MEDIATYPE=text/calendar:ftp://example.com/busy/project-a.ifb
+
+6.9.2. CALADRURI
+
+ Purpose: To specify the calendar user address [RFC5545] to which a
+ scheduling request [RFC5546] should be sent for the object
+ represented by the vCard.
+
+ Value type: A single URI value.
+
+ Cardinality: *
+
+ Special notes: Where multiple CALADRURI properties are specified,
+ the default CALADRURI property is indicated with the PREF
+ parameter.
+
+ ABNF:
+
+ CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param
+ / mediatype-param / altid-param / any-param
+ CALADRURI-value = URI
+
+ Example:
+
+ CALADRURI;PREF=1:mailto:janedoe@example.com
+ CALADRURI:http://example.com/calendar/jdoe
+
+6.9.3. CALURI
+
+ Purpose: To specify the URI for a calendar associated with the
+ object represented by the vCard.
+
+ Value type: A single URI value.
+
+ Cardinality: *
+
+ Special notes: Where multiple CALURI properties are specified, the
+ default CALURI property is indicated with the PREF parameter. The
+ property should contain a URI pointing to an iCalendar [RFC5545]
+
+
+
+Perreault Standards Track [Page 50]
+
+RFC 6350 vCard August 2011
+
+
+ object associated with a snapshot of the user's calendar store.
+ If the iCalendar object is represented as a file or document, its
+ file extension should be ".ics".
+
+ ABNF:
+
+ CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param
+ / mediatype-param / altid-param / any-param
+ CALURI-value = URI
+
+ Examples:
+
+ CALURI;PREF=1:http://cal.example.com/calA
+ CALURI;MEDIATYPE=text/calendar:ftp://ftp.example.com/calA.ics
+
+6.10. Extended Properties and Parameters
+
+ The properties and parameters defined by this document can be
+ extended. Non-standard, private properties and parameters with a
+ name starting with "X-" may be defined bilaterally between two
+ cooperating agents without outside registration or standardization.
+
+7. Synchronization
+
+ vCard data often needs to be synchronized between devices. In this
+ context, synchronization is defined as the intelligent merging of two
+ representations of the same object. vCard 4.0 includes mechanisms to
+ aid this process.
+
+7.1. Mechanisms
+
+ Two mechanisms are available: the UID property is used to match
+ multiple instances of the same vCard, while the PID parameter is used
+ to match multiple instances of the same property.
+
+ The term "matching" is used here to mean recognizing that two
+ instances are in fact representations of the same object. For
+ example, a single vCard that is shared with someone results in two
+ vCard instances. After they have evolved separately, they still
+ represent the same object, and therefore may be matched by a
+ synchronization engine.
+
+7.1.1. Matching vCard Instances
+
+ vCard instances for which the UID properties (Section 6.7.6) are
+ equivalent MUST be matched. Equivalence is determined as specified
+ in [RFC3986], Section 6.
+
+
+
+
+Perreault Standards Track [Page 51]
+
+RFC 6350 vCard August 2011
+
+
+ In all other cases, vCard instances MAY be matched at the discretion
+ of the synchronization engine.
+
+7.1.2. Matching Property Instances
+
+ Property instances belonging to unmatched vCards MUST NOT be matched.
+
+ Property instances whose name (e.g., EMAIL, TEL, etc.) is not the
+ same MUST NOT be matched.
+
+ Property instances whose name is CLIENTPIDMAP are handled separately
+ and MUST NOT be matched. The synchronization MUST ensure that there
+ is consistency of CLIENTPIDMAPs among matched vCard instances.
+
+ Property instances belonging to matched vCards, whose name is the
+ same, and whose maximum cardinality is 1, MUST be matched.
+
+ Property instances belonging to matched vCards, whose name is the
+ same, and whose PID parameters match, MUST be matched. See
+ Section 7.1.3 for details on PID matching.
+
+ In all other cases, property instances MAY be matched at the
+ discretion of the synchronization engine.
+
+7.1.3. PID Matching
+
+ Two PID values for which the first fields are equivalent represent
+ the same local value.
+
+ Two PID values representing the same local value and for which the
+ second fields point to CLIENTPIDMAP properties whose second field
+ URIs are equivalent (as specified in [RFC3986], Section 6) also
+ represent the same global value.
+
+ PID parameters for which at least one pair of their values represent
+ the same global value MUST be matched.
+
+ In all other cases, PID parameters MAY be matched at the discretion
+ of the synchronization engine.
+
+ For example, PID value "5.1", in the first vCard below, and PID value
+ "5.2", in the second vCard below, represent the same global value.
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 52]
+
+RFC 6350 vCard August 2011
+
+
+ BEGIN:VCARD
+ VERSION:4.0
+ EMAIL;PID=4.2,5.1:jdoe@example.com
+ CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
+ CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc
+ END:VCARD
+
+ BEGIN:VCARD
+ VERSION:4.0
+ EMAIL;PID=5.1,5.2:john@example.com
+ CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d
+ CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527
+ END:VCARD
+
+7.2. Example
+
+7.2.1. Creation
+
+ The following simple vCard is first created on a given device.
+
+ BEGIN:VCARD
+ VERSION:4.0
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
+ FN;PID=1.1:J. Doe
+ N:Doe;J.;;;
+ EMAIL;PID=1.1:jdoe@example.com
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
+ END:VCARD
+
+ This new vCard is assigned the UID
+ "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating
+ device. The FN and EMAIL properties are assigned the same local
+ value of 1, and this value is given global context by associating it
+ with "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which
+ represents the creating device. We are at liberty to reuse the same
+ local value since instances of different properties will never be
+ matched. The N property has no PID because it is forbidden by its
+ maximum cardinality of 1.
+
+7.2.2. Initial Sharing
+
+ This vCard is shared with a second device. Upon inspecting the UID
+ property, the second device understands that this is a new vCard
+ (i.e., unmatched) and thus the synchronization results in a simple
+ copy.
+
+
+
+
+
+
+Perreault Standards Track [Page 53]
+
+RFC 6350 vCard August 2011
+
+
+7.2.3. Adding and Sharing a Property
+
+ A new phone number is created on the first device, then the vCard is
+ shared with the second device. This is what the second device
+ receives:
+
+ BEGIN:VCARD
+ VERSION:4.0
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
+ FN;PID=1.1:J. Doe
+ N:Doe;J.;;;
+ EMAIL;PID=1.1:jdoe@example.com
+ TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
+ END:VCARD
+
+ Upon inspecting the UID property, the second device matches the vCard
+ it received to the vCard that it already has stored. It then starts
+ comparing the properties of the two vCards in same-named pairs.
+
+ The FN properties are matched because the PID parameters have the
+ same global value. Since the property value is the same, no update
+ takes place.
+
+ The N properties are matched automatically because their maximum
+ cardinality is 1. Since the property value is the same, no update
+ takes place.
+
+ The EMAIL properties are matched because the PID parameters have the
+ same global value. Since the property value is the same, no update
+ takes place.
+
+ The TEL property in the new vCard is not matched to any in the stored
+ vCard because no property in the stored vCard has the same name.
+ Therefore, this property is copied from the new vCard to the stored
+ vCard.
+
+ The CLIENTPIDMAP property is handled separately by the
+ synchronization engine. It ensures that it is consistent with the
+ stored one. If it was not, the results would be up to the
+ synchronization engine, and thus undefined by this document.
+
+7.2.4. Simultaneous Editing
+
+ A new email address and a new phone number are added to the vCard on
+ each of the two devices, and then a new synchronization event
+ happens. Here are the vCards that are communicated to each other:
+
+
+
+
+Perreault Standards Track [Page 54]
+
+RFC 6350 vCard August 2011
+
+
+ BEGIN:VCARD
+ VERSION:4.0
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
+ FN;PID=1.1:J. Doe
+ N:Doe;J.;;;
+ EMAIL;PID=1.1:jdoe@example.com
+ EMAIL;PID=2.1:boss@example.com
+ TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
+ TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
+ END:VCARD
+
+ BEGIN:VCARD
+ VERSION:4.0
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
+ FN;PID=1.1:J. Doe
+ N:Doe;J.;;;
+ EMAIL;PID=1.1:jdoe@example.com
+ EMAIL;PID=2.2:ceo@example.com
+ TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
+ TEL;PID=2.2;VALUE=uri:tel:+1-666-666-6666
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
+ CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee
+ END:VCARD
+
+ On the first device, the same PID source identifier (1) is reused for
+ the new EMAIL and TEL properties. On the second device, a new source
+ identifier (2) is generated, and a corresponding CLIENTPIDMAP
+ property is created. It contains the second device's identifier,
+ "urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee".
+
+ The new EMAIL properties are unmatched on both sides since the PID
+ global value is new in both cases. The sync thus results in a copy
+ on both sides.
+
+ Although the situation appears to be the same for the TEL properties,
+ in this case, the synchronization engine is particularly smart and
+ matches the two new TEL properties even though their PID global
+ values are different. Note that in this case, the rules of
+ Section 7.1.2 state that two properties MAY be matched at the
+ discretion of the synchronization engine. Therefore, the two
+ properties are merged.
+
+ All this results in the following vCard, which is stored on both
+ devices:
+
+
+
+
+
+
+Perreault Standards Track [Page 55]
+
+RFC 6350 vCard August 2011
+
+
+ BEGIN:VCARD
+ VERSION:4.0
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
+ FN:J. Doe
+ N:Doe;J.;;;
+ EMAIL;PID=1.1:jdoe@example.com
+ EMAIL;PID=2.1:boss@example.com
+ EMAIL;PID=2.2:ceo@example.com
+ TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
+ TEL;PID=2.1,2.2;VALUE=uri:tel:+1-666-666-6666
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
+ CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee
+ END:VCARD
+
+7.2.5. Global Context Simplification
+
+ The two devices finish their synchronization procedure by simplifying
+ their global contexts. Since they haven't talked to any other
+ device, the following vCard is for all purposes equivalent to the
+ above. It is also shorter.
+
+ BEGIN:VCARD
+ VERSION:4.0
+ UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
+ FN:J. Doe
+ N:Doe;J.;;;
+ EMAIL;PID=1.1:jdoe@example.com
+ EMAIL;PID=2.1:boss@example.com
+ EMAIL;PID=3.1:ceo@example.com
+ TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555
+ TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666
+ CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556
+ END:VCARD
+
+ The details of global context simplification are unspecified by this
+ document. They are left up to the synchronization engine. This
+ example is merely intended to illustrate the possibility, which
+ investigating would be, in the author's opinion, worthwhile.
+
+8. Example: Author's vCard
+
+ BEGIN:VCARD
+ VERSION:4.0
+ FN:Simon Perreault
+ N:Perreault;Simon;;;ing. jr,M.Sc.
+ BDAY:--0203
+ ANNIVERSARY:20090808T1430-0500
+ GENDER:M
+
+
+
+Perreault Standards Track [Page 56]
+
+RFC 6350 vCard August 2011
+
+
+ LANG;PREF=1:fr
+ LANG;PREF=2:en
+ ORG;TYPE=work:Viagenie
+ ADR;TYPE=work:;Suite D2-630;2875 Laurier;
+ Quebec;QC;G1V 2M2;Canada
+ TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102
+ TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501
+ EMAIL;TYPE=work:simon.perreault@viagenie.ca
+ GEO;TYPE=work:geo:46.772673,-71.282945
+ KEY;TYPE=work;VALUE=uri:
+ http://www.viagenie.ca/simon.perreault/simon.asc
+ TZ:-0500
+ URL;TYPE=home:http://nomis80.org
+ END:VCARD
+
+9. Security Considerations
+
+ o Internet mail is often used to transport vCards and is subject to
+ many well-known security attacks, including monitoring, replay,
+ and forgery. Care should be taken by any directory service in
+ allowing information to leave the scope of the service itself,
+ where any access controls or confidentiality can no longer be
+ guaranteed. Applications should also take care to display
+ directory data in a "safe" environment.
+
+ o vCards can carry cryptographic keys or certificates, as described
+ in Section 6.8.1.
+
+ o vCards often carry information that can be sensitive (e.g.,
+ birthday, address, and phone information). Although vCards have
+ no inherent authentication or confidentiality provisions, they can
+ easily be carried by any security mechanism that transfers MIME
+ objects to address authentication or confidentiality (e.g., S/MIME
+ [RFC5751], OpenPGP [RFC4880]). In cases where the confidentiality
+ or authenticity of information contained in vCard is a concern,
+ the vCard SHOULD be transported using one of these secure
+ mechanisms. The KEY property (Section 6.8.1) can be used to
+ transport the public key used by these mechanisms.
+
+ o The information in a vCard may become out of date. In cases where
+ the vitality of data is important to an originator of a vCard, the
+ SOURCE property (Section 6.1.3) SHOULD be specified. In addition,
+ the "REV" type described in Section 6.7.4 can be specified to
+ indicate the last time that the vCard data was updated.
+
+ o Many vCard properties may be used to transport URIs. Please refer
+ to [RFC3986], Section 7, for considerations related to URIs.
+
+
+
+
+Perreault Standards Track [Page 57]
+
+RFC 6350 vCard August 2011
+
+
+10. IANA Considerations
+
+10.1. Media Type Registration
+
+ IANA has registered the following Media Type (in
+ <http://www.iana.org/>) and marked the text/directory Media Type as
+ DEPRECATED.
+
+ To: ietf-types@iana.org
+
+ Subject: Registration of media type text/vcard
+
+ Type name: text
+
+ Subtype name: vcard
+
+ Required parameters: none
+
+ Optional parameters: version
+
+ The "version" parameter is to be interpreted identically as the
+ VERSION vCard property. If this parameter is present, all vCards
+ in a text/vcard body part MUST have a VERSION property with value
+ identical to that of this MIME parameter.
+
+ "charset": as defined for text/plain [RFC2046]; encodings other
+ than UTF-8 [RFC3629] MUST NOT be used.
+
+ Encoding considerations: 8bit
+
+ Security considerations: See Section 9.
+
+ Interoperability considerations: The text/vcard media type is
+ intended to identify vCard data of any version. There are older
+ specifications of vCard [RFC2426][vCard21] still in common use.
+ While these formats are similar, they are not strictly compatible.
+ In general, it is necessary to inspect the value of the VERSION
+ property (see Section 6.7.9) for identifying the standard to which
+ a given vCard object conforms.
+
+ In addition, the following media types are known to have been used
+ to refer to vCard data. They should be considered deprecated in
+ favor of text/vcard.
+
+ * text/directory
+ * text/directory; profile=vcard
+ * text/x-vcard
+
+
+
+
+Perreault Standards Track [Page 58]
+
+RFC 6350 vCard August 2011
+
+
+ Published specification: RFC 6350
+
+ Applications that use this media type: They are numerous, diverse,
+ and include mail user agents, instant messaging clients, address
+ book applications, directory servers, and customer relationship
+ management software.
+
+ Additional information:
+
+ Magic number(s):
+
+ File extension(s): .vcf .vcard
+
+ Macintosh file type code(s):
+
+ Person & email address to contact for further information: vCard
+ discussion mailing list <vcarddav@ietf.org>
+
+ Intended usage: COMMON
+
+ Restrictions on usage: none
+
+ Author: Simon Perreault
+
+ Change controller: IETF
+
+10.2. Registering New vCard Elements
+
+ This section defines the process for registering new or modified
+ vCard elements (i.e., properties, parameters, value data types, and
+ values) with IANA.
+
+10.2.1. Registration Procedure
+
+ The IETF has created a mailing list, vcarddav@ietf.org, which can be
+ used for public discussion of vCard element proposals prior to
+ registration. Use of the mailing list is strongly encouraged. The
+ IESG has appointed a designated expert who will monitor the
+ vcarddav@ietf.org mailing list and review registrations.
+
+ Registration of new vCard elements MUST be reviewed by the designated
+ expert and published in an RFC. A Standards Track RFC is REQUIRED
+ for the registration of new value data types that modify existing
+ properties. A Standards Track RFC is also REQUIRED for registration
+ of vCard elements that modify vCard elements previously documented in
+ a Standards Track RFC.
+
+
+
+
+
+Perreault Standards Track [Page 59]
+
+RFC 6350 vCard August 2011
+
+
+ The registration procedure begins when a completed registration
+ template, defined in the sections below, is sent to vcarddav@ietf.org
+ and iana@iana.org. Within two weeks, the designated expert is
+ expected to tell IANA and the submitter of the registration whether
+ the registration is approved, approved with minor changes, or
+ rejected with cause. When a registration is rejected with cause, it
+ can be re-submitted if the concerns listed in the cause are
+ addressed. Decisions made by the designated expert can be appealed
+ to the IESG Applications Area Director, then to the IESG. They
+ follow the normal appeals procedure for IESG decisions.
+
+ Once the registration procedure concludes successfully, IANA creates
+ or modifies the corresponding record in the vCard registry. The
+ completed registration template is discarded.
+
+ An RFC specifying new vCard elements MUST include the completed
+ registration templates, which MAY be expanded with additional
+ information. These completed templates are intended to go in the
+ body of the document, not in the IANA Considerations section.
+
+ Finally, note that there is an XML representation for vCard defined
+ in [RFC6351]. An XML representation SHOULD be defined for new vCard
+ elements.
+
+10.2.2. Vendor Namespace
+
+ The vendor namespace is used for vCard elements associated with
+ commercially available products. "Vendor" or "producer" are
+ construed as equivalent and very broadly in this context.
+
+ A registration may be placed in the vendor namespace by anyone who
+ needs to interchange files associated with the particular product.
+ However, the registration formally belongs to the vendor or
+ organization handling the vCard elements in the namespace being
+ registered. Changes to the specification will be made at their
+ request, as discussed in subsequent sections.
+
+ vCard elements belonging to the vendor namespace will be
+ distinguished by the "VND-" prefix. This is followed by an IANA-
+ registered Private Enterprise Number (PEN), a dash, and a vCard
+ element designation of the vendor's choosing (e.g., "VND-123456-
+ MUDPIE").
+
+ While public exposure and review of vCard elements to be registered
+ in the vendor namespace are not required, using the vcarddav@ietf.org
+ mailing list for review is strongly encouraged to improve the quality
+ of those specifications. Registrations in the vendor namespace may
+ be submitted directly to the IANA.
+
+
+
+Perreault Standards Track [Page 60]
+
+RFC 6350 vCard August 2011
+
+
+10.2.3. Registration Template for Properties
+
+ A property is defined by completing the following template.
+
+ Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor-
+ specific property (where NNNN is replaced by the vendor's PEN).
+
+ Property name: The name of the property.
+
+ Purpose: The purpose of the property. Give a short but clear
+ description.
+
+ Value type: Any of the valid value types for the property value
+ needs to be specified. The default value type also needs to be
+ specified.
+
+ Cardinality: See Section 6.
+
+ Property parameters: Any of the valid property parameters for the
+ property MUST be specified.
+
+ Description: Any special notes about the property, how it is to be
+ used, etc.
+
+ Format definition: The ABNF for the property definition needs to be
+ specified.
+
+ Example(s): One or more examples of instances of the property need
+ to be specified.
+
+10.2.4. Registration Template for Parameters
+
+ A parameter is defined by completing the following template.
+
+ Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor-
+ specific property (where NNNN is replaced by the vendor's PEN).
+
+ Parameter name: The name of the parameter.
+
+ Purpose: The purpose of the parameter. Give a short but clear
+ description.
+
+ Description: Any special notes about the parameter, how it is to be
+ used, etc.
+
+ Format definition: The ABNF for the parameter definition needs to be
+ specified.
+
+
+
+
+Perreault Standards Track [Page 61]
+
+RFC 6350 vCard August 2011
+
+
+ Example(s): One or more examples of instances of the parameter need
+ to be specified.
+
+10.2.5. Registration Template for Value Data Types
+
+ A value data type is defined by completing the following template.
+
+ Value name: The name of the value type.
+
+ Purpose: The purpose of the value type. Give a short but clear
+ description.
+
+ Description: Any special notes about the value type, how it is to be
+ used, etc.
+
+ Format definition: The ABNF for the value type definition needs to
+ be specified.
+
+ Example(s): One or more examples of instances of the value type need
+ to be specified.
+
+10.2.6. Registration Template for Values
+
+ A value is defined by completing the following template.
+
+ Value: The value literal.
+
+ Purpose: The purpose of the value. Give a short but clear
+ description.
+
+ Conformance: The vCard properties and/or parameters that can take
+ this value needs to be specified.
+
+ Example(s): One or more examples of instances of the value need to
+ be specified.
+
+ The following is a fictitious example of a registration of a vCard
+ value:
+
+ Value: supervisor
+
+ Purpose: It means that the related entity is the direct hierarchical
+ superior (i.e., supervisor or manager) of the entity this vCard
+ represents.
+
+ Conformance: This value can be used with the "TYPE" parameter
+ applied on the "RELATED" property.
+
+
+
+
+Perreault Standards Track [Page 62]
+
+RFC 6350 vCard August 2011
+
+
+ Example(s):
+
+ RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
+
+10.3. Initial vCard Elements Registries
+
+ The IANA has created and will maintain the following registries for
+ vCard elements with pointers to appropriate reference documents. The
+ registries are grouped together under the heading "vCard Elements".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 63]
+
+RFC 6350 vCard August 2011
+
+
+10.3.1. Properties Registry
+
+ The following table has been used to initialize the properties
+ registry.
+
+ +-----------+--------------+-------------------------+
+ | Namespace | Property | Reference |
+ +-----------+--------------+-------------------------+
+ | | SOURCE | RFC 6350, Section 6.1.3 |
+ | | KIND | RFC 6350, Section 6.1.4 |
+ | | XML | RFC 6350, Section 6.1.5 |
+ | | FN | RFC 6350, Section 6.2.1 |
+ | | N | RFC 6350, Section 6.2.2 |
+ | | NICKNAME | RFC 6350, Section 6.2.3 |
+ | | PHOTO | RFC 6350, Section 6.2.4 |
+ | | BDAY | RFC 6350, Section 6.2.5 |
+ | | ANNIVERSARY | RFC 6350, Section 6.2.6 |
+ | | GENDER | RFC 6350, Section 6.2.7 |
+ | | ADR | RFC 6350, Section 6.3.1 |
+ | | TEL | RFC 6350, Section 6.4.1 |
+ | | EMAIL | RFC 6350, Section 6.4.2 |
+ | | IMPP | RFC 6350, Section 6.4.3 |
+ | | LANG | RFC 6350, Section 6.4.4 |
+ | | TZ | RFC 6350, Section 6.5.1 |
+ | | GEO | RFC 6350, Section 6.5.2 |
+ | | TITLE | RFC 6350, Section 6.6.1 |
+ | | ROLE | RFC 6350, Section 6.6.2 |
+ | | LOGO | RFC 6350, Section 6.6.3 |
+ | | ORG | RFC 6350, Section 6.6.4 |
+ | | MEMBER | RFC 6350, Section 6.6.5 |
+ | | RELATED | RFC 6350, Section 6.6.6 |
+ | | CATEGORIES | RFC 6350, Section 6.7.1 |
+ | | NOTE | RFC 6350, Section 6.7.2 |
+ | | PRODID | RFC 6350, Section 6.7.3 |
+ | | REV | RFC 6350, Section 6.7.4 |
+ | | SOUND | RFC 6350, Section 6.7.5 |
+ | | UID | RFC 6350, Section 6.7.6 |
+ | | CLIENTPIDMAP | RFC 6350, Section 6.7.7 |
+ | | URL | RFC 6350, Section 6.7.8 |
+ | | VERSION | RFC 6350, Section 6.7.9 |
+ | | KEY | RFC 6350, Section 6.8.1 |
+ | | FBURL | RFC 6350, Section 6.9.1 |
+ | | CALADRURI | RFC 6350, Section 6.9.2 |
+ | | CALURI | RFC 6350, Section 6.9.3 |
+ +-----------+--------------+-------------------------+
+
+
+
+
+
+
+Perreault Standards Track [Page 64]
+
+RFC 6350 vCard August 2011
+
+
+10.3.2. Parameters Registry
+
+ The following table has been used to initialize the parameters
+ registry.
+
+ +-----------+-----------+------------------------+
+ | Namespace | Parameter | Reference |
+ +-----------+-----------+------------------------+
+ | | LANGUAGE | RFC 6350, Section 5.1 |
+ | | VALUE | RFC 6350, Section 5.2 |
+ | | PREF | RFC 6350, Section 5.3 |
+ | | ALTID | RFC 6350, Section 5.4 |
+ | | PID | RFC 6350, Section 5.5 |
+ | | TYPE | RFC 6350, Section 5.6 |
+ | | MEDIATYPE | RFC 6350, Section 5.7 |
+ | | CALSCALE | RFC 6350, Section 5.8 |
+ | | SORT-AS | RFC 6350, Section 5.9 |
+ | | GEO | RFC 6350, Section 5.10 |
+ | | TZ | RFC 6350, Section 5.11 |
+ +-----------+-----------+------------------------+
+
+10.3.3. Value Data Types Registry
+
+ The following table has been used to initialize the parameters
+ registry.
+
+ +------------------+-------------------------+
+ | Value Data Type | Reference |
+ +------------------+-------------------------+
+ | BOOLEAN | RFC 6350, Section 4.4 |
+ | DATE | RFC 6350, Section 4.3.1 |
+ | DATE-AND-OR-TIME | RFC 6350, Section 4.3.4 |
+ | DATE-TIME | RFC 6350, Section 4.3.3 |
+ | FLOAT | RFC 6350, Section 4.6 |
+ | INTEGER | RFC 6350, Section 4.5 |
+ | LANGUAGE-TAG | RFC 6350, Section 4.8 |
+ | TEXT | RFC 6350, Section 4.1 |
+ | TIME | RFC 6350, Section 4.3.2 |
+ | TIMESTAMP | RFC 6350, Section 4.3.5 |
+ | URI | RFC 6350, Section 4.2 |
+ | UTC-OFFSET | RFC 6350, Section 4.7 |
+ +------------------+-------------------------+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 65]
+
+RFC 6350 vCard August 2011
+
+
+10.3.4. Values Registries
+
+ Separate tables are used for property and parameter values.
+
+ The following table is to be used to initialize the property values
+ registry.
+
+ +----------+------------+-------------------------+
+ | Property | Value | Reference |
+ +----------+------------+-------------------------+
+ | BEGIN | VCARD | RFC 6350, Section 6.1.1 |
+ | END | VCARD | RFC 6350, Section 6.1.2 |
+ | KIND | individual | RFC 6350, Section 6.1.4 |
+ | KIND | group | RFC 6350, Section 6.1.4 |
+ | KIND | org | RFC 6350, Section 6.1.4 |
+ | KIND | location | RFC 6350, Section 6.1.4 |
+ +----------+------------+-------------------------+
+
+ The following table has been used to initialize the parameter values
+ registry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 66]
+
+RFC 6350 vCard August 2011
+
+
+ +------------------------+-----------+--------------+---------------+
+ | Property | Parameter | Value | Reference |
+ +------------------------+-----------+--------------+---------------+
+ | FN, NICKNAME, PHOTO, | TYPE | work | RFC 6350, |
+ | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 |
+ | LANG, TZ, GEO, TITLE, | | | |
+ | ROLE, LOGO, ORG, | | | |
+ | RELATED, CATEGORIES, | | | |
+ | NOTE, SOUND, URL, KEY, | | | |
+ | FBURL, CALADRURI, and | | | |
+ | CALURI | | | |
+ | FN, NICKNAME, PHOTO, | TYPE | home | RFC 6350, |
+ | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 |
+ | LANG, TZ, GEO, TITLE, | | | |
+ | ROLE, LOGO, ORG, | | | |
+ | RELATED, CATEGORIES, | | | |
+ | NOTE, SOUND, URL, KEY, | | | |
+ | FBURL, CALADRURI, and | | | |
+ | CALURI | | | |
+ | TEL | TYPE | text | RFC 6350, |
+ | | | | Section 6.4.1 |
+ | TEL | TYPE | voice | RFC 6350, |
+ | | | | Section 6.4.1 |
+ | TEL | TYPE | fax | RFC 6350, |
+ | | | | Section 6.4.1 |
+ | TEL | TYPE | cell | RFC 6350, |
+ | | | | Section 6.4.1 |
+ | TEL | TYPE | video | RFC 6350, |
+ | | | | Section 6.4.1 |
+ | TEL | TYPE | pager | RFC 6350, |
+ | | | | Section 6.4.1 |
+ | TEL | TYPE | textphone | RFC 6350, |
+ | | | | Section 6.4.1 |
+ | BDAY, ANNIVERSARY | CALSCALE | gregorian | RFC 6350, |
+ | | | | Section 5.8 |
+ | RELATED | TYPE | contact | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | acquaintance | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | friend | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | met | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+
+
+
+
+Perreault Standards Track [Page 67]
+
+RFC 6350 vCard August 2011
+
+
+ | RELATED | TYPE | co-worker | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | colleague | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | co-resident | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | neighbor | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | child | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | parent | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | sibling | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | spouse | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | kin | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | muse | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | crush | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | date | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | sweetheart | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | me | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | | | | and [xfn] |
+ | RELATED | TYPE | agent | RFC 6350, |
+ | | | | Section 6.6.6 |
+ | RELATED | TYPE | emergency | RFC 6350, |
+ | | | | Section 6.6.6 |
+ +------------------------+-----------+--------------+---------------+
+
+
+
+
+Perreault Standards Track [Page 68]
+
+RFC 6350 vCard August 2011
+
+
+11. Acknowledgments
+
+ The authors would like to thank Tim Howes, Mark Smith, and Frank
+ Dawson, the original authors of [RFC2425] and [RFC2426], Pete
+ Resnick, who got this effort started and provided help along the way,
+ as well as the following individuals who have participated in the
+ drafting, review, and discussion of this memo:
+
+ Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil
+ Srivastava, Barry Leiba, Ben Fortuna, Bernard Desruisseaux, Bernie
+ Hoeneisen, Bjoern Hoehrmann, Caleb Richardson, Chris Bryant, Chris
+ Newman, Cyrus Daboo, Daisuke Miyakawa, Dan Brickley, Dan Mosedale,
+ Dany Cauchie, Darryl Champagne, Dave Thewlis, Filip Navara, Florian
+ Zeitz, Helge Hess, Jari Urpalainen, Javier Godoy, Jean-Luc Schellens,
+ Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, Julian Reschke,
+ Kepeng Li, Kevin Marks, Kevin Wu Won, Kurt Zeilenga, Lisa Dusseault,
+ Marc Blanchet, Mark Paterson, Markus Lorenz, Michael Haardt, Mike
+ Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter
+ Saint-Andre, Renato Iannella, Rohit Khare, Sly Gryphon, Stephane
+ Bortzmeyer, Tantek Celik, and Zoltan Ordogh.
+
+12. References
+
+12.1. Normative References
+
+ [CCITT.X520.1988]
+ International Telephone and Telegraph Consultative
+ Committee, "Information Technology - Open Systems
+ Interconnection - The Directory: Selected Attribute
+ Types", CCITT Recommendation X.520, November 1988.
+
+ [IEEE.754.2008]
+ Institute of Electrical and Electronics Engineers,
+ "Standard for Binary Floating-Point Arithmetic",
+ IEEE Standard 754, August 2008.
+
+ [ISO.8601.2000]
+ International Organization for Standardization, "Data
+ elements and interchange formats - Information interchange
+ - Representation of dates and times", ISO Standard 8601,
+ December 2000.
+
+ [ISO.8601.2004]
+ International Organization for Standardization, "Data
+ elements and interchange formats - Information interchange
+ - Representation of dates and times", ISO Standard 8601,
+ December 2004.
+
+
+
+
+Perreault Standards Track [Page 69]
+
+RFC 6350 vCard August 2011
+
+
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ November 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar
+ Attributes for vCard and LDAP", RFC 2739, January 2000.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
+ RFC 3966, December 2004.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, January 2005.
+
+ [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
+ Unique IDentifier (UUID) URN Namespace", RFC 4122,
+ July 2005.
+
+ [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
+ Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ October 2008.
+
+ [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
+ Core Object Specification (iCalendar)", RFC 5545,
+ September 2009.
+
+ [RFC5546] Daboo, C., "iCalendar Transport-Independent
+ Interoperability Protocol (iTIP)", RFC 5546,
+ December 2009.
+
+ [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
+ Languages", BCP 47, RFC 5646, September 2009.
+
+
+
+
+Perreault Standards Track [Page 70]
+
+RFC 6350 vCard August 2011
+
+
+ [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
+ Identifier for Geographic Locations ('geo' URI)",
+ RFC 5870, June 2010.
+
+ [RFC6351] Perreault, S., "xCard: vCard XML Representation",
+ RFC 6351, August 2011.
+
+ [W3C.REC-xml-20081126]
+ Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J.,
+ and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
+ Edition)", World Wide Web Consortium Recommendation REC-
+ xml-20081126, November 2008,
+ <http://www.w3.org/TR/2008/REC-xml-20081126>.
+
+ [xfn] Celik, T., Mullenweg, M., and E. Meyer, "XFN 1.1 profile",
+ <http://gmpg.org/xfn/11>.
+
+12.2. Informative References
+
+ [IANA-TZ] Lear, E. and P. Eggert, "IANA Procedures for Maintaining
+ the Timezone Database", Work in Progress, May 2011.
+
+ [ISO9070] International Organization for Standardization,
+ "Information Processing - SGML support facilities -
+ Registration Procedures for Public Text Owner
+ Identifiers", ISO 9070, April 1991.
+
+ [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+ [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
+ August 1998.
+
+ [RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type
+ for Directory Information", RFC 2425, September 1998.
+
+ [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
+ RFC 2426, September 1998.
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
+ May 2002.
+
+
+
+
+
+
+Perreault Standards Track [Page 71]
+
+RFC 6350 vCard August 2011
+
+
+ [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
+ "Uniform Resource Names (URN) Namespace Definition
+ Mechanisms", BCP 66, RFC 3406, October 2002.
+
+ [RFC3536] Hoffman, P., "Terminology Used in Internationalization in
+ the IETF", RFC 3536, May 2003.
+
+ [RFC4770] Jennings, C. and J. Reschke, Ed., "vCard Extensions for
+ Instant Messaging (IM)", RFC 4770, January 2007.
+
+ [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+ Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
+
+ [RFC5335bis]
+ Yang, A. and S. Steele, "Internationalized Email Headers",
+ Work in Progress, July 2011.
+
+ [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+ Mail Extensions (S/MIME) Version 3.2 Message
+ Specification", RFC 5751, January 2010.
+
+ [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
+ URI Scheme", RFC 6068, October 2010.
+
+ [TZ-DB] Olson, A., "Time zone code and data",
+ <ftp://elsie.nci.nih.gov/pub/>.
+
+ [vCard21] Internet Mail Consortium, "vCard - The Electronic Business
+ Card Version 2.1", September 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 72]
+
+RFC 6350 vCard August 2011
+
+
+Appendix A. Differences from RFCs 2425 and 2426
+
+ This appendix contains a high-level overview of the major changes
+ that have been made in the vCard specification from RFCs 2425 and
+ 2426. It is incomplete, as it only lists the most important changes.
+
+A.1. New Structure
+
+ o [RFC2425] and [RFC2426] have been merged.
+
+ o vCard is now not only a MIME type but a stand-alone format.
+
+ o A proper MIME type registration form has been included.
+
+ o UTF-8 is now the only possible character set.
+
+ o New vCard elements can be registered from IANA.
+
+A.2. Removed Features
+
+ o The CONTEXT and CHARSET parameters are no more.
+
+ o The NAME, MAILER, LABEL, and CLASS properties are no more.
+
+ o The "intl", "dom", "postal", and "parcel" TYPE parameter values
+ for the ADR property have been removed.
+
+ o In-line vCards (such as the value of the AGENT property) are no
+ longer supported.
+
+A.3. New Properties and Parameters
+
+ o The KIND, GENDER, LANG, ANNIVERSARY, XML, and CLIENTPIDMAP
+ properties have been added.
+
+ o [RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI
+ properties, has been merged in.
+
+ o [RFC4770], which defines the IMPP property, has been merged in.
+
+ o The "work" and "home" TYPE parameter values are now applicable to
+ many more properties.
+
+ o The "pref" value of the TYPE parameter is now a parameter of its
+ own, with a positive integer value indicating the level of
+ preference.
+
+ o The ALTID and PID parameters have been added.
+
+
+
+Perreault Standards Track [Page 73]
+
+RFC 6350 vCard August 2011
+
+
+ o The MEDIATYPE parameter has been added and replaces the TYPE
+ parameter when it was used for indicating the media type of the
+ property's content.
+
+Author's Address
+
+ Simon Perreault
+ Viagenie
+ 2875 Laurier, suite D2-630
+ Quebec, QC G1V 2M2
+ Canada
+
+ Phone: +1 418 656 9254
+ EMail: simon.perreault@viagenie.ca
+ URI: http://www.viagenie.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Perreault Standards Track [Page 74]
+