doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc7095.txt b/doc/rfc/rfc7095.txt
new file mode 100644
index 0000000..f35acc6
--- /dev/null
+++ b/doc/rfc/rfc7095.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        P. Kewisch
+Request for Comments: 7095                                       Mozilla
+Category: Standards Track                                   January 2014
+ISSN: 2070-1721
+
+
+                    jCard: The JSON Format for vCard
+
+Abstract
+
+   This specification defines "jCard", a JSON format for vCard data.
+   The vCard data format is a text format for representing and
+   exchanging information about individuals and other entities, for
+   example, telephone numbers, email addresses, structured names, and
+   delivery addresses.  JSON is a lightweight, text-based, language-
+   independent data interchange format commonly used in Internet
+   applications.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7095.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Kewisch                      Standards Track                    [Page 1]
+
+RFC 7095                          jCard                     January 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
+   3.  Converting from vCard to jCard  . . . . . . . . . . . . . . .   4
+     3.1.  Pre-processing  . . . . . . . . . . . . . . . . . . . . .   4
+     3.2.  jCard Object and Syntactic Entities (RFC 6350, Sections
+           6.1.1 and 6.1.2)  . . . . . . . . . . . . . . . . . . . .   5
+     3.3.  Properties (RFC 6350, Section 6)  . . . . . . . . . . . .   5
+       3.3.1.  Special Cases for Properties  . . . . . . . . . . . .   7
+         3.3.1.1.  The VERSION Property  . . . . . . . . . . . . . .   7
+         3.3.1.2.  Grouping of Properties  . . . . . . . . . . . . .   7
+         3.3.1.3.  Structured Property Values  . . . . . . . . . . .   8
+     3.4.  Parameters (RFC 6350, Section 5)  . . . . . . . . . . . .  10
+       3.4.1.  VALUE Parameter . . . . . . . . . . . . . . . . . . .  10
+       3.4.2.  Multi-Valued Parameters . . . . . . . . . . . . . . .  11
+     3.5.  Values (RFC 6350, Section 4)  . . . . . . . . . . . . . .  11
+       3.5.1.  Text (RFC 6350, Section 4.1)  . . . . . . . . . . . .  12
+       3.5.2.  URI (RFC 6350, Section 4.2) . . . . . . . . . . . . .  12
+       3.5.3.  Date (RFC 6350, Section 4.3.1)  . . . . . . . . . . .  12
+       3.5.4.  Time (RFC 6350, Section 4.3.2)  . . . . . . . . . . .  13
+       3.5.5.  Date-Time (RFC 6350, Section 4.3.3) . . . . . . . . .  14
+       3.5.6.  Date and/or Time (RFC 6350, Section 4.3.4)  . . . . .  16
+       3.5.7.  Timestamp (RFC 6350, Section 4.3.5) . . . . . . . . .  16
+       3.5.8.  Boolean (RFC 6350, Section 4.4) . . . . . . . . . . .  17
+       3.5.9.  Integer (RFC 6350, Section 4.5) . . . . . . . . . . .  17
+       3.5.10. Float (RFC 6350, Section 4.6) . . . . . . . . . . . .  17
+       3.5.11. UTC Offset (RFC 6350, Section 4.7)  . . . . . . . . .  18
+       3.5.12. Language Tag (RFC 6350, Section 4.8)  . . . . . . . .  18
+     3.6.  Extensions (RFC 6350, Section 6.10) . . . . . . . . . . .  18
+   4.  Converting from jCard into vCard  . . . . . . . . . . . . . .  19
+   5.  Handling Unrecognized Properties or Parameters  . . . . . . .  19
+     5.1.  Converting vCard into jCard . . . . . . . . . . . . . . .  19
+     5.2.  Converting jCard into vCard . . . . . . . . . . . . . . .  20
+     5.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  20
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
+     7.1.  GROUP vCard Parameter . . . . . . . . . . . . . . . . . .  23
+     7.2.  UNKNOWN vCard Value Data Type . . . . . . . . . . . . . .  24
+   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  24
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  24
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  25
+   Appendix A.  ABNF Syntax  . . . . . . . . . . . . . . . . . . . .  26
+   Appendix B.  Examples . . . . . . . . . . . . . . . . . . . . . .  27
+     B.1.  Example: vCard of the Author of RFC 6350  . . . . . . . .  27
+       B.1.1.  vCard Data  . . . . . . . . . . . . . . . . . . . . .  27
+       B.1.2.  jCard Data  . . . . . . . . . . . . . . . . . . . . .  28
+
+
+
+Kewisch                      Standards Track                    [Page 2]
+
+RFC 7095                          jCard                     January 2014
+
+
+1.  Introduction
+
+   The vCard data format [RFC6350] provides for the capture and exchange
+   of information normally stored within an address book or directory
+   application.  The vCard format has gone through multiple revisions,
+   most recently vCard 4.
+
+   As certain similarities exist between vCard and the iCalendar data
+   format [RFC5545], there is also an effort to define a JSON-based data
+   format for calendar information called jCal [JCAL] that parallels the
+   format defined in this specification.  The term "JSON" describes the
+   JavaScript Object Notation defined in [RFC4627].
+
+   The purpose of this specification is to define "jCard", a JSON format
+   for vCard data.  One main advantage to using a JSON-based format over
+   the classic vCard format is easier processing for JavaScript-based
+   widgets and libraries, especially in the scope of web-based
+   applications.
+
+   The key design considerations are essentially the same as those for
+   [JCAL] and [RFC6321], that is:
+
+      Round-tripping (converting a vCard instance to jCard and back)
+      will give the same semantic result as the starting point.  For
+      example, all components, properties, and property parameters are
+      guaranteed to be preserved.
+
+      The Ordering of elements and the case of property and parameter
+      names will not necessarily be preserved.
+
+      The vCard data semantics are to be preserved, allowing a simple
+      consumer to easily browse the data in jCard.  A full understanding
+      of vCard is still required in order to modify and/or fully
+      comprehend the directory data.
+
+      Extensions to the underlying vCard specification must not lead to
+      requiring an update to jCard.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The underlying format used for jCard is JSON.  Consequently, the
+   terms "object" and "array" as well as the four primitive types
+   (strings, numbers, booleans, and null) are to be interpreted as
+   described in Section 1 of [RFC4627].
+
+
+
+Kewisch                      Standards Track                    [Page 3]
+
+RFC 7095                          jCard                     January 2014
+
+
+   Some examples in this document contain "partial" JSON documents used
+   for illustrative purposes.  In these examples, three periods "..."
+   are used to indicate a portion of the document that has been removed
+   for compactness.
+
+3.  Converting from vCard to jCard
+
+   This section describes how vCard objects are converted to jCard using
+   a simple mapping between the vCard data model and JSON elements.
+
+   In [RFC6350], vCard objects are comprised of a set of "properties",
+   "parameters", and "values".  The top level of a vCard object contains
+   "properties".  A "property" has a "value" and a set of zero or more
+   "parameters".  Each of these entities has a representation in jCard,
+   defined in the following sections.  The representation of a vCard
+   object in JSON will be named "jCard object" throughout this document.
+
+3.1.  Pre-processing
+
+   vCard uses a line-folding mechanism to limit lines of data to a
+   maximum line length (typically 75 octets) to ensure maximum
+   likelihood of preserving data integrity as it is transported via
+   various means (e.g., email) -- see Section 3.2 of [RFC6350].
+
+   vCard data uses an "escape" character sequence for text values and
+   property parameter values.  See Section 3.4 of [RFC6350] as well as
+   [RFC6868].
+
+   When converting from vCard to jCard, first vCard lines MUST be
+   unfolded.  Afterwards, any vCard escaping MUST be unescaped.
+   Finally, JSON escaping (e.g., for control characters) MUST be
+   applied.
+
+   The reverse order applies when converting from jCard to vCard.
+   First, JSON escaping MUST be unescaped.  Afterwards, vCard escaping
+   MUST be applied.  Finally, long lines SHOULD be folded as described
+   in [RFC6350].
+
+   One key difference in the formatting of values used in vCard and
+   jCard is that in jCard the specification uses date/time values
+   aligned with the extended format of [ISO.8601.2004], which is more
+   commonly used in Internet applications that make use of the JSON
+   format.  The sections of this document describing the various date
+   and time formats contain more information on the use of the complete
+   representation, reduced accuracy, or truncated representation.
+
+
+
+
+
+
+Kewisch                      Standards Track                    [Page 4]
+
+RFC 7095                          jCard                     January 2014
+
+
+3.2.  jCard Object and Syntactic Entities (RFC 6350, Sections 6.1.1 and
+      6.1.2)
+
+   In Sections 6.1.1 and 6.1.2 of [RFC6350], the BEGIN and END
+   properties delimit a syntactic vCard entity.  In jCard, each
+   syntactic entity is represented by an array with two elements and is
+   named "jCard object".  The first element is the string "vcard", and
+   the second element is an array of jCard properties as described in
+   Section 3.3, belonging to the entity.
+
+   Although [RFC6350] defines BEGIN and END to be properties, they MUST
+   NOT appear as properties of the jCard.  Instead, the jCard object is
+   sufficient to define a vCard entity.  When converting from jCard to
+   vCard, the BEGIN and END properties MUST be added to enclose the
+   properties of the jCard object.
+
+   Example:
+
+   ["vcard", [
+     /* Add properties in place of this comment */
+     ]
+   ]
+
+   Consumers of this format wishing to define content that can represent
+   multiple jCard objects within the same JSON document can use a simple
+   JSON array, each element being a single jCard object.
+
+3.3.  Properties (RFC 6350, Section 6)
+
+   Each individual vCard property is represented in jCard by an array
+   with three fixed elements, followed by one or more additional
+   elements, depending on if the property is a multi-valued property as
+   described in Section 3.3 of [RFC6350].
+
+   The array consists of the following fixed elements:
+
+   1.  The name of the property, as a lowercase string.  The vCard
+       format specifies that property names are case insensitive and
+       recommends that they be rendered in uppercase.  In jCard, they
+       MUST be in lowercase.
+
+   2.  An object containing the parameters as described in Section 3.4.
+       If the property has no parameters, an empty object is used to
+       represent that.
+
+
+
+
+
+
+
+Kewisch                      Standards Track                    [Page 5]
+
+RFC 7095                          jCard                     January 2014
+
+
+   3.  The type identifier string of the value, in lowercase.  It is
+       important that parsers check this to determine the data type of
+       the value and that they do not rely on assumptions.  For example,
+       for structured values, the data type will be "array".
+
+   The remaining elements of the array are used for one or more values
+   of the property.  For single-value properties, the array has exactly
+   four elements; for multi-valued properties, each value is another
+   element, and there can be any number of additional elements.
+
+   In the following example, the "categories" property is multi-valued
+   and has two values, while all other properties are single-valued:
+
+   ["vcard",
+     [
+       ["version", {}, "text", "4.0"],
+       ["fn", {}, "text", "John Doe"],
+       ["gender", {}, "text", "M"],
+       ["categories", {}, "text", "computers", "cameras"],
+       ...
+     ]
+   ]
+
+   As described in Section 3.3.1.3, a property value may be a structured
+   property value, in which case it is represented as an array
+   encapsulated in the array that represents the overall property.
+
+   Strictly speaking, this means that the property value is not
+   represented in the format indicated by the type identifier but by an
+   array instead.  However, the values inside the encapsulated array are
+   of the format identified by the type identifier.
+
+   The above also holds for multi-valued properties, where some of the
+   values may be structured property values and therefore are
+   represented as an encapsulated array.
+
+   A special case is where a value in an encapsulated array consists of
+   multiple components itself, in which case it is represented as yet
+   another nested array, with elements matching the value type.
+   Section 3.3.1.3 describes this in more detail.
+
+   The above illustrates that it's important for the parser to check the
+   format of each property value, as it might either directly match the
+   value type, or it might be a structured value where nested
+   subelements match the value type.
+
+
+
+
+
+
+Kewisch                      Standards Track                    [Page 6]
+
+RFC 7095                          jCard                     January 2014
+
+
+3.3.1.  Special Cases for Properties
+
+   This section describes some properties that have special handling
+   when converting to jCard.
+
+3.3.1.1.  The VERSION Property
+
+   The vCard format specification [RFC6350] defines the "VERSION"
+   property to be mandatory.  The jCard "version" property MUST be
+   represented in the corresponding jCard component, with the same value
+   as in the vCard. vCards that conform to RFC 6350 will contain the
+   value "4.0".
+
+   Also in accordance to [RFC6350], the "version" property MUST be the
+   first element of the array containing the properties of a jCard.
+
+3.3.1.2.  Grouping of Properties
+
+   In vCard [RFC6350], related properties can be grouped together using
+   a grouping construct.  The grouping is accomplished by adding a
+   prefix (which consists of the group name followed by a dot) to the
+   property name.
+
+   In jCard, the same grouping is achieved through a "group" parameter
+   that holds the group name.  In jCard, a property name therefore MUST
+   NOT be prefixed by a group name.
+
+   The "GROUP" parameter MUST NOT be used in vCard; as per [RFC6350], it
+   is merely registered to reserve the parameter, avoiding collisions.
+   Formal registration of the "GROUP" parameter is described in
+   Section 7.1.
+
+3.3.1.2.1.  Group Conversion Rules
+
+   In jCard, the parameter's value is a single opaque string.
+   Conversion rules are as follows:
+
+   o  From vCard to jCard, the group construct (see [RFC6350],
+      Section 3.3) is removed.  In its place, the "group" parameter is
+      used.  Its value is a string corresponding to the group name,
+      which is case insensitive both in vCard and jCard.  The name's
+      case SHOULD be converted into lowercase.
+
+   o  When converting from jCard to vCard, the value of the "group"
+      parameter followed by a dot is prefixed to the property name, and
+      the "group" parameter is discarded.  The "GROUP" parameter MUST
+      NOT appear in the resulting vCard.  Following the recommendations
+      in [RFC6350], the name's case SHOULD be converted into uppercase.
+
+
+
+Kewisch                      Standards Track                    [Page 7]
+
+RFC 7095                          jCard                     January 2014
+
+
+   Example:
+
+   CONTACT.FN:Mr. John Q. Public\, Esq.
+
+   is equivalent to:
+
+   [ "fn", { "group": "CONTACT" }, "text", "Mr. John Q. Public, Esq." ]
+
+3.3.1.3.  Structured Property Values
+
+   The vCard specification defines properties with structured values,
+   for example, "GENDER" or "ADR".  In vCard, a structured text value
+   consists of one or multiple text components, delimited by the
+   SEMICOLON character.  Its equivalent in jCard is a structured
+   property value, which is an array containing one element for each
+   text component, with empty/missing text components represented by
+   zero-length strings.
+
+   vCard Example:
+
+   ADR:;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
+
+   jCard Example:
+
+   ["adr", {}, "text",
+     [
+     "", "", "123 Main Street",
+     "Any Town", "CA", "91921-1234", "U.S.A."
+     ]
+   ]
+
+   Some vCard properties, for example, ADR, also allow a structured
+   value element that itself has multiple values.  In this case, the
+   element of the array describing the structured value is itself an
+   array with one element for each of the component's multiple values.
+
+   vCard Example:
+
+   ADR:;;My Street,Left Side,Second Shack;Hometown;PA;18252;U.S.A.
+
+
+
+
+
+
+
+
+
+
+
+
+Kewisch                      Standards Track                    [Page 8]
+
+RFC 7095                          jCard                     January 2014
+
+
+   jCard Example:
+
+   ["adr", {}, "text",
+     [
+     "", "",
+     ["My Street", "Left Side", "Second Shack"],
+     "Hometown", "PA", "18252", "U.S.A."
+     ]
+   ]
+
+   In both cases, the array element values MUST have the primitive type
+   that matches the jCard type identifier.  In [RFC6350], there are only
+   structured text values and thus only JSON strings are used.  For
+   example, extensions may define structured number or boolean values,
+   where JSON number or boolean types MUST be used.
+
+   Although it is allowed for a structured property value to hold just
+   one component, it is RECOMMENDED to represent it as a single text
+   value instead, omitting the array completely.  Nevertheless, a simple
+   implementation MAY choose to retain the array, with a single text
+   value as its element.
+
+   Similarly, structured values that consist of two text components with
+   one being optional (for example, "GENDER") can be represented as a
+   single text value.  Therefore, parsers of jCard data SHOULD check
+   even known property values for structured information by considering
+   the JSON data type of the value, which can be an array or a primitive
+   value.  This is especially important for languages where accessing
+   array members is done by the same construct as accessing characters
+   of a string.
+
+   Examples:
+
+   ["gender", {}, "text", ["F", "grrrl"] ],
+   ["gender", {}, "text", "M" ]
+
+   Per Section 6.3.1 of [RFC6350], the component separator MUST be
+   specified even if the component value is missing.  Similarly, the
+   jCard array containing the structured data MUST contain all required
+   elements, even if they are empty.
+
+   vCard Example:
+
+   ADR;LABEL="123 Maple Ave\nSuite 901\nVancouver BC\nA1B 2C9\nCan
+    ada":;;;;;;
+
+
+
+
+
+
+Kewisch                      Standards Track                    [Page 9]
+
+RFC 7095                          jCard                     January 2014
+
+
+   jCard Example:
+
+   ["adr",
+    {"label":"123 Maple Ave\nSuite 901\nVancouver BC\nA1B 2C9\nCanada"},
+    "text",
+    ["", "", "", "", "", "", ""]
+   ]
+
+3.4.  Parameters (RFC 6350, Section 5)
+
+   Property parameters are represented as a JSON object where each key-
+   value pair represents the vCard parameter name and its value.  The
+   name of the parameter MUST be in lowercase; the original case of the
+   parameter value MUST be preserved.  For example, the "LANGUAGE"
+   property parameter is represented in jCard by the "language" key.
+   Any new vCard parameters added in the future will be converted in the
+   same way.
+
+   Example:
+
+   ["role", { "language": "tr" }, "text", "roca"],
+
+3.4.1.  VALUE Parameter
+
+   vCard defines a "VALUE" property parameter (Section 5.2 of
+   [RFC6350]).  This property parameter MUST NOT be added to the
+   parameters object.  Instead, the value type is signaled through the
+   type identifier in the third element of the array describing the
+   property.  When converting a property from vCard to jCard, the value
+   type is determined as follows:
+
+   1.  If the property has a "VALUE" parameter, that parameter's value
+       is used as the value type.
+
+   2.  If the property has no "VALUE" parameter but has a default value
+       type, the default value type is used.
+
+   3.  If the property has no "VALUE" parameter and has no default value
+       type, "unknown" is used.
+
+   Converting from jCard into vCard is done as follows:
+
+   1.  If the property's value type is "unknown", no "VALUE" parameter
+       is included.
+
+   2.  If the property's value type is the default type for that
+       property, no "VALUE" parameter is included.
+
+
+
+
+Kewisch                      Standards Track                   [Page 10]
+
+RFC 7095                          jCard                     January 2014
+
+
+   3.  Otherwise, a "VALUE" parameter is included, and the value type is
+       used as the parameter value.
+
+   See Section 5 for information on handling unknown value types.
+
+3.4.2.  Multi-Valued Parameters
+
+   In [RFC6350], some parameters allow using a comma-separated list of
+   values.  To ease processing in jCard, the value for such parameters
+   MUST be represented in an array containing the separated values.  The
+   array elements MUST be string values.  Single-value parameters SHOULD
+   be represented using a single string value, although a more simple
+   implementation might prefer an array with one string element.  An
+   example of such a parameter is the vCard "SORT-AS" parameter; more
+   such parameters may be added in extensions.
+
+   The vCard specification requires encapsulation between DQUOTE
+   characters if a parameter value contains a colon, a semicolon, or a
+   comma.  These extra DQUOTE characters do not belong to the actual
+   parameter value and hence are not included when the parameter is
+   converted to jCard.
+
+   Example:
+
+   ["vcard",
+     [
+       ["version", {}, "text", "4.0"],
+       ["n",
+        { "sort-as": ["Harten", "Rene"] },
+        "text",
+        ["van der Harten", "Rene", "J.", "Sir", "R.D.O.N."]
+       ],
+       ["fn", {}, "text", "Rene van der Harten"]
+       ...
+     ]
+   ]
+
+3.5.  Values (RFC 6350, Section 4)
+
+   The following subsections specify how vCard property value data types
+   (which are defined in Section 4 of [RFC6350]) are represented in
+   jCard.
+
+
+
+
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 11]
+
+RFC 7095                          jCard                     January 2014
+
+
+3.5.1.  Text (RFC 6350, Section 4.1)
+
+   Description:  vCard "TEXT" property values are represented by a
+      property with the type identifier "text".  The value elements are
+      JSON strings.  For details on structured text values, see
+      Section 3.3.1.3.
+
+   Example:
+
+   ["kind", {}, "text", "group"]
+
+3.5.2.  URI (RFC 6350, Section 4.2)
+
+   Description:  vCard "URI" property values are represented by a
+      property with the type identifier "uri".  The value elements are
+      JSON strings.
+
+   Example:
+
+   ["source", {}, "uri", "ldap://ldap.example.com/cn=babs%20jensen"]
+
+3.5.3.  Date (RFC 6350, Section 4.3.1)
+
+   Description:  vCard "DATE" property values are represented by a
+      property with the type identifier "date".  The value elements are
+      JSON strings with the same date value specified by [RFC6350], but
+      represented using the extended format specified in
+      [ISO.8601.2004], Section 4.1.2.  If the complete representation is
+      not used, the same date format restrictions regarding reduced
+      accuracy, truncated representation, and expanded representation
+      noted in [RFC6350], Section 4.3.1 apply.  Whenever the extended
+      format is not applicable, the basic format MUST be used.
+
+   ABNF syntax:
+
+   date-complete = year "-" month "-" day ;YYYY-MM-DD
+
+   date-noreduc = date-complete
+              / "--" month "-" day ; --MM-DD
+              / "---" day          ; ---DDD
+
+   date = date-noreduc
+      / year; YYYY
+      / year "-" month ; YYYY-MM
+      / "--" month     ; --MM
+
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 12]
+
+RFC 7095                          jCard                     January 2014
+
+
+   Examples:
+
+   ["bday", {}, "date", "1985-04-12"],
+   ["bday", {}, "date", "1985-04"],
+   ["bday", {}, "date", "1985"],
+   ["bday", {}, "date", "--04-12"],
+   ["bday", {}, "date", "---12"]
+
+   This table contains possible conversions between the vCard DATE
+   format and jCard date.  This information is just an example and not a
+   formal specification of the syntax.  The specification can be found
+   in [ISO.8601.2000] and [ISO.8601.2004].
+
+                   +-----------+----------+------------+
+                   |           | vCard    | jCard      |
+                   +-----------+----------+------------+
+                   | Complete  | 19850412 | 1985-04-12 |
+                   |           |          |            |
+                   | Reduced   | 1985-04  | 1985-04    |
+                   |           |          |            |
+                   | Reduced   | 1985     | 1985       |
+                   |           |          |            |
+                   | Truncated | --0412   | --04-12    |
+                   |           |          |            |
+                   | Truncated | --04     | --04       |
+                   |           |          |            |
+                   | Truncated | ---12    | ---12      |
+                   +-----------+----------+------------+
+
+3.5.4.  Time (RFC 6350, Section 4.3.2)
+
+   Description:  vCard "TIME" property values are represented by a
+      property with the type identifier "time".  The value elements are
+      JSON strings with the same time value specified by [RFC6350], but
+      represented using the extended format specified in
+      [ISO.8601.2004], Section 4.2.  If the complete representation is
+      not used, the same time format restrictions regarding reduced
+      accuracy, decimal fraction, and truncated representation noted in
+      [RFC6350], Section 4.3.2 apply.  Whenever the extended format is
+      not applicable, the basic format MUST be used.  The seconds value
+      of 60 MUST only be used to account for positive "leap" seconds,
+      and the midnight hour is always represented by 00, never 24.
+      Fractions of a second are not supported by this format.  In jCard,
+      UTC offsets are permitted within a time value; note that this
+      differs from jCal [JCAL], where they are not permitted.
+
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 13]
+
+RFC 7095                          jCard                     January 2014
+
+
+   ABNF syntax:
+
+   time-notrunc =  hour [":" minute [":" second]] [zone]
+
+   time = time-notrunc
+      / "-" minute ":" second [zone]; -mm:ss
+      / "-" minute [zone]; -mm
+      / "--" second [zone]; --ss
+
+   Examples:
+
+   ["x-time-local", {}, "time", "12:30:00"],
+   ["x-time-utc", {}, "time", "12:30:00Z"],
+   ["x-time-offset", {}, "time", "12:30:00-08:00"],
+   ["x-time-reduced", {}, "time", "23"],
+   ["x-time-truncated", {}, "time", "-30"]
+
+   This table contains possible conversions between the vCard TIME
+   format and jCard time.  This information is just an example and not a
+   formal specification of the syntax.  The specification can be found
+   in [ISO.8601.2000] and [ISO.8601.2004].
+
+                     +-----------+--------+----------+
+                     |           | vCard  | jCard    |
+                     +-----------+--------+----------+
+                     | Complete  | 232050 | 23:20:50 |
+                     |           |        |          |
+                     | Reduced   | 2320   | 23:20    |
+                     |           |        |          |
+                     | Reduced   | 23     | 23       |
+                     |           |        |          |
+                     | Truncated | -2050  | -20:50   |
+                     |           |        |          |
+                     | Truncated | -20    | -20      |
+                     |           |        |          |
+                     | Truncated | --50   | --50     |
+                     +-----------+--------+----------+
+
+   Also, all combinations may have any zone designator appended, as in
+   the complete representation.
+
+3.5.5.  Date-Time (RFC 6350, Section 4.3.3)
+
+   Description:  vCard "DATE-TIME" property values are represented by a
+      property with the type identifier "date-time".  The value elements
+      are JSON strings with the same date value specified by [RFC6350],
+      but represented using the extended format specified in
+      [ISO.8601.2004], Section 4.3.  If the complete representation is
+
+
+
+Kewisch                      Standards Track                   [Page 14]
+
+RFC 7095                          jCard                     January 2014
+
+
+      not used, the same date and time format restrictions noted in
+      Sections 3.5.3 and 3.5.4 apply.  Just as described in [RFC6350],
+      truncation of the date part is permitted.
+
+   Example:
+
+   ["anniversary", {}, "date-time", "2013-02-14T12:30:00"],
+   ["anniversary", {}, "date-time", "2013-01-10T19:00:00Z"],
+   ["anniversary", {}, "date-time", "2013-08-15T09:45:00+01:00"],
+   ["anniversary", {}, "date-time", "---15T09:45:00+01:00"]
+
+   This table contains possible conversions between the vCard DATE-TIME
+   format and jCard date-time.  This information is just an example and
+   not a formal specification of the syntax.  The specification can be
+   found in [ISO.8601.2000] and [ISO.8601.2004].
+
+   +----------------+----------------------+---------------------------+
+   | Representation | vCard                | jCard                     |
+   +----------------+----------------------+---------------------------+
+   | Complete       | 19850412T232050      | 1985-04-12T23:20:50       |
+   |                |                      |                           |
+   | Complete       | 19850412T232050Z     | 1985-04-12T23:20:50Z      |
+   |                |                      |                           |
+   | Complete       | 19850412T232050+0400 | 1985-04-12T23:20:50+04:00 |
+   |                |                      |                           |
+   | Complete       | 19850412T232050+04   | 1985-04-12T23:20:50+04    |
+   |                |                      |                           |
+   | Reduced        | 19850412T2320        | 1985-04-12T23:20          |
+   |                |                      |                           |
+   | Reduced        | 19850412T23          | 1985-04-12T23             |
+   |                |                      |                           |
+   | Truncated and  | --0412T2320          | --04-12T23:20             |
+   | Reduced        |                      |                           |
+   |                |                      |                           |
+   | Truncated and  | --04T2320            | --04T23:20                |
+   | Reduced        |                      |                           |
+   |                |                      |                           |
+   | Truncated and  | ---12T2320           | ---12T23:20               |
+   | Reduced        |                      |                           |
+   |                |                      |                           |
+   | Truncated and  | --0412T2320          | --04-12T23:20             |
+   | Reduced        |                      |                           |
+   |                |                      |                           |
+   | Truncated and  | --04T23              | --04T23                   |
+   | Reduced        |                      |                           |
+   +----------------+----------------------+---------------------------+
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 15]
+
+RFC 7095                          jCard                     January 2014
+
+
+   As specified in [ISO.8601.2000], the lower-order components may not
+   be omitted in the date part (reduced accuracy) and the higher-order
+   components may not be omitted in the time part (truncation).  Also,
+   all combinations may have any zone designator appended, as in the
+   complete representation.
+
+3.5.6.  Date and/or Time (RFC 6350, Section 4.3.4)
+
+   Description:  vCard "DATE-AND-OR-TIME" property values are
+      represented by a property with the type identifier "date-and-or-
+      time".  The value elements are either a date-time (Section 3.5.5),
+      a date (Section 3.5.3), or a time (Section 3.5.4) value.  Just as
+      described in Section 4.3.4 of [RFC6350], a stand-alone time value
+      MUST always be preceded by a "T".
+
+   Example:
+
+   ["bday", {}, "date-and-or-time", "2013-02-14T12:30:00"],
+   ["bday", {}, "date-and-or-time", "---22T14:00"]
+   ["bday", {}, "date-and-or-time", "1985"],
+   ["bday", {}, "date-and-or-time", "T12:30"]
+
+3.5.7.  Timestamp (RFC 6350, Section 4.3.5)
+
+   Description:  vCard "TIMESTAMP" property values are represented by a
+      property with the type identifier "timestamp".  The value elements
+      are JSON strings with the same timestamp value specified by
+      [RFC6350], but represented using the extended format and complete
+      representation specified in [ISO.8601.2004], Section 4.3.2.
+
+   Example:
+
+   ["rev", {}, "timestamp", "2013-02-14T12:30:00"],
+   ["rev", {}, "timestamp", "2013-02-14T12:30:00Z"],
+   ["rev", {}, "timestamp", "2013-02-14T12:30:00-05"],
+   ["rev", {}, "timestamp", "2013-02-14T12:30:00-05:00"]
+
+   This table contains possible conversions between the vCard TIMESTAMP
+   format and jCard timestamp.  This information is just an example and
+   not a formal specification of the syntax.  The specification can be
+   found in [ISO.8601.2000] and [ISO.8601.2004].
+
+
+
+
+
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 16]
+
+RFC 7095                          jCard                     January 2014
+
+
+   +----------------+----------------------+---------------------------+
+   | Representation | vCard                | jCard                     |
+   +----------------+----------------------+---------------------------+
+   | Complete       | 19850412T232050      | 1985-04-12T23:20:50       |
+   |                |                      |                           |
+   | Complete       | 19850412T232050Z     | 1985-04-12T23:20:50Z      |
+   |                |                      |                           |
+   | Complete       | 19850412T232050+0400 | 1985-04-12T23:20:50+04:00 |
+   |                |                      |                           |
+   | Complete       | 19850412T232050+04   | 1985-04-12T23:20:50+04    |
+   +----------------+----------------------+---------------------------+
+
+3.5.8.  Boolean (RFC 6350, Section 4.4)
+
+   Description:  vCard "BOOLEAN" property values are represented by a
+      property with the type identifier "boolean".  The value element is
+      a JSON boolean value.
+
+   Example:
+
+   ["x-non-smoking", {}, "boolean", true]
+
+3.5.9.  Integer (RFC 6350, Section 4.5)
+
+   Description:  vCard "INTEGER" property values are represented by a
+      property with the type identifier "integer".  The value elements
+      are JSON primitive number values.
+
+   Examples:
+
+   ["x-karma-points", {}, "integer", 42]
+
+   JSON allows decimals (e.g., 3.14) and exponents (e.g., 2e10) to be
+   used in numeric values.  jCard does not prohibit this for "integer"
+   property values.  However, since vCard does not support decimals or
+   exponents in integers, any decimals and exponents MUST be eliminated
+   when converting an "integer" value type property from jCard to vCard.
+
+3.5.10.  Float (RFC 6350, Section 4.6)
+
+   Description:  vCard "FLOAT" property values are represented by a
+      property with the type identifier "float".  The value elements are
+      JSON primitive number values.
+
+   Example:
+
+   ["x-grade", {}, "float", 1.3]
+
+
+
+
+Kewisch                      Standards Track                   [Page 17]
+
+RFC 7095                          jCard                     January 2014
+
+
+   JSON allows exponents (e.g., 2e10) to be used in numeric values.
+   jCard does not prohibit this for "float" property values.  However,
+   since vCard does not support exponents in floats, any exponents MUST
+   be eliminated when converting a "float" value type property from
+   jCard to vCard.
+
+3.5.11.  UTC Offset (RFC 6350, Section 4.7)
+
+   Description:  vCard "UTC-OFFSET" property values are represented by a
+      property with the type identifier "utc-offset".  The value
+      elements are JSON strings with the same UTC offset value specified
+      by [RFC6350], with the exception that the hour and minute
+      components are separated by a ":" character, for consistency with
+      the [ISO.8601.2004] timezone offset, extended format.
+
+   Example:
+
+   // Note: [RFC6350] mentions use of utc-offset
+   // for the TZ property as NOT RECOMMENDED
+   ["tz", {}, "utc-offset", "-05:00"]
+
+3.5.12.  Language Tag (RFC 6350, Section 4.8)
+
+   Description:  vCard "LANGUAGE-TAG" property values are represented by
+      a property with the type identifier "language-tag".  The value
+      elements are JSON strings containing a single language-tag, as
+      defined in [RFC5646].
+
+   Example:
+
+   ["lang", {}, "language-tag", "de"]
+
+3.6.  Extensions (RFC 6350, Section 6.10)
+
+   vCard extension properties and property parameters (those with an
+   "X-" prefix in their name) are handled in the same way as other
+   properties and property parameters: the property is represented by an
+   array, the property parameter represented by an object.  The property
+   or parameter name uses the same name as for the vCard extension, but
+   in lowercase.  For example, the "X-FOO" property in vCard turns into
+   the "x-foo" jCard property.  See Section 5 for how to deal with
+   default values for unrecognized extension properties or property
+   parameters.
+
+
+
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 18]
+
+RFC 7095                          jCard                     January 2014
+
+
+4.  Converting from jCard into vCard
+
+   When converting property and property parameter values, the names
+   SHOULD be converted to uppercase.  Although vCard names are case
+   insensitive, common practice is to keep them all uppercase following
+   the actual definitions in [RFC6350].
+
+   Character escaping and line folding MUST be applied to the resulting
+   vCard data as required by [RFC6350] and [RFC6868].
+
+   When converting to vCard, the "VALUE" parameter MUST be added to
+   properties whose default value type is unknown but do not have a
+   jCard type identifier "unknown".  The "VALUE" parameter MAY be
+   omitted for properties using the default value type.  The "VALUE"
+   parameter MUST be omitted for properties that have the jCard type
+   identifier "unknown".
+
+5.  Handling Unrecognized Properties or Parameters
+
+   In vCard, properties can have one or more value types as specified by
+   their definition, with one of those values being defined as the
+   default.  When a property uses its default value type, the "VALUE"
+   property parameter does not need to be specified on the property.
+   For example, "BDAY"'s default value type is "date-and-or-time", so
+   "VALUE=date-and-or-time" need not be set as a property parameter.
+   However, "BDAY" also allows a "text" value to be specified, and if
+   that is used, "VALUE=text" has to be set as a property parameter.
+
+   When new properties are defined or "X-" properties used, a vCard-to-
+   jCard converter might not recognize them, and not know what the
+   appropriate default value types are, yet it needs to be able to
+   preserve the values.  A similar issue arises for unrecognized
+   property parameters.
+
+   In jCard, a new "unknown" property value type is introduced.  Its
+   purpose is to allow preserving unknown property values when round-
+   tripping between jCard and vCard.  To avoid collisions, this
+   specification reserves the "UNKNOWN" property value type in vCard.
+   It MUST NOT be used in any vCard as specified by [RFC6350], nor any
+   extensions to it.  The type is hence registered to the "vCard Value
+   Data Types" registry; see Section 7.2.
+
+5.1.  Converting vCard into jCard
+
+   Any property that does not include a "VALUE" property parameter and
+   whose default value type is not known MUST be converted to a
+   primitive JSON string.  The content of that string is the unprocessed
+   value text.  Also, value type MUST be set to "unknown".
+
+
+
+Kewisch                      Standards Track                   [Page 19]
+
+RFC 7095                          jCard                     January 2014
+
+
+   To correctly implement this format, it's critical to use the value
+   type "unknown" when the default value type is not known.  If this
+   requirement is ignored and, for example, "text" is used, additional
+   escaping may occur that breaks round-tripping values.
+
+   Any unrecognized property parameter MUST be converted to a string
+   value, with its content set to the property parameter value text,
+   treated as if it were a "TEXT" value.
+
+5.2.  Converting jCard into vCard
+
+   In jCard, the value type is always explicitly specified.  It is
+   converted to vCard using the vCard "VALUE" parameter, except in the
+   following two cases:
+
+   o  If the value type specified in jCard matches the default value
+      type in vCard, the "VALUE" parameter MAY be omitted.
+
+   o  If the value type specified in jCard is set to "unknown", the
+      "VALUE" parameter MUST NOT be specified.  The value MUST be taken
+      over in vCard without processing.
+
+5.3.  Examples
+
+   The following is an example of an unrecognized vCard property (that
+   uses a "URI" value as its default), and the equivalent jCard
+   representation of that property.
+
+   vCard:
+
+   X-COMPLAINT-URI:mailto:abuse@example.org
+
+   jCard:
+
+   ["x-complaint-uri", {}, "unknown", "mailto:abuse@example.org"]
+
+   The following is an example of how to cope with jCard data where the
+   parser was unable to identify the value type.  Note how the "unknown"
+   value type is not added to the vCard data, and escaping, aside from
+   standard JSON string escaping, is not processed.
+
+   jCard:
+
+   ["x-coffee-data", {}, "unknown", "Stenophylla;Guinea\\,Africa"]
+
+   vCard:
+
+   X-COFFEE-DATA:Stenophylla;Guinea\,Africa
+
+
+
+Kewisch                      Standards Track                   [Page 20]
+
+RFC 7095                          jCard                     January 2014
+
+
+   There are no standard properties in [RFC6350] that have a default
+   type of integer.  Consequently, this example uses the following
+   extended property that we treat as having a default type (namely,
+   integer) known to the parser in order to illustrate how a property
+   with a known default type would be transformed.
+
+   jCard:
+
+   ["x-karma-points", {}, "integer", 95]
+
+   vCard:
+
+   X-KARMA-POINTS:95
+
+   The following is an example of an unrecognized vCard property
+   parameter (that uses a "FLOAT" value as its default) specified on a
+   recognized vCard property, and the equivalent jCard representation of
+   that property and property parameter.
+
+   vCard:
+
+   GENDER;X-PROBABILITY=0.8:M
+
+   jCard:
+
+   ["gender", { "x-probability": "0.8" }, "text", "M"]
+
+6.  Security Considerations
+
+   This specification defines how vCard data can be "translated" between
+   two different data formats -- the original text format and JSON --
+   with a one-to-one mapping to ensure all the semantic data in one
+   format (properties, parameters, and values) are preserved in the
+   other.  It does not change the semantic meaning of the underlying
+   data itself, or impose or remove any security considerations that
+   apply to the underlying data.
+
+   The use of JSON as a format does have its own inherent security risks
+   as discussed in Section 7 of [RFC4627].  Even though JSON is
+   considered a safe subset of JavaScript, it should be kept in mind
+   that a flaw in the parser for JSON data could still impose a threat
+   that doesn't arise with conventional vCard data.
+
+   With this in mind when using jCard, the parser for JSON data should
+   be aware of the security implications.  For example, the use of
+   JavaScript's eval() function is only allowed using the regular
+   expression in Section 6 of [RFC4627].  A native parser with full
+   awareness of the JSON format should be preferred.
+
+
+
+Kewisch                      Standards Track                   [Page 21]
+
+RFC 7095                          jCard                     January 2014
+
+
+   In addition, it is expected that this new format will result in vCard
+   data being more widely disseminated (e.g., with use in web
+   applications rather than just dedicated "contact managers").
+
+   In all cases, application developers have to conform to the semantics
+   of the vCard data as defined by [RFC6350] and associated extensions,
+   and all of the security considerations described in Section 9 of
+   [RFC6350], or any associated extensions, are applicable.
+
+7.  IANA Considerations
+
+   This document defines a MIME media type for use with vCard in JSON
+   data.  This media type SHOULD be used for the transfer of calendaring
+   data in JSON.
+
+   Type name:  application
+
+   Subtype name:  vcard+json
+
+   Required parameters:  none
+
+   Optional parameters:  "version", as defined for the text/vcard media
+      type in [RFC6350], Section 10.1.
+
+   Encoding considerations:  Same as encoding considerations of
+      application/json as specified in [RFC4627], Section 6.
+
+   Security considerations:  See Section 6.
+
+   Interoperability considerations:  This media type provides an
+      alternative format for vCard data based on JSON.
+
+   Published specification:  This specification.
+
+   Applications which use this media type:  Applications that currently
+      make use of the text/vcard media type can use this as an
+      alternative.  Similarly, applications that use the application/
+      json media type to transfer directory data can use this to further
+      specify the content.
+
+   Fragment identifier considerations:  N/A
+
+
+
+
+
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 22]
+
+RFC 7095                          jCard                     January 2014
+
+
+   Additional information:
+
+      Deprecated alias names for this type:  N/A
+
+      Magic number(s):  N/A
+
+      File extension(s):  N/A
+
+      Macintosh file type code(s):  N/A
+
+   Person & email address to contact for further information:
+      vcarddav@ietf.org
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  There are no restrictions on where this media
+      type can be used.
+
+   Author:  See the "Author's Address" section of this document.
+
+   Change controller:  IETF
+
+7.1.  GROUP vCard Parameter
+
+   IANA has added the "GROUP" parameter to the "vCard Parameters"
+   registry, initialized in Section 10.3.2 of [RFC6350].  Usage of the
+   "GROUP" parameter is further described in Section 3.3.1.2 of this
+   document.
+
+   Namespace:  <empty>
+
+   Parameter name:  GROUP
+
+   Purpose:  To simplify the jCard format.
+
+   Description:  The "GROUP" parameter is reserved for the exclusive use
+      of the jCard format described in this document.  It MUST NOT be
+      used in plain vCard [RFC6350], nor in xCard [RFC6351].
+
+   Format definition:  When converting from jCard to vCard, the value of
+      the "GROUP" parameter is used as part of the property name.
+      Therefore, the value is restricted to characters allowed in
+      property names, namely ALPHA, DIGIT, and "-" characters.  When
+      used, the "GROUP" parameter MUST NOT be empty.
+
+
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 23]
+
+RFC 7095                          jCard                     January 2014
+
+
+   Example:  As this registration serves as a reservation of the "GROUP"
+      parameter so that it is not used in vCard, there is no applicable
+      vCard example.  Examples of its usage in jCard can be found in
+      this document.
+
+7.2.  UNKNOWN vCard Value Data Type
+
+   IANA has added the "UNKNOWN" value data type to the "vCard Value Data
+   Types" registry, initialized in Section 10.3.3 of [RFC6350].  Usage
+   of the "UNKNOWN" type is further described in Section 5 of this
+   document.
+
+   Value name:  UNKNOWN
+
+   Purpose:  To allow preserving property values whose default value
+      type is not known during round-tripping between jCard and vCard.
+
+   Format definition:  (Not applicable)
+
+   Description:  The "UNKNOWN" value data type is reserved for the
+      exclusive use of the jCard format.  It MUST NOT be used in plain
+      vCard [RFC6350].
+
+   Example:  As this registration serves as a reservation of the
+      "UNKNOWN" type so that it is not used in vCard, there is no
+      applicable vCard example.  Examples of its usage in jCard can be
+      found in this document.
+
+8.  Acknowledgments
+
+   The author would like to thank the following for their valuable
+   contributions: Cyrus Daboo, Mike Douglass, William Gill, Erwin Rehme,
+   Dave Thewlis, Simon Perreault, Michael Angstadt, Peter Saint-Andre,
+   Bert Greevenbosch, and Javier Godoy.  This specification originated
+   from the work of the XML-JSON technical committee of the Calendaring
+   and Scheduling Consortium.
+
+9.  References
+
+9.1.  Normative References
+
+   [ISO.8601.2000]
+              International Organization for Standardization, "Data
+              elements and interchange formats -- Information
+              interchange -- Representation of dates and times", ISO
+              8601, December 2000.
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 24]
+
+RFC 7095                          jCard                     January 2014
+
+
+   [ISO.8601.2004]
+              International Organization for Standardization, "Data
+              elements and interchange formats -- Information
+              interchange -- Representation of dates and times", ISO
+              8601, December 2004.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4627]  Crockford, D., "The application/json Media Type for
+              JavaScript Object Notation (JSON)", RFC 4627, July 2006.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC5646]  Phillips, A. and M. Davis, "Tags for Identifying
+              Languages", BCP 47, RFC 5646, September 2009.
+
+   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
+              August 2011.
+
+   [RFC6868]  Daboo, C., "Parameter Value Encoding in iCalendar and
+              vCard", RFC 6868, February 2013.
+
+9.2.  Informative References
+
+   [JCAL]     Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON
+              format for iCalendar", Work in Progress, December 2013.
+
+   [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling
+              Core Object Specification (iCalendar)", RFC 5545,
+              September 2009.
+
+   [RFC6321]  Daboo, C., Douglass, M., and S. Lees, "xCal: The XML
+              Format for iCalendar", RFC 6321, August 2011.
+
+   [RFC6351]  Perreault, S., "xCard: vCard XML Representation", RFC
+              6351, August 2011.
+
+   [calconnect-artifacts]
+              The Calendaring and Scheduling Consortium, "Code Artifacts
+              and Schemas", <http://www.calconnect.org/artifacts.shtml>.
+
+
+
+
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 25]
+
+RFC 7095                          jCard                     January 2014
+
+
+Appendix A.  ABNF Syntax
+
+   Below is the ABNF syntax as per [RFC5234] for vCard in JSON.  ABNF
+   symbols not described here are taken from [RFC4627].  The syntax is
+   non-normative and given for reference only.
+
+   The numeric section numbers given in the comments refer to sections
+   in [RFC6350].  Additional semantic restrictions apply, especially
+   regarding the allowed properties and subcomponents per component.
+   Details on these restrictions can be found in this document and
+   [RFC6350].
+
+   Additional ABNF syntax may be available on the Internet at
+   [calconnect-artifacts].
+
+   ; A jCard object uses the name "vcard" and a properties array.
+   ; Restrictions to which properties may be specified are to
+   ; be taken from RFC 6350.
+   jcardobject = begin-array
+                 DQUOTE component-name DQUOTE value-separator
+                 properties-array
+                 end-array
+
+   ; A jCard property consists of the name string, parameters object,
+   ; type string, and one or more values as specified in this document.
+   property = begin-array
+              DQUOTE property-name DQUOTE value-separator
+              params-object value-separator
+              DQUOTE type-name DQUOTE
+              property-value *(value-separator property-value)
+              end-array
+   properties-array = begin-array
+                      [ property *(value-separator property) ]
+                      end-array
+
+   ; Property values depend on the type-name. Aside from the value types
+   ; mentioned here, extensions may make use of other JSON value types.
+   property-value = simple-prop-value / structured-prop-value
+   simple-prop-value = string / number / true / false
+   structured-prop-value =
+       begin-array
+       [ structured-element *(value-separator structured-element) ]
+       end-array
+
+   ; Each structured element may have multiple values if
+   ; semantically allowed.
+   structured-element = simple-prop-value / structured-multi-prop
+
+
+
+
+Kewisch                      Standards Track                   [Page 26]
+
+RFC 7095                          jCard                     January 2014
+
+
+   structured-multi-prop =
+       begin-array
+       [ simple-prop-value *(value-separator simple-prop-value) ]
+       end-array
+
+   ; The jCard params-object is a JSON object that follows the semantic
+   ; guidelines described in this document.
+   params-object = begin-object
+                   [ params-member *(value-separator params-member) ]
+                   end-object
+   params-member = DQUOTE param-name DQUOTE name-separator param-value
+   param-value = string / param-multi
+   param-multi = begin-array
+                 [ string *(value-separator string) ]
+                 end-array
+
+   ; The type MUST be a valid type as described by this document. New
+   ; value types can be added by extensions.
+   type-name = "text" / "uri" / "date" / "time" / "date-time" /
+               "boolean" / "integer" / "float" / "utc-offset" /
+               "language-tag" / x-type
+
+   ; Property, parameter, and type names MUST be lowercase. Additional
+   ; semantic restrictions apply as described by this document and
+   ; RFC 6350.
+   component-name = lowercase-name
+   property-name = lowercase-name
+   param-name = lowercase-name
+   x-type = lowercase-name
+   lowercase-name = 1*(%x61-7A / DIGIT / "-")
+
+Appendix B.  Examples
+
+   This section contains an example of a vCard object with its jCard
+   representation.
+
+B.1.  Example: vCard of the Author of RFC 6350
+
+B.1.1.  vCard Data
+
+   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
+
+
+
+Kewisch                      Standards Track                   [Page 27]
+
+RFC 7095                          jCard                     January 2014
+
+
+   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
+
+B.1.2.  jCard Data
+
+   ["vcard",
+     [
+       ["version", {}, "text", "4.0"],
+       ["fn", {}, "text", "Simon Perreault"],
+       ["n",
+         {},
+         "text",
+         ["Perreault", "Simon", "", "", ["ing. jr", "M.Sc."]]
+       ],
+       ["bday", {}, "date-and-or-time", "--02-03"],
+       ["anniversary",
+         {},
+         "date-and-or-time",
+         "2009-08-08T14:30:00-05:00"
+       ],
+       ["gender", {}, "text", "M"],
+       ["lang", { "pref": "1" }, "language-tag", "fr"],
+       ["lang", { "pref": "2" }, "language-tag", "en"],
+       ["org", { "type": "work" }, "text", "Viagenie"],
+       ["adr",
+          { "type": "work" },
+          "text",
+          [
+           "",
+           "Suite D2-630",
+           "2875 Laurier",
+           "Quebec",
+           "QC",
+           "G1V 2M2",
+           "Canada"
+          ]
+       ],
+
+
+
+Kewisch                      Standards Track                   [Page 28]
+
+RFC 7095                          jCard                     January 2014
+
+
+       ["tel",
+         { "type": ["work", "voice"], "pref": "1" },
+         "uri",
+         "tel:+1-418-656-9254;ext=102"
+       ],
+       ["tel",
+         { "type": ["work", "cell", "voice", "video", "text"] },
+         "uri",
+         "tel:+1-418-262-6501"
+       ],
+       ["email",
+         { "type": "work" },
+         "text",
+         "simon.perreault@viagenie.ca"
+       ],
+       ["geo", { "type": "work" }, "uri", "geo:46.772673,-71.282945"],
+       ["key",
+         { "type": "work" },
+         "uri",
+         "http://www.viagenie.ca/simon.perreault/simon.asc"
+       ],
+       ["tz", {}, "utc-offset", "-05:00"],
+       ["url", { "type": "home" }, "uri", "http://nomis80.org"]
+     ]
+   ]
+
+Author's Address
+
+   Philipp Kewisch
+   Mozilla Corporation
+   650 Castro Street, Suite 300
+   Mountain View, CA  94041
+   USA
+
+   EMail: mozilla@kewis.ch
+   URI:   http://www.mozilla.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kewisch                      Standards Track                   [Page 29]
+