RubyGems - metanorma-cli - Versions diffs - 1.5.15.pre.alpha → 1.5.15.pre.alpha.2 - Mend

metanorma-cli 1.5.15.pre.alpha → 1.5.15.pre.alpha.2

Files changed (12) hide show

data/exe/rfc6350.adoc DELETED Viewed

@@ -1,3505 +0,0 @@
-= vCard Format Specification
-Simon Perreault <simon.perreault@viagenie.ca>
-:bibliography-database: rfc6350_refs.xml
-:bibliography-passthrough: true
-:bibliography-prepend-empty: false
-:bibliography-hyperlinks: false
-:bibliography-style: rfc-v2
-:doctype: rfc
-:abbrev: vCard
-:obsoletes: 2425, 2426, 4770
-:updates: 2739
-:name: 6350
-:revdate: 2011-08
-:submission-type: IETF
-:status: standard
-:intended-series: full-standard 6350
-:fullname: Simon Perreault
-:lastname: Perreault
-:forename_initials: S.
-:organization: Viagenie
-:email: simon.perreault@viagenie.ca
-:street: 2875 Laurier, suite D2-630
-:region: Quebec, QC
-:code: G1V 2M2
-:country: Canada
-:phone: +1 418 656 9254
-:uri: http://www.viagenie.ca
-:link: urn:issn:2070-1721 item
-:rfcedstyle: yes
-:ipr: pre5378Trust200902
-:inline-definition-lists: true
-:comments: yes
-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.
-[[section1]]
-== 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 <<appendixA>>.
-[[section2]]
-== Conventions
-The key words "[bcp14]#MUST#", "[bcp14]#MUST NOT#", "[bcp14]#REQUIRED#", "[bcp14]#SHALL#", "[bcp14]#SHALL NOT#",
-"[bcp14]#SHOULD#", "[bcp14]#SHOULD NOT#", "[bcp14]#RECOMMENDED#", "[bcp14]#NOT RECOMMENDED#", "[bcp14]#MAY#", and
-"[bcp14]#OPTIONAL#" in this document are to be interpreted as described in
-cite:norm[RFC2119].
-[[section3]]
-== vCard Format Specification
-The text/vcard MIME content type (hereafter known as "vCard"; see
-<<section10_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.
-[[section3_1]]
-=== Charset
-The charset (see cite:info[RFC3536] for internationalization terminology) for
-vCard is UTF-8 as defined in cite:norm[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 <<section10_1>>).
-[[section3_2]]
-===  Line Delimiting and Folding
-Individual lines within vCard are delimited by the cite:norm[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
-[bcp14]#SHOULD# be folded to a maximum width of 75 octets, excluding the line
-break.  Multi-octet characters [bcp14]#MUST# remain contiguous.  The rationale
-for this folding process can be found in cite:norm[RFC5322, suffix=", Section 2.1.1"].
-A logical line [bcp14]#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 [bcp14]#MUST# contain at least one character.  Any
-sequence of CRLF followed immediately by a single white space
-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 [bcp14]#SHOULD# unfold lines in
-such a way as to properly restore the original sequence.
-Note: Unfolding is done differently than in cite:norm[RFC5322].  Unfolding
-in cite:norm[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.
-[[section3_3]]
-=== ABNF Format Definition
-The following ABNF uses the notation of cite:norm[RFC5234], which also defines
-CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT.
-[source,abnf]
-----
-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.
-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
-----
-A line that begins with a white space character is a continuation of
-the previous line, as described in <<section3_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 cite:norm[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
-[bcp14]#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 [bcp14]#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 [bcp14]#SHOULD# be grouped
-together when displayed by an application.  It has no other
-significance.  Implementations that do not understand or support
-grouping [bcp14]#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 cite:norm[RFC5234, suffix=", Section 3.6"]):
-|===
-| Cardinality | Meaning
-|      1      | Exactly one instance per vCard [bcp14]#MUST# be present.
-|      *1     | Exactly one instance per vCard [bcp14]#MAY# be present.
-|      1*     | One or more instances per vCard [bcp14]#MUST# be present.
-|      *      | One or more instances per vCard [bcp14]#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).
-[[section3_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 [bcp14]#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 [bcp14]#MUST# be escaped with a BACKSLASH
-character.  SEMICOLON characters in non-compound properties [bcp14]#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 [bcp14]#MUST# be escaped with a BACKSLASH
-character, even for fields that don't allow multiple values (for
-consistency).  Compound properties allowing multiple instances [bcp14]#MUST NOT#
-be encoded in a single content line.
-Finally, BACKSLASH characters in values [bcp14]#MUST# be escaped with a
-BACKSLASH character.  NEWLINE (U+000A) characters in values [bcp14]#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 [bcp14]#MUST NOT# be used.
-[[section4]]
-==  Property Value Data Types
-Standard value types are defined below.
-[source,abnf]
-----
-  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.
-  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]
-  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.
-----
-[[section4_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 <<section5_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 [bcp14]#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.
-[[section4_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 cite:norm[RFC3986, prefix="Section 3 of "].  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
-....
-[[section4_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
-cite:norm[ISO.8601.2004].  Multiple such values can be specified using the
-comma-separated notation.
-Only the basic format is supported.
-[[section4_3_1]]
-====  DATE
-A calendar date as specified in cite:norm[ISO.8601.2004, suffix=", Section 4.1.2"].
-Reduced accuracy, as specified in cite:norm[ISO.8601.2004, suffix=", Sections 4.1.2.3"] a)
-and b), but not c), is permitted.
-Expanded representation, as specified in cite:norm[ISO.8601.2004, suffix=", Section 4.1.4"], is forbidden.
-Truncated representation, as specified in cite:norm[ISO.8601.2000, suffix=", Sections 5.2.1.3"] d), e), and f), is permitted.
-Examples for "date":
-....
-          19850412
-          1985-04
-          1985
-          --0412
-          ---12
-....
-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.
-[[section4_3_2]]
-====  TIME
-A time of day as specified in cite:norm[ISO.8601.2004, suffix=", Section 4.2"].
-Reduced accuracy, as specified in cite:norm[ISO.8601.2004, suffix=", Section 4.2.2.3"],
-is permitted.
-Representation with decimal fraction, as specified in
-cite:norm[ISO.8601.2004, suffix=", Section 4.2.2.4"], is forbidden.
-The midnight hour is always represented by 00, never 24 (see
-cite:norm[ISO.8601.2004, suffix=", Section 4.2.3"]).
-Truncated representation, as specified in cite:norm[ISO.8601.2000, suffix=", Sections 5.3.1.4"] a), b), and c), is permitted.
-Examples for "time":
-....
-          102200
-          1022
-          10
-          -2200
-          --00
-          102200Z
-          102200-0800
-....
-[[section4_3_3]]
-====  DATE-TIME
-A date and time of day combination as specified in cite:norm[ISO.8601.2004, suffix=", Section 4.3"].
-Truncation of the date part, as specified in cite:norm[ISO.8601.2000, suffix=", Section 5.4.2"] c), is permitted.
-Examples for "date-time":
-....
-          19961022T140000
-          --1022T1400
-          ---22T14
-....
-[[section4_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
-....
-[[section4_3_5]]
-====  TIMESTAMP
-A complete date and time of day combination as specified in
-cite:norm[ISO.8601.2004, suffix=", Section 4.3.2"].
-Examples for "timestamp":
-....
-          19961022T140000
-          19961022T140000Z
-          19961022T140000-05
-          19961022T140000-0500
-....
-[[section4_4]]
-===  BOOLEAN
-"boolean": The "boolean" value type is used to express boolean
-values.  These values are case-insensitive.
-Examples: ::
-....
-    TRUE
-    false
-    True
-....
-[[section4_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
-....
-[[section4_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 [bcp14]#MUST# support a precision equal or better than that of
-the IEEE "binary64" format cite:norm[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
-....
-[[section4_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
-[bcp14]#MUST# be used.
-[[section4_8]]
-===  LANGUAGE-TAG
-"language-tag": A single language tag, as defined in cite:norm[RFC5646].
-[[section5]]
-==  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 [bcp14]#MUST# be
-specified as quoted-string text values.  Property parameter values
-[bcp14]#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 [bcp14]#MUST# ignore x-param and iana-param values they don't
-recognize.
-[[section5_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 cite:info[RFC3282].  The value of the LANGUAGE property parameter is a
-language tag as defined in cite:norm[RFC5646, prefix="Section 2 of "].
-Examples: ::
-....
-  ROLE;LANGUAGE=tr:hoca
-....
-ABNF: ::
-[source,abnf]
-----
-        language-param = "LANGUAGE=" Language-Tag
-          ; Language-Tag is defined in section 2.1 of RFC 5646
-----
-[[section5_2]]
-===  VALUE
-The VALUE parameter is [bcp14]#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
-predefined data type values [bcp14]#MUST NOT# be repeated in COMMA-separated
-value lists except within the N, NICKNAME, ADR, and CATEGORIES
-properties.
-ABNF: ::
-[source,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
-----
-[[section5_3]]
-===  PREF
-The PREF parameter is [bcp14]#OPTIONAL# and is used to indicate that the
-corresponding instance of a property is preferred by the vCard
-author.  Its value [bcp14]#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 [bcp14]#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, [bcp14]#MUST NOT#
-be interpreted on its own.
-This parameter [bcp14]#MAY# be applied to any property that allows multiple
-instances.
-ABNF: ::
-[source,abnf]
-----
-        pref-param = "PREF=" (1*2DIGIT / "100")
-                             ; An integer between 1 and 100.
-----
-[[section5_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 (<<section5_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 [bcp14]#MUST NOT# be considered an alternative
-representation of any other property instance.  Values for the ALTID
-parameter are not globally unique: they [bcp14]#MAY# be reused for different
-property names.
-Property instances having the same ALTID parameter value count as 1
-toward cardinality.  Therefore, since N (<<section6_2_2>>) has
-cardinality *1 and TITLE (<<section6_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.)
-....
-....
-  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 [bcp14]#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: ::
-[source,abnf]
-----
-        altid-param = "ALTID=" param-value
-----
-[[section5_5]]
-===  PID
-The PID parameter is used to identify a specific property among
-multiple instances.  It plays a role analogous to the UID property
-(<<section6_7_6>>) on a per-property instead of per-vCard basis.  It [bcp14]#MAY#
-appear more than once in a given property.  It [bcp14]#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
-<<section7>> for more details on its usage.
-ABNF: ::
-[source,abnf]
-----
-        pid-param = "PID=" pid-value *("," pid-value)
-        pid-value = 1*DIGIT ["." 1*DIGIT]
-----
-[[section5_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,
-NOTE, SOUND, URL, KEY, FBURL, CALADRURI, and CALURI.  The TYPE
-parameter [bcp14]#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: ::
-[source,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.
-----
-[[section5_7]]
-===  MEDIATYPE
-The MEDIATYPE parameter is used with properties whose value is a URI.
-Its use is [bcp14]#OPTIONAL#.  It provides a hint to the vCard consumer
-application about the media type cite:norm[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 cite:info[RFC2397].  Another scheme, "http",
-provides the media type as part of the URI resolution process, with
-the Content-Type HTTP header cite:info[RFC2616].  The MEDIATYPE parameter is
-intended to be used with URI schemes that do not provide such
-functionality (e.g., "ftp" cite:info[RFC1738]).
-ABNF: ::
-[source,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]
-----
-cite:norm[RFC2045, text="<xref target='RFC2045' format='none'/>"] cite:norm[RFC4288, text="<xref target='RFC4288' format='none'/>"]
-[[section5_8]]
-===  CALSCALE
-The CALSCALE parameter is identical to the CALSCALE property in
-iCalendar (see cite:norm[RFC5545, suffix=", 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
-registered with IANA (see <<section10_3_4>>).  A vCard implementation
-[bcp14]#MUST# ignore properties with a CALSCALE parameter value that it does
-not understand.
-ABNF: ::
-[source,abnf]
-----
-        calscale-param = "CALSCALE=" calscale-value
-        calscale-value = "gregorian" / iana-token / x-name
-----
-[[section5_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 [bcp14]#MUST# have as
-many or fewer elements as the corresponding property value has
-components.  This parameter's value is case-sensitive.
-ABNF: ::
-[source,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;;
-....
-....
-        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
-....
-[[section5_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 <<section6_5_2>>).
-ABNF: ::
-[source,abnf]
-----
-  geo-parameter = "GEO=" DQUOTE URI DQUOTE
-----
-[[section5_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: ::
-[source,abnf]
-----
-  tz-parameter = "TZ=" (param-value / DQUOTE URI DQUOTE)
-----
-[[section6]]
-==  vCard Properties
-What follows is an enumeration of the standard vCard properties.
-[[section6_1]]
-===  General Properties
-[[section6_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 [bcp14]#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: ::
-+
-[source,abnf]
-----
-  BEGIN-param = 0" "  ; no parameter allowed
-  BEGIN-value = "VCARD"
-----
-Example: ::
-+
-....
-      BEGIN:VCARD
-....
-[[section6_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 [bcp14]#MUST# end with the END type with a
-   value of "VCARD".  The value is case-insensitive.
-+
-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: ::
-+
-[source,abnf]
-----
-  END-param = 0" "  ; no parameter allowed
-  END-value = "VCARD"
-----
-Example: ::
-....
-      END:VCARD
-....
-[[section6_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 cite:norm[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,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
-....
-+
-....
-  SOURCE:http://directory.example.com/addressbooks/jdoe/
-   Jean%20Dupont.vcf
-....
-[[section6_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, [bcp14]#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.
-"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 [bcp14]#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
-      <<section10_3_4>>).  A new value's specification document [bcp14]#MUST#
-      specify which properties make sense for that new kind of vCard
-      and which do not.
-Implementations [bcp14]#MUST# support the specific string values defined
-   above.  If this property is absent, "individual" [bcp14]#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 [bcp14]#SHOULD# act in a neutral way, which usually
-   means treating the vCard as though its kind were "individual".
-   The presence of MEMBER properties [bcp14]#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.
-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: ::
-+
-[source,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
-....
-[[section6_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
-   cite:norm[W3C.REC-xml-20081126] element whose namespace [bcp14]#MUST# be explicitly
-   specified using the xmlns attribute and [bcp14]#MUST NOT# be the vCard 4
-   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 cite:norm[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 [bcp14]#OPTIONAL#, but implementations of this
-   specification [bcp14]#MUST# preserve instances of this property when
-   propagating vCards.
-+
-See cite:norm[RFC6351] for more information on the intended use of this
-   property.
-ABNF: ::
-+
-[source,abnf]
-----
-  XML-param = "VALUE=text" / altid-param
-  XML-value = text
-----
-[[section6_2]]
-===  Identification Properties
-These types are used to capture information associated with the
-identification and naming of the entity associated with the vCard.
-[[section6_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 cite:norm[CCITT.X520.1988].  The property [bcp14]#MUST# be
-   present in the vCard object.
-ABNF: ::
-+
-[source,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.
-....
-[[section6_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 cite:norm[CCITT.X520.1988].  The property [bcp14]#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 [bcp14]#MAY# be applied to this property.
-ABNF: ::
-+
-[source,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.
-....
-[[section6_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: :: *
-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: ::
-+
-[source,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
-....
-[[section6_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: ::
-+
-[source,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...>
-....
-[[section6_2_5]]
-====  BDAY
-Purpose: :: To specify the birth date 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: ::
-+
-[source,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
-....
-[[section6_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: ::
-+
-[source,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
-....
-[[section6_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: ::
-+
-[source,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
-....
-[[section6_3]]
-=== Delivery Addressing Properties
-These types are concerned with information related to the delivery
-addressing or label for the vCard object.
-[[section6_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).
-Cardinality: :: *
-Special notes: :: The structured type value consists of a sequence of
-   address components.  The component values [bcp14]#MUST# be specified in
-   their corresponding position.  The structured type value
-   corresponds, in sequence, to
-+
-[empty]
-* 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
-      <<section5_1>>).
-When a component value is missing, the associated component
-   separator [bcp14]#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 [bcp14]#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 [bcp14]#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: ::
-+
-[source,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
-  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.
-....
-[[section6_4]]
-===  Communications Properties
-These properties describe information about how to communicate with
-the object the vCard represents.
-[[section6_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 [bcp14]#SHOULD# be reset to a
-   URI value.  It is expected that the URI scheme will be "tel", as
-   specified in cite:norm[RFC3966], but other schemes [bcp14]#MAY# be used.
-Cardinality: :: *
-Special notes: :: This property is based on the X.520 Telephone Number
-   attribute cite:norm[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:
-[cols="2"]
-|===
-| 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 (<<section6_4_3>>) property [bcp14]#SHOULD# be
-   used in addition to this property.
-ABNF: ::
-+
-[source,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.
-----
-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
-....
-[[section6_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 cite:norm[RFC5322, suffix=", Section 3.4.1"].  Readers should also be aware
-   of the current work toward internationalized email addresses
-   cite:info[RFC5335bis].
-ABNF: ::
-+
-[source,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
-....
-[[section6_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.
-+
-If this property's value is a URI that can be used for voice
-and/or video, the TEL property (<<section6_4_1>>) [bcp14]#SHOULD# be used in
-addition to this property.
-+
-This property is adapted from cite:info[RFC4770], which is made obsolete by
-   this document.
-ABNF: ::
-+
-[source,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
-....
-[[section6_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: ::
-+
-[source,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
-....
-[[section6_5]]
-===  Geographical Properties
-These properties are concerned with information associated with
-geographical positions or regions associated with the object the
-vCard represents.
-[[section6_5_1]]
-====  TZ
-Purpose: :: To specify information related to the time zone of the
-   object the vCard represents.
-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 cite:info[TZ-DB] will be used, but this is not a
-   restriction.  See also cite:info[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 [bcp14]#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: ::
-+
-[source,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.
-....
-[[section6_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 cite:norm[RFC5870] is particularly well
-   suited for this property, but other schemes [bcp14]#MAY# be used.
-ABNF: ::
-+
-[source,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
-....
-[[section6_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.
-[[section6_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
-   cite:norm[CCITT.X520.1988].
-ABNF: ::
-+
-[source,abnf]
-----
-  TITLE-param = "VALUE=text" / language-param / pid-param
-              / pref-param / altid-param / type-param / any-param
-  TITLE-value = text
-----
-Example: ::
-+
-....
-        TITLE:Research Scientist
-....
-[[section6_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: :: *
-Special notes:  This property is based on the X.520 Business Category
-   explanatory attribute cite:norm[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: ::
-+
-[source,abnf]
-----
-  ROLE-param = "VALUE=text" / language-param / pid-param / pref-param
-             / type-param / altid-param / any-param
-  ROLE-value = text
-----
-Example: ::
-+
-....
-        ROLE:Project Leader
-....
-[[section6_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: ::
-+
-[source,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...>
-....
-[[section6_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).
-Cardinality: :: *
-Special notes: ::  The property is based on the X.520 Organization Name
-   and Organization Unit attributes cite:norm[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 [bcp14]#MAY# be applied to this property.
-ABNF: ::
-+
-[source,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
-....
-[[section6_6_5]]
-====  MEMBER
-Purpose: :: To include a member in the group this vCard represents.
-Value type: :: A single URI.  It [bcp14]#MAY# refer to something other than a
-   vCard object.  For example, an email distribution list could
-   employ the "mailto" URI scheme cite:info[RFC6068] for efficiency.
-Cardinality: :: *
-Special notes: :: This property [bcp14]#MUST NOT# be present unless the value of
-   the KIND property is "group".
-ABNF: ::
-+
-[source,abnf]
-----
-  MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param
-               / mediatype-param / any-param
-  MEMBER-value = URI
-----
-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
-....
-[[section6_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 [bcp14]#MAY# be used to characterize the
-   related entity.  It contains a comma-separated list of values that
-   are registered with IANA as described in <<section10_2>>.  The
-   registry is pre-populated with the values defined in cite:norm[xfn].  This
-   document also specifies two additional values:
-agent: ::: an entity who may sometimes act on behalf of the entity
-      associated with the vCard.
-emergency: ::: indicates an emergency contact
-+
-ABNF: ::
-+
-[source,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.
-....
-[[section6_7]]
-===  Explanatory Properties
-These properties are concerned with additional explanations, such as
-that related to informational notes or revisions specific to the
-vCard.
-[[section6_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: :: *
-ABNF: ::
-+
-[source,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
-....
-[[section6_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 cite:norm[CCITT.X520.1988].
-ABNF: ::
-+
-[source,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.
-....
-[[section6_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 [bcp14]#SHOULD# use a method such as that
-   specified for Formal Public Identifiers in cite:info[ISO9070] or for
-   Universal Resource Names in cite:info[RFC3406] to ensure that the text
-   value is unique.
-ABNF: ::
-+
-[source,abnf]
-----
-  PRODID-param = "VALUE=text" / any-param
-  PRODID-value = text
-----
-Example: ::
-+
-....
-        PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
-....
-[[section6_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: ::
-+
-[source,abnf]
-----
-  REV-param = "VALUE=timestamp" / any-param
-  REV-value = timestamp
-----
-Example: ::
-+
-....
-        REV:19951031T222710Z
-....
-[[section6_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: ::
-+
-[source,abnf]
-----
-  SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param
-              / type-param / mediatype-param / altid-param
-              / any-param
-  SOUND-value = URI
-----
-Example: ::
-+
-....
-  SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com
-  SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh
-   AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
-   ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
-   <...the remainder of base64-encoded data...>
-....
-[[section6_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 [bcp14]#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
-   cite:norm[RFC4122] is particularly well suited to this task, but other URI
-   schemes [bcp14]#MAY# be used.  Free-form text [bcp14]#MAY# also be used.
-ABNF: ::
-+
-[source,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
-....
-[[section6_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 cite:norm[RFC4122] is particularly well suited to this
-   task, but other URI schemes [bcp14]#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 [bcp14]#MUST#
-   have an associated CLIENTPIDMAP.  See <<section7>> for more details
-   on the usage of CLIENTPIDMAP.
-+
-PID source identifiers [bcp14]#MUST# be strictly positive.  Zero is not
-   allowed.
-+
-As a special exception, the PID parameter [bcp14]#MUST NOT# be applied to
-   this property.
-ABNF: ::
-+
-[source,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
-....
-[[section6_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.
-ABNF: ::
-+
-[source,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
-....
-[[section6_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 [bcp14]#MUST# be present in the vCard object,
-   and it must appear immediately after BEGIN:VCARD.  The value [bcp14]#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: ::
-+
-[source,abnf]
-----
-  VERSION-param = "VALUE=text" / any-param
-  VERSION-value = "4.0"
-----
-Example: ::
-+
-....
-        VERSION:4.0
-....
-[[section6_8]]
-===  Security Properties
-These properties are concerned with the security of communication
-pathways or access to the vCard.
-[[section6_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: :: *
-ABNF: ::
-+
-[source,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 ...>
-....
-[[section6_9]]
-===  Calendar Properties
-These properties are further specified in cite:norm[RFC2739].
-[[secton6_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 cite:info[RFC1738] or HTTP cite:info[RFC2616] type of URI points to an iCalendar
-   cite:norm[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".
-ABNF: ::
-+
-[source,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
-....
-[[section6_9_2]]
-====  CALADRURI
-Purpose: :: To specify the calendar user address cite:norm[RFC5545] to which a
-   scheduling request cite:norm[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: ::
-+
-[source,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
-....
-[[section6_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 cite:norm[RFC5545]
-   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: ::
-+
-[source,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
-....
-[[section6_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.
-[[section7]]
-==  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.
-[[section7_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.
-[[section7_1_1]]
-====  Matching vCard Instances
-vCard instances for which the UID properties (<<section6_7_6>>) are
-equivalent [bcp14]#MUST# be matched.  Equivalence is determined as specified
-in cite:norm[RFC3986, suffix=", Section 6"].
-In all other cases, vCard instances [bcp14]#MAY# be matched at the discretion
-of the synchronization engine.
-[[section7_1_2]]
-====  Matching Property Instances
-Property instances belonging to unmatched vCards [bcp14]#MUST NOT# be matched.
-Property instances whose name (e.g., EMAIL, TEL, etc.) is not the
-same [bcp14]#MUST NOT# be matched.
-Property instances whose name is CLIENTPIDMAP are handled separately
-and [bcp14]#MUST NOT# be matched.  The synchronization [bcp14]#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, [bcp14]#MUST# be matched.
-Property instances belonging to matched vCards, whose name is the
-same, and whose PID parameters match, [bcp14]#MUST# be matched.  See
-<<section7_1_3>> for details on PID matching.
-In all other cases, property instances [bcp14]#MAY# be matched at the
-discretion of the synchronization engine.
-[[section7_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 cite:norm[RFC3986, suffix=", Section 6"]) also
-represent the same global value.
-PID parameters for which at least one pair of their values represent
-the same global value [bcp14]#MUST# be matched.
-In all other cases, PID parameters [bcp14]#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.
-....
-  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
-....
-[[section7_2]]
-===  Example
-[[section7_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.
-[[section7_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.
-[[section7_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.
-[[section7_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:
-....
-  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
-<<section7_1_2>> state that two properties [bcp14]#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:
-....
-  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
-....
-[[section7_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.
-[[section8]]
-==  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
- 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
-....
-[[section9]]
-==  Security Considerations
-* 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.
-*  vCards can carry cryptographic keys or certificates, as described
-   in <<section6_8_1>>.
-*  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
-   cite:info[RFC5751], OpenPGP cite:info[RFC4880]).  In cases where the confidentiality
-   or authenticity of information contained in vCard is a concern,
-   the vCard [bcp14]#SHOULD# be transported using one of these secure
-   mechanisms.  The KEY property (<<section6_8_1>>) can be used to
-   transport the public key used by these 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
-   SOURCE property (<<section6_1_3>>) [bcp14]#SHOULD# be specified.  In addition,
-   the "REV" type described in <<section6_7_4>> can be specified to
-   indicate the last time that the vCard data was updated.
-*  Many vCard properties may be used to transport URIs.  Please refer
-   to cite:norm[RFC3986, suffix=", Section 7"], for considerations related to URIs.
-[[section10]]
-== IANA Considerations
-[[section10_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 [bcp14]#MUST# have a VERSION property with value
-   identical to that of this MIME parameter.
-+
-"charset": as defined for text/plain cite:norm[RFC2046]; encodings other
-   than UTF-8 cite:norm[RFC3629] [bcp14]#MUST NOT# be used.
-Encoding considerations: :: 8bit
-Security considerations: :: See <<section9>>.
-Interoperability considerations: :: The text/vcard media type is
-   intended to identify vCard data of any version.  There are older
-   specifications of vCard cite:info[RFC2426] cite:info[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 <<section6_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
-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
-[[section10_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.
-[[section10_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 [bcp14]#MUST# be reviewed by the designated
-expert and published in an RFC.  A Standards Track RFC is [bcp14]#REQUIRED#
-for the registration of new value data types that modify existing
-properties.  A Standards Track RFC is also [bcp14]#REQUIRED# for registration
-of vCard elements that modify vCard elements previously documented in
-a Standards Track RFC.
-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 [bcp14]#MUST# include the completed
-registration templates, which [bcp14]#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 cite:norm[RFC6351].  An XML representation [bcp14]#SHOULD# be defined for new vCard
-elements.
-[[section10_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.
-[[section10_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 <<section6>>.
-Property parameters: :: Any of the valid property parameters for the
-   property [bcp14]#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.
-[[section10_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.
-Example(s): :: One or more examples of instances of the parameter need
-   to be specified.
-[[section10_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.
-[[section10_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.
-Example(s): ::
-+
-....
-RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
-....
-[[section10_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".
-[[section10_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
-|===
-[[section10_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
-|===
-[[section10_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
-|===
-[[section10_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.
-[cols="4"]
-|===
-| Property               | Parameter | Value        | Reference
-| FN, NICKNAME, PHOTO,
- ADR, TEL, EMAIL, IMPP,
- LANG, TZ, GEO, TITLE,
- ROLE, LOGO, ORG,
- RELATED, CATEGORIES,
- NOTE, SOUND, URL, KEY,
- FBURL, CALADRURI, and
- CALURI
-| TYPE      | work         | RFC 6350, Section 5.6
-| FN, NICKNAME, PHOTO,
- ADR, TEL, EMAIL, IMPP,
- LANG, TZ, GEO, TITLE,
- ROLE, LOGO, ORG,
- RELATED, CATEGORIES,
- NOTE, SOUND, URL, KEY,
- FBURL, CALADRURI, and
- CALURI
-| TYPE      | home         | RFC 6350, Section 5.6
-| 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 cite:norm[xfn]
-| RELATED   | TYPE      | acquaintance
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | friend
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | met
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | co-worker
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | colleague
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | co-resident
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | neighbor
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | child
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | parent
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | sibling
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | spouse
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | kin
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | muse
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | crush
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | date
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | sweetheart
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | me
-| RFC 6350, Section 6.6.6 and cite:norm[xfn]
-| RELATED   | TYPE      | agent        | RFC 6350, Section 6.6.6
-| RELATED   | TYPE      | emergency    | RFC 6350, Section 6.6.6
-|===
-[[section11]]
-==  Acknowledgments
-The authors would like to thank Tim Howes, Mark Smith, and Frank
-Dawson, the original authors of cite:info[RFC2425] and cite:info[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.
-[bibliography]
-==  Normative References
-++++
-bibliography::norm[]
-++++
-[bibliography]
-==  Informative References
-++++
-bibliography::info[]
-++++
-[[appendixA]]
-== 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.
-[[appendixA_1]]
-===  New Structure
-*  cite:info[RFC2425] and cite:info[RFC2426] have been merged.
-*  vCard is now not only a MIME type but a stand-alone format.
-*  A proper MIME type registration form has been included.
-*  UTF-8 is now the only possible character set.
-*  New vCard elements can be registered from IANA.
-[[appendixA_2]]
-===  Removed Features
-*  The CONTEXT and CHARSET parameters are no more.
-*  The NAME, MAILER, LABEL, and CLASS properties are no more.
-*  The "intl", "dom", "postal", and "parcel" TYPE parameter values
-   for the ADR property have been removed.
-*  In-line vCards (such as the value of the AGENT property) are no
-   longer supported.
-[[appendixA_3]]
-===  New Properties and Parameters
-*  The KIND, GENDER, LANG, ANNIVERSARY, XML, and CLIENTPIDMAP
-   properties have been added.
-*  cite:norm[RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI
-   properties, has been merged in.
-*  cite:info[RFC4770], which defines the IMPP property, has been merged in.
-*  The "work" and "home" TYPE parameter values are now applicable to
-   many more properties.
-*  The "pref" value of the TYPE parameter is now a parameter of its
-   own, with a positive integer value indicating the level of
-   preference.
-*  The ALTID and PID parameters have been added.
-*  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.