1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
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
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
|
Internet Engineering Task Force (IETF) G. Salgueiro
Request for Comments: 6869 J. Clarke
Category: Standards Track P. Saint-Andre
ISSN: 2070-1721 Cisco Systems
February 2013
vCard KIND:device
Abstract
This document defines a value of "device" for the vCard KIND property
so that the vCard format can be used to represent computing devices
such as appliances, computers, or network elements (e.g., a server,
router, switch, printer, sensor, or phone).
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/rfc6869.
Copyright Notice
Copyright (c) 2013 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.
Salgueiro, et al. Standards Track [Page 1]
^L
RFC 6869 vCard KIND:device February 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction
Version 4 of the vCard specification [RFC6350] defines a new "KIND"
property to specify the type of entity that a vCard represents.
During its work on the base vCard4 specification, the VCARDDAV
Working Group defined values of "individual", "org", "group", and
"location" for the KIND property.
During working group discussion of the document that became
[RFC6473], consideration was given to defining a more general value
of "thing", but it was decided to split "thing" into software
applications and hardware devices and to define only the
"application" value at that time. Since then, use cases for device
vCards have emerged. These use cases involve using vCards as a
primer for inventory and asset tracking data specific to network
elements. Therefore, this document complements [RFC6473] by defining
a value of "device" for the KIND property to represent computing
devices such as appliances, computers, or network elements. In this
context, the concept of a device is constrained to computing devices
and thus is distinct from purely mechanical devices such as
elevators, electric generators, etc., that cannot communicate in any
way over a network. This does not preclude, however, network-
attached sensors that are connected to such mechanical devices.
2. Scope
When the KIND property has a value of "device", the vCard represents
a computing device such as an appliance, a computer, or a network
element (e.g., a server, router, switch, printer, sensor, or phone).
More formally, a "device" is functionally equivalent to the "device"
object class used in the Lightweight Directory Access Protocol
[RFC4519] as derived from the Open Systems Interconnection model
[X.521] [X.200]. However, whereas [X.521] specifies that devices are
"physical" elements, a device in this context can also be virtual
such as a virtual machine running within another physical element.
As one example of the "device" KIND, vCards can be embedded into
devices at manufacturing time so that basic information such as
Salgueiro, et al. Standards Track [Page 2]
^L
RFC 6869 vCard KIND:device February 2013
serial number, support email, and documentation URL can be retrieved
upon initial deployment. This vCard can be modified after the device
is deployed to contain user-specified data about the device's
characteristics. The vCard data can therefore be used for both asset
tracking and operational purposes.
A device might have a number of embedded vCards for varying purposes.
The process for discovering and accessing these vCards is
purposefully left unspecified in this document, as this process could
rely on any mechanism that makes sense for the device in question.
For example, a device could have one or more of the following vCard
instances:
o The device itself. For example, the FN ("full name") property
might represent the hostname of a computing device; the URL
property might represent a website that contains details on where
to find documentation or get further information about the device;
the KEY property might represent a digital certificate that was
provisioned into the device at the time of manufacture
[IEEE.802.1AR], or a public key certificate previously provisioned
into the device; and the ADR, GEO, and TZ properties might
represent the physical address, geographical location, and time
zone where the device is deployed.
o An organization or person that produces or manufactures the
device.
o A person or role that maintains or administers the device.
o Application-level vCards as described in [RFC6473] for each
application installed on the device.
When a device has vCards other than its KIND:device vCard, those
vCards can be linked together with RELATED (see the definition of the
RELATED organizational property in Section 6.6.6 of [RFC6350]). In
multi-vCard instances, the KIND:device vCard would use the RELATED
property to express the relationship with the ancillary vCard(s).
Those supplementary vCards need not use RELATED to point back to the
KIND:device vCard. In this manner, the vCard for the device itself
can be easily distinguished from vCards referring to the vendor
organization, device administrator, and installed applications.
Salgueiro, et al. Standards Track [Page 3]
^L
RFC 6869 vCard KIND:device February 2013
The following base properties make sense for vCards that represent
devices (this list is not exhaustive, and other properties might be
applicable as well):
* ADR
* EMAIL
* FN
* GEO
* IMPP
* KEY
* KIND
* LANG
* LOGO
* NOTE
* ORG
* PHOTO
* RELATED
* REV
* SOURCE
* TEL
* TZ
* UID
* URL
Although it might be desirable to define a more fine-grained taxonomy
of devices (e.g., a KIND of "device" with a subtype of "router" or
"computer"), such a taxonomy is out of scope for this document.
3. Example
The following is an example of a router device that contains both
manufacturing details as well as post-deployment attributes and uses
the XML representation of vCard (xCard) described in [RFC6351]. This
vCard points to another, related vCard that contains the details of
an administrative contact for the device. This vCard also leverages
the extensibility of the xCard format to reference additional
namespaces in order to provide richer details about the given device
(e.g., the serial number and software version are specified as xCard
extensions).
Salgueiro, et al. Standards Track [Page 4]
^L
RFC 6869 vCard KIND:device February 2013
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
<kind><text>device</text></kind>
<fn>
<parameters>
<type><text>x-model-name</text></type>
</parameters>
<text>RTR1001</text>
</fn>
<fn><text>core-rtr-1.example.net</text></fn>
<url><uri>http://www.example.com/support/index.html</uri></url>
<email><text>support@example.com</text></email>
<email>
<parameters>
<type><text>x-local-support</text></type>
</parameters>
<text>network-support@example.net</text>
</email>
<impp><uri>xmpp:core-rtr-1@example.net</uri></impp>
<related>
<parameters>
<type><text>contact</text></type>
</parameters>
<uri>urn:uuid:5CEF1870-0326-11E2-A21F-0800200C9A66</uri>
</related>
<logo><uri>http://www.example.com/images/logo.png</uri></logo>
<geo><uri>geo:35.82,-78.64</uri></geo>
<tz><text>America/New_York</text></tz>
<rev><timestamp>20120104T213000Z</timestamp></rev>
<uid><uri>urn:uuid:00CCFB88-155F-40F6-B9D9-B04D134860C0</uri></uid>
<serial-number xmlns='http://example.org/profiles/serial-number'>
FTX1234ABCD
</serial-number>
<note>
<parameters>
<type><text>x-contract-number</text></type>
</parameters>
<text>1234567</text>
</note>
<mac xmlns='http://example.org/profiles/mac'>
00-00-5E-00-00-01
</mac>
<sw-version xmlns='http://example.org/profiles/sw-version'>
2.1.5
</sw-version>
</vcard>
Salgueiro, et al. Standards Track [Page 5]
^L
RFC 6869 vCard KIND:device February 2013
4. IANA Considerations
IANA has added the following entry to the "vCard Property Values"
table of the "vCard Elements" registry
(http://www.iana.org/assignments/vcard-elements):
+----------+--------+---------------------+
| Property | Value | Reference |
+----------+--------+---------------------+
| KIND | device | RFC 6869, Section 3 |
+----------+--------+---------------------+
Table 1: IANA Registration of KIND:device vCard Property Value
In conformance with Section 10.2.6 of [RFC6350], the registration
template is as follows:
Value: device
Purpose: The entity represented by the vCard is a computing device
such as an appliance, computer, or network element.
Conformance: This value can be used with the "KIND" property.
Example: See Section 3 of RFC 6869.
5. Security Considerations
Registration of this vCard KIND to represent devices does not in
itself introduce security considerations beyond those specified for
vCards in general as described in [RFC6350]. Nevertheless, risks can
arise for vulnerable Internet-connected devices as a result of the
publication of the identification details provided by device vCards.
Well-known publicly accessible device vCard repositories, while not
defined in this document, can increase the probability of an
exploitation of an existing vulnerability, especially for devices
with no good way to update their software or firmware. It is the
responsibility of the device administrator to adhere to best current
security practices and employ proper strategies for software upgrades
and security patches in order to mitigate vulnerability to attack.
Specifications defining device-specific vCard extensions or profiles
that might be included in such vCards also need to consider this
potential increased risk.
Salgueiro, et al. Standards Track [Page 6]
^L
RFC 6869 vCard KIND:device February 2013
6. References
6.1. Normative References
[RFC6350] Perreault, S., "vCard Format Specification",
RFC 6350, August 2011.
6.2. Informative References
[IEEE.802.1AR] Institute of Electrical and Electronics Engineers,
"Secure Device Identity", IEEE 802.1AR, 2009.
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519,
June 2006.
[RFC6351] Perreault, S., "xCard: vCard XML Representation",
RFC 6351, August 2011.
[RFC6473] Saint-Andre, P., "vCard KIND:application", RFC 6473,
December 2011.
[X.200] International Telecommunication Union, "Information
Technology - Open Systems Interconnection - Basic
Reference Model: The Basic Model", ITU-T
Recommendation X.521, ISO Standard 9594-7,
February 2001.
[X.521] International Telecommunication Union, "Information
Technology - Open Systems Interconnection - The
Directory: Selected Object Classes", ITU-T
Recommendation X.200, ISO Standard 7498-1, July 1994.
Salgueiro, et al. Standards Track [Page 7]
^L
RFC 6869 vCard KIND:device February 2013
Authors' Addresses
Gonzalo Salgueiro
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
Phone: +1-919-392-3266
EMail: gsalguei@cisco.com
Joe Clarke
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
US
Phone: +1-919-392-2867
EMail: jclarke@cisco.com
Peter Saint-Andre
Cisco Systems
1899 Wynkoop Street, Suite 600
Denver, CO 80202
US
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Salgueiro, et al. Standards Track [Page 8]
^L
|