vCard KIND:device
RFC 6869

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]
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]
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]
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]
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]
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]
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]
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]