1
2
3
4
5
6
7Internet Engineering Task Force (IETF) K. Li
8Request for Comments: 6474 B. Leiba
9Category: Standards Track Huawei Technologies
10ISSN: 2070-1721 December 2011
11
12
13 vCard Format Extensions: Place of Birth, Place and Date of Death
14
15Abstract
16
17 The base vCard 4.0 specification defines a large number of
18 properties, including date of birth. This specification adds three
19 new properties to vCard 4.0: place of birth, place of death, and date
20 of death.
21
22Status of This Memo
23
24 This is an Internet Standards Track document.
25
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 5741.
31
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 http://www.rfc-editor.org/info/rfc6474.
35
36Copyright Notice
37
38 Copyright (c) 2011 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
40
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
50
51
52
53
54
55
56
57
58Li & Leiba Standards Track [Page 1]
59
60RFC 6474 Birth/Death Extensions December 2011
61
62
63Table of Contents
64
65 1. Introduction ....................................................2
66 1.1. Terminology Used in This Document ..........................2
67 2. Identification Property Extensions ..............................2
68 2.1. Property: BIRTHPLACE .......................................2
69 2.2. Property: DEATHPLACE .......................................3
70 2.3. Property: DEATHDATE ........................................4
71 3. Security Considerations .........................................5
72 4. IANA Considerations .............................................5
73 5. Acknowledgements ................................................5
74 6. Normative References ............................................5
75
761. Introduction
77
78 The base vCard 4.0 specification [RFC6350] defines a large number of
79 properties, including date of birth. This specification adds three
80 new properties to vCard 4.0: place of birth, place of death, and date
81 of death.
82
831.1. Terminology Used in This Document
84
85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
87 document are to be interpreted as described in [RFC2119].
88
89 Syntax specifications shown here use the augmented Backus-Naur Form
90 (ABNF) as described in [RFC5234], and are specified as in the base
91 vCard specification [RFC6350].
92
932. Identification Property Extensions
94
952.1. Property: BIRTHPLACE
96
97 Namespace:
98
99 Property name: BIRTHPLACE
100
101 Purpose: To specify the place of birth of the object the vCard
102 represents.
103
104 Value type: A single text value (default) or a single URI value.
105
106 Cardinality: *1
107
108 Property parameters: VALUE, LANGUAGE
109
110
111
112
113
114Li & Leiba Standards Track [Page 2]
115
116RFC 6474 Birth/Death Extensions December 2011
117
118
119 Description:
120
121 Format definition:
122
123 BIRTHPLACE-param = "VALUE=" ("text" / "uri")
124 BIRTHPLACE-value = text / uri
125 ; Value type and VALUE parameter MUST match.
126
127 BIRTHPLACE-param =/ altid-param / language-param / any-param
128
129 Examples:
130
131 BIRTHPLACE:Babies'R'Us Hospital
132 BIRTHPLACE;VALUE=uri:http://example.com/hospitals/babiesrus.vcf
133 BIRTHPLACE;VALUE=uri:geo:46.769307,-71.283079
134
1352.2. Property: DEATHPLACE
136
137 Namespace:
138
139 Property name: DEATHPLACE
140
141 Purpose: To specify the place of death of the object the vCard
142 represents.
143
144 Value type: A single text value (default) or a single URI value.
145
146 Cardinality: *1
147
148 Property parameters: VALUE, LANGUAGE
149
150 Description:
151
152 Format definition:
153
154 DEATHPLACE-param = "VALUE=" ("text" / "uri")
155 DEATHPLACE-value = text / uri
156 ; Value type and VALUE parameter MUST match.
157
158 DEATHPLACE-param =/ altid-param / language-param / any-param
159
160 Examples:
161
162 DEATHPLACE:Aboard the Titanic\, near Newfoundland
163 DEATHPLACE;VALUE=uri:http://example.com/ships/titanic.vcf
164 DEATHPLACE;VALUE=uri:geo:41.731944,-49.945833
165
166
167
168
169
170Li & Leiba Standards Track [Page 3]
171
172RFC 6474 Birth/Death Extensions December 2011
173
174
1752.3. Property: DEATHDATE
176
177 Namespace:
178
179 Property name: DEATHDATE
180
181 Purpose: To specify the date of death of the object the vCard
182 represents.
183
184 Value type: The default is a single date-and-or-time value. It can
185 also be reset to a single text value.
186
187 Cardinality: *1
188
189 Property parameters: VALUE, CALSCALE, LANGUAGE
190
191 CALSCALE can only be present when the value is a
192 date-and-or-time value and actually contains a date or date-time.
193 LANGUAGE can only be present when the value is text.
194
195 Description: The presence of a DEATHDATE property indicates that the
196 subject of the vCard is known to be dead. The absence
197 of this property makes no statement one way or the
198 other.
199
200 Format definition:
201
202 DEATHDATE-param = DEATHDATE-param-date / DEATHDATE-param-text
203 DEATHDATE-value = date-and-or-time / text
204 ; Value type and VALUE parameter MUST match.
205
206 DEATHDATE-param-date = "VALUE=date-and-or-time" / calscale-param
207 ; calscale-param can only be present when DEATHDATE-value is
208 ; date-and-or-time and actually contains a date or date-time.
209
210 DEATHDATE-param-date = "VALUE=text" / language-param
211
212 DEATHDATE-param =/ altid-param / any-param
213
214 Examples:
215
216 DEATHDATE:19960415
217 DEATHDATE:--0415
218 DEATHDATE;19531015T231000Z
219 DEATHDATE;VALUE=text:circa 1800
220
221
222
223
224
225
226Li & Leiba Standards Track [Page 4]
227
228RFC 6474 Birth/Death Extensions December 2011
229
230
2313. Security Considerations
232
233 The properties defined in this document present no security
234 considerations beyond those in Section 9 of the base vCard
235 specification [RFC6350].
236
2374. IANA Considerations
238
239 IANA has added the following entries to the vCard Properties
240 registry, defined in Section 10.3.1 of [RFC6350].
241
242 +-----------+--------------+------------------------+
243 | Namespace | Property | Reference |
244 +-----------+--------------+------------------------+
245 | | BIRTHPLACE | [RFC6474], Section 2.1 |
246 | | DEATHPLACE | [RFC6474], Section 2.2 |
247 | | DEATHDATE | [RFC6474], Section 2.3 |
248 +-----------+--------------+------------------------+
249
2505. Acknowledgements
251
252 The authors of this document would like to thank Simon Perreault and
253 Pete Resnick, the authors of a draft version of RFC 6350 whence the
254 properties defined herein originated.
255
2566. Normative References
257
258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
259 Requirement Levels", BCP 14, RFC 2119, March 1997.
260
261 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
262 Syntax Specifications: ABNF", STD 68, RFC 5234,
263 January 2008.
264
265 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
266 August 2011.
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Li & Leiba Standards Track [Page 5]
283
284RFC 6474 Birth/Death Extensions December 2011
285
286
287Authors' Addresses
288
289 Kepeng Li
290 Huawei Technologies
291 Huawei Base, Bantian, Longgang District
292 Shenzhen, Guangdong 518129
293 P.R. China
294
295 Phone: +86-755-28974289
296 EMail: likepeng@huawei.com
297
298
299 Barry Leiba
300 Huawei Technologies
301
302 Phone: +1 646 827 0648
303 EMail: barryleiba@computer.org
304 URI: http://internetmessagingtechnology.org/
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338Li & Leiba Standards Track [Page 6]
339
340