1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc6474.txt b/doc/rfc/rfc6474.txt
new file mode 100644
index 0000000..1a73951
--- /dev/null
+++ b/doc/rfc/rfc6474.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                             K. Li
+Request for Comments: 6474                                      B. Leiba
+Category: Standards Track                            Huawei Technologies
+ISSN: 2070-1721                                            December 2011
+
+
+    vCard Format Extensions: Place of Birth, Place and Date of Death
+
+Abstract
+
+   The base vCard 4.0 specification defines a large number of
+   properties, including date of birth.  This specification adds three
+   new properties to vCard 4.0: place of birth, place of death, and date
+   of death.
+
+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/rfc6474.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+Li & Leiba                   Standards Track                    [Page 1]
+
+RFC 6474                 Birth/Death Extensions            December 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology Used in This Document ..........................2
+   2. Identification Property Extensions ..............................2
+      2.1. Property: BIRTHPLACE .......................................2
+      2.2. Property: DEATHPLACE .......................................3
+      2.3. Property: DEATHDATE ........................................4
+   3. Security Considerations .........................................5
+   4. IANA Considerations .............................................5
+   5. Acknowledgements ................................................5
+   6. Normative References ............................................5
+
+1.  Introduction
+
+   The base vCard 4.0 specification [RFC6350] defines a large number of
+   properties, including date of birth.  This specification adds three
+   new properties to vCard 4.0: place of birth, place of death, and date
+   of death.
+
+1.1.  Terminology 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].
+
+   Syntax specifications shown here use the augmented Backus-Naur Form
+   (ABNF) as described in [RFC5234], and are specified as in the base
+   vCard specification [RFC6350].
+
+2.  Identification Property Extensions
+
+2.1.  Property: BIRTHPLACE
+
+   Namespace:
+
+   Property name:  BIRTHPLACE
+
+   Purpose:  To specify the place of birth of the object the vCard
+             represents.
+
+   Value type:  A single text value (default) or a single URI value.
+
+   Cardinality:  *1
+
+   Property parameters:  VALUE, LANGUAGE
+
+
+
+
+
+Li & Leiba                   Standards Track                    [Page 2]
+
+RFC 6474                 Birth/Death Extensions            December 2011
+
+
+   Description:
+
+   Format definition:
+
+      BIRTHPLACE-param =  "VALUE=" ("text" / "uri")
+      BIRTHPLACE-value =  text / uri
+         ; Value type and VALUE parameter MUST match.
+
+      BIRTHPLACE-param =/  altid-param / language-param / any-param
+
+   Examples:
+
+      BIRTHPLACE:Babies'R'Us Hospital
+      BIRTHPLACE;VALUE=uri:http://example.com/hospitals/babiesrus.vcf
+      BIRTHPLACE;VALUE=uri:geo:46.769307,-71.283079
+
+2.2.  Property: DEATHPLACE
+
+   Namespace:
+
+   Property name:  DEATHPLACE
+
+   Purpose:  To specify the place of death of the object the vCard
+             represents.
+
+   Value type:  A single text value (default) or a single URI value.
+
+   Cardinality:  *1
+
+   Property parameters:  VALUE, LANGUAGE
+
+   Description:
+
+   Format definition:
+
+      DEATHPLACE-param =  "VALUE=" ("text" / "uri")
+      DEATHPLACE-value =  text / uri
+         ; Value type and VALUE parameter MUST match.
+
+      DEATHPLACE-param =/  altid-param / language-param / any-param
+
+   Examples:
+
+      DEATHPLACE:Aboard the Titanic\, near Newfoundland
+      DEATHPLACE;VALUE=uri:http://example.com/ships/titanic.vcf
+      DEATHPLACE;VALUE=uri:geo:41.731944,-49.945833
+
+
+
+
+
+Li & Leiba                   Standards Track                    [Page 3]
+
+RFC 6474                 Birth/Death Extensions            December 2011
+
+
+2.3.  Property: DEATHDATE
+
+   Namespace:
+
+   Property name:  DEATHDATE
+
+   Purpose:  To specify the date of death 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
+
+   Property parameters:  VALUE, CALSCALE, LANGUAGE
+
+      CALSCALE can only be present when the value is a
+      date-and-or-time value and actually contains a date or date-time.
+      LANGUAGE can only be present when the value is text.
+
+   Description:  The presence of a DEATHDATE property indicates that the
+                 subject of the vCard is known to be dead.  The absence
+                 of this property makes no statement one way or the
+                 other.
+
+   Format definition:
+
+      DEATHDATE-param =  DEATHDATE-param-date / DEATHDATE-param-text
+      DEATHDATE-value =  date-and-or-time / text
+         ; Value type and VALUE parameter MUST match.
+
+      DEATHDATE-param-date =  "VALUE=date-and-or-time" / calscale-param
+         ; calscale-param can only be present when DEATHDATE-value is
+         ; date-and-or-time and actually contains a date or date-time.
+
+      DEATHDATE-param-date =  "VALUE=text" / language-param
+
+      DEATHDATE-param =/  altid-param / any-param
+
+   Examples:
+
+      DEATHDATE:19960415
+      DEATHDATE:--0415
+      DEATHDATE;19531015T231000Z
+      DEATHDATE;VALUE=text:circa 1800
+
+
+
+
+
+
+Li & Leiba                   Standards Track                    [Page 4]
+
+RFC 6474                 Birth/Death Extensions            December 2011
+
+
+3.  Security Considerations
+
+   The properties defined in this document present no security
+   considerations beyond those in Section 9 of the base vCard
+   specification [RFC6350].
+
+4.  IANA Considerations
+
+   IANA has added the following entries to the vCard Properties
+   registry, defined in Section 10.3.1 of [RFC6350].
+
+         +-----------+--------------+------------------------+
+         | Namespace | Property     | Reference              |
+         +-----------+--------------+------------------------+
+         |           | BIRTHPLACE   | [RFC6474], Section 2.1 |
+         |           | DEATHPLACE   | [RFC6474], Section 2.2 |
+         |           | DEATHDATE    | [RFC6474], Section 2.3 |
+         +-----------+--------------+------------------------+
+
+5.  Acknowledgements
+
+   The authors of this document would like to thank Simon Perreault and
+   Pete Resnick, the authors of a draft version of RFC 6350 whence the
+   properties defined herein originated.
+
+6.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", STD 68, RFC 5234,
+              January 2008.
+
+   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
+              August 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li & Leiba                   Standards Track                    [Page 5]
+
+RFC 6474                 Birth/Death Extensions            December 2011
+
+
+Authors' Addresses
+
+   Kepeng Li
+   Huawei Technologies
+   Huawei Base, Bantian, Longgang District
+   Shenzhen, Guangdong  518129
+   P.R. China
+
+   Phone: +86-755-28974289
+   EMail: likepeng@huawei.com
+
+
+   Barry Leiba
+   Huawei Technologies
+
+   Phone: +1 646 827 0648
+   EMail: barryleiba@computer.org
+   URI:   http://internetmessagingtechnology.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li & Leiba                   Standards Track                    [Page 6]
+