7Internet Engineering Task Force (IETF) G. Salgueiro
8Request for Comments: 6869 J. Clarke
9Category: Standards Track P. Saint-Andre
10ISSN: 2070-1721 Cisco Systems
18 This document defines a value of "device" for the vCard KIND property
19 so that the vCard format can be used to represent computing devices
20 such as appliances, computers, or network elements (e.g., a server,
21 router, switch, printer, sensor, or phone).
25 This is an Internet Standards Track document.
27 This document is a product of the Internet Engineering Task Force
28 (IETF). It represents the consensus of the IETF community. It has
29 received public review and has been approved for publication by the
30 Internet Engineering Steering Group (IESG). Further information on
31 Internet Standards is available in Section 2 of RFC 5741.
33 Information about the current status of this document, any errata,
34 and how to provide feedback on it may be obtained at
35 http://www.rfc-editor.org/info/rfc6869.
39 Copyright (c) 2013 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (http://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
58Salgueiro, et al. Standards Track [Page 1]
60RFC 6869 vCard KIND:device February 2013
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
67 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
69 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
72 6.2. Informative References . . . . . . . . . . . . . . . . . . 7
76 Version 4 of the vCard specification [RFC6350] defines a new "KIND"
77 property to specify the type of entity that a vCard represents.
78 During its work on the base vCard4 specification, the VCARDDAV
79 Working Group defined values of "individual", "org", "group", and
80 "location" for the KIND property.
82 During working group discussion of the document that became
83 [RFC6473], consideration was given to defining a more general value
84 of "thing", but it was decided to split "thing" into software
85 applications and hardware devices and to define only the
86 "application" value at that time. Since then, use cases for device
87 vCards have emerged. These use cases involve using vCards as a
88 primer for inventory and asset tracking data specific to network
89 elements. Therefore, this document complements [RFC6473] by defining
90 a value of "device" for the KIND property to represent computing
91 devices such as appliances, computers, or network elements. In this
92 context, the concept of a device is constrained to computing devices
93 and thus is distinct from purely mechanical devices such as
94 elevators, electric generators, etc., that cannot communicate in any
95 way over a network. This does not preclude, however, network-
96 attached sensors that are connected to such mechanical devices.
100 When the KIND property has a value of "device", the vCard represents
101 a computing device such as an appliance, a computer, or a network
102 element (e.g., a server, router, switch, printer, sensor, or phone).
103 More formally, a "device" is functionally equivalent to the "device"
104 object class used in the Lightweight Directory Access Protocol
105 [RFC4519] as derived from the Open Systems Interconnection model
106 [X.521] [X.200]. However, whereas [X.521] specifies that devices are
107 "physical" elements, a device in this context can also be virtual
108 such as a virtual machine running within another physical element.
109 As one example of the "device" KIND, vCards can be embedded into
110 devices at manufacturing time so that basic information such as
114Salgueiro, et al. Standards Track [Page 2]
116RFC 6869 vCard KIND:device February 2013
119 serial number, support email, and documentation URL can be retrieved
120 upon initial deployment. This vCard can be modified after the device
121 is deployed to contain user-specified data about the device's
122 characteristics. The vCard data can therefore be used for both asset
123 tracking and operational purposes.
125 A device might have a number of embedded vCards for varying purposes.
126 The process for discovering and accessing these vCards is
127 purposefully left unspecified in this document, as this process could
128 rely on any mechanism that makes sense for the device in question.
129 For example, a device could have one or more of the following vCard
132 o The device itself. For example, the FN ("full name") property
133 might represent the hostname of a computing device; the URL
134 property might represent a website that contains details on where
135 to find documentation or get further information about the device;
136 the KEY property might represent a digital certificate that was
137 provisioned into the device at the time of manufacture
138 [IEEE.802.1AR], or a public key certificate previously provisioned
139 into the device; and the ADR, GEO, and TZ properties might
140 represent the physical address, geographical location, and time
141 zone where the device is deployed.
143 o An organization or person that produces or manufactures the
146 o A person or role that maintains or administers the device.
148 o Application-level vCards as described in [RFC6473] for each
149 application installed on the device.
151 When a device has vCards other than its KIND:device vCard, those
152 vCards can be linked together with RELATED (see the definition of the
153 RELATED organizational property in Section 6.6.6 of [RFC6350]). In
154 multi-vCard instances, the KIND:device vCard would use the RELATED
155 property to express the relationship with the ancillary vCard(s).
156 Those supplementary vCards need not use RELATED to point back to the
157 KIND:device vCard. In this manner, the vCard for the device itself
158 can be easily distinguished from vCards referring to the vendor
159 organization, device administrator, and installed applications.
170Salgueiro, et al. Standards Track [Page 3]
172RFC 6869 vCard KIND:device February 2013
175 The following base properties make sense for vCards that represent
176 devices (this list is not exhaustive, and other properties might be
199 Although it might be desirable to define a more fine-grained taxonomy
200 of devices (e.g., a KIND of "device" with a subtype of "router" or
201 "computer"), such a taxonomy is out of scope for this document.
205 The following is an example of a router device that contains both
206 manufacturing details as well as post-deployment attributes and uses
207 the XML representation of vCard (xCard) described in [RFC6351]. This
208 vCard points to another, related vCard that contains the details of
209 an administrative contact for the device. This vCard also leverages
210 the extensibility of the xCard format to reference additional
211 namespaces in order to provide richer details about the given device
212 (e.g., the serial number and software version are specified as xCard
226Salgueiro, et al. Standards Track [Page 4]
228RFC 6869 vCard KIND:device February 2013
231 <vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
232 <kind><text>device</text></kind>
235 <type><text>x-model-name</text></type>
239 <fn><text>core-rtr-1.example.net</text></fn>
240 <url><uri>http://www.example.com/support/index.html</uri></url>
241 <email><text>support@example.com</text></email>
244 <type><text>x-local-support</text></type>
246 <text>network-support@example.net</text>
248 <impp><uri>xmpp:core-rtr-1@example.net</uri></impp>
251 <type><text>contact</text></type>
253 <uri>urn:uuid:5CEF1870-0326-11E2-A21F-0800200C9A66</uri>
255 <logo><uri>http://www.example.com/images/logo.png</uri></logo>
256 <geo><uri>geo:35.82,-78.64</uri></geo>
257 <tz><text>America/New_York</text></tz>
258 <rev><timestamp>20120104T213000Z</timestamp></rev>
259 <uid><uri>urn:uuid:00CCFB88-155F-40F6-B9D9-B04D134860C0</uri></uid>
260 <serial-number xmlns='http://example.org/profiles/serial-number'>
265 <type><text>x-contract-number</text></type>
269 <mac xmlns='http://example.org/profiles/mac'>
272 <sw-version xmlns='http://example.org/profiles/sw-version'>
282Salgueiro, et al. Standards Track [Page 5]
284RFC 6869 vCard KIND:device February 2013
2874. IANA Considerations
289 IANA has added the following entry to the "vCard Property Values"
290 table of the "vCard Elements" registry
291 (http://www.iana.org/assignments/vcard-elements):
293 +----------+--------+---------------------+
294 | Property | Value | Reference |
295 +----------+--------+---------------------+
296 | KIND | device | RFC 6869, Section 3 |
297 +----------+--------+---------------------+
299 Table 1: IANA Registration of KIND:device vCard Property Value
301 In conformance with Section 10.2.6 of [RFC6350], the registration
302 template is as follows:
306 Purpose: The entity represented by the vCard is a computing device
307 such as an appliance, computer, or network element.
309 Conformance: This value can be used with the "KIND" property.
311 Example: See Section 3 of RFC 6869.
3135. Security Considerations
315 Registration of this vCard KIND to represent devices does not in
316 itself introduce security considerations beyond those specified for
317 vCards in general as described in [RFC6350]. Nevertheless, risks can
318 arise for vulnerable Internet-connected devices as a result of the
319 publication of the identification details provided by device vCards.
320 Well-known publicly accessible device vCard repositories, while not
321 defined in this document, can increase the probability of an
322 exploitation of an existing vulnerability, especially for devices
323 with no good way to update their software or firmware. It is the
324 responsibility of the device administrator to adhere to best current
325 security practices and employ proper strategies for software upgrades
326 and security patches in order to mitigate vulnerability to attack.
327 Specifications defining device-specific vCard extensions or profiles
328 that might be included in such vCards also need to consider this
329 potential increased risk.
338Salgueiro, et al. Standards Track [Page 6]
340RFC 6869 vCard KIND:device February 2013
3456.1. Normative References
347 [RFC6350] Perreault, S., "vCard Format Specification",
348 RFC 6350, August 2011.
3506.2. Informative References
352 [IEEE.802.1AR] Institute of Electrical and Electronics Engineers,
353 "Secure Device Identity", IEEE 802.1AR, 2009.
355 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
356 (LDAP): Schema for User Applications", RFC 4519,
359 [RFC6351] Perreault, S., "xCard: vCard XML Representation",
360 RFC 6351, August 2011.
362 [RFC6473] Saint-Andre, P., "vCard KIND:application", RFC 6473,
365 [X.200] International Telecommunication Union, "Information
366 Technology - Open Systems Interconnection - Basic
367 Reference Model: The Basic Model", ITU-T
368 Recommendation X.521, ISO Standard 9594-7,
371 [X.521] International Telecommunication Union, "Information
372 Technology - Open Systems Interconnection - The
373 Directory: Selected Object Classes", ITU-T
374 Recommendation X.200, ISO Standard 7498-1, July 1994.
394Salgueiro, et al. Standards Track [Page 7]
396RFC 6869 vCard KIND:device February 2013
403 7200-12 Kit Creek Road
404 Research Triangle Park, NC 27709
407 Phone: +1-919-392-3266
408 EMail: gsalguei@cisco.com
413 7200-12 Kit Creek Road
414 Research Triangle Park, NC 27709
417 Phone: +1-919-392-2867
418 EMail: jclarke@cisco.com
423 1899 Wynkoop Street, Suite 600
427 Phone: +1-303-308-3282
428 EMail: psaintan@cisco.com
450Salgueiro, et al. Standards Track [Page 8]