From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6474.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc6474.txt (limited to 'doc/rfc/rfc6474.txt') 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] + -- cgit v1.2.3