vCard KIND:device
Extracted elements (17)
A "device" in this context is constrained to computing devices and excludes purely mechanical devices (e.g., elevators, generators) that cannot communicate over a network, though network-attached sensors connected to such mechanical devices are not precluded.
A more fine-grained taxonomy of devices (e.g., subtypes like "router" or "computer" under KIND:device) was considered but explicitly deemed out of scope for this document.
Although a virtual machine running within a physical element is not a physical device per OSI/X.521 definitions, the KIND:device value is explicitly extended to cover virtual devices, departing from the strict X.521 definition.
The process for discovering and accessing vCards embedded in devices is purposefully left unspecified, as it could rely on any mechanism appropriate to the device, avoiding premature standardization of discovery.
The value "device" was chosen instead of the broader "thing" category (considered during RFC 6473 development) by splitting "thing" into software applications and hardware devices; RFC 6473 defined "application" while this document defines "device" for network-connected hardware.
KIND:device complements RFC 6473 (KIND:application) by covering hardware devices; the two values together implement the split of the originally considered "thing" value into software and hardware categories.
Supplementary vCards linked from a KIND:device vCard need not use RELATED to point back to the KIND:device vCard, allowing the device vCard to be easily distinguished from ancillary vCards.
A device may have multiple embedded vCards (for the device itself, the manufacturer, an administrator, or installed applications); these are linked together using the RELATED property from Section 6.6.6 of RFC 6350.
A KIND:device vCard is functionally equivalent to the "device" object class in LDAP (RFC 4519) as derived from the OSI model (X.521/X.200), but extends the concept to include virtual devices.
Recommended base properties for device vCards include ADR, EMAIL, FN, GEO, IMPP, KEY, KIND, LANG, LOGO, NOTE, ORG, PHOTO, RELATED, REV, SOURCE, TEL, TZ, UID, and URL; this list is non-exhaustive.
The FN property in a device vCard may represent the hostname; URL may point to documentation; KEY may hold a digital certificate provisioned at manufacture (e.g., IEEE 802.1AR) or a public key; ADR, GEO, and TZ may represent physical deployment location and timezone.
The KIND property value "device" is defined for use in vCard version 4, representing a computing device such as an appliance, computer, or network element (e.g., server, router, switch, printer, sensor, or phone).
vCards for devices can be embedded at manufacturing time to carry basic information such as serial number, support email, and documentation URL, and can be modified post-deployment for asset tracking and operational purposes.
IANA has added the value "device" for the KIND property to the "vCard Property Values" table of the "vCard Elements" registry, per Section 10.2.6 of RFC 6350, referencing RFC 6869 Section 3.
Publication of device identification details in publicly accessible vCard repositories increases the probability of exploitation of existing vulnerabilities, particularly for devices with no good software/firmware update mechanism; device administrators must follow best current security practices and employ proper upgrade and patch strategies.
Specifications defining device-specific vCard extensions or profiles must consider the increased risk introduced by exposing device details in publicly accessible repositories, as registration of KIND:device itself does not introduce security considerations beyond those in RFC 6350.
The xCard (XML) representation of a KIND:device vCard uses the element <kind><text>device</text></kind> within the vcard namespace (urn:ietf:params:xml:ns:vcard-4.0), and may include extension elements from custom namespaces for device-specific attributes like serial number, MAC address, and software version.