RFC 6869

vCard KIND:device

📅 published February 2013, from ietf

vCard KIND:device 🎀

Okay bestie, here's the header tea ☕

  • RFC number: 6869
  • Title: vCard KIND:device
  • Authors: G. Salgueiro, J. Clarke, and P. Saint-Andre, all from Cisco Systems
  • Category: Standards Track
  • Stream: Internet Engineering Task Force (IETF)
  • ISSN: 2070-1721
  • Date: February 2013
  • Obsoletes / Updates: the title block doesn't list anything here 🫶

Abstract ✨

This doc defines a device value for the vCard KIND property, so the vCard format can represent computing devices like appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). It's giving versatile 💅

Status of This Memo 💜

This is an Internet Standards Track document, no cap 🔥

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6869 🌸

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) as they were in effect on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License 🫶

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 ✨

Okay so version 4 of the vCard spec [RFC6350] adds a new KIND property to say what kind of entity a vCard represents. While the VCARDDAV Working Group was building the base vCard4 spec, it defined individual, org, group, and location as KIND values. Iconic lineup 👑

Then, during working group discussion of the document that became [RFC6473], people considered a broader value called thing. The call was to split thing into software applications and hardware devices, and at that time only the application value got defined. Since then, device vCards have had their moment 🦋 Use cases showed up that treat vCards as a primer for inventory and asset tracking data specific to network elements.

So this document complements [RFC6473] by defining a device value for KIND to represent computing devices such as appliances, computers, or network elements. Here the idea of a device is limited to computing devices, which makes it different from purely mechanical devices like elevators or electric generators that can't communicate over a network in any way. That doesn't rule out network-attached sensors that are hooked up to those mechanical devices though 🧚

2. Scope 💖

When the KIND property has the value 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). Formally, a "device" is functionally equivalent to the "device" object class used in the Lightweight Directory Access Protocol [RFC4519], which comes from the Open Systems Interconnection model [X.521] [X.200]. The twist is that [X.521] says devices are "physical" elements, but a device in this context can also be virtual, like a virtual machine running inside another physical element. Main character energy 🎀

Here's a fave example: vCards can be embedded into devices at manufacturing time, so basic info like serial number, support email, and documentation URL can be pulled up right when the device is first deployed. After deployment, that vCard can be modified to hold user-specified details about the device's characteristics. So the same vCard data works for both asset tracking and operational purposes 🫶

A device might have several embedded vCards for different purposes. How you discover and access these vCards is purposefully left unspecified here, since it could rely on any mechanism that makes sense for the device in question. For example, a device could have one or more of these vCard instances:

  • The device itself. For example, the FN ("full name") property might represent the hostname of a computing device. The URL property might point to a website with details on where to find documentation or more info about the device. The KEY property might represent a digital certificate provisioned into the device at manufacture [IEEE.802.1AR], or a public key certificate previously provisioned into the device. The ADR, GEO, and TZ properties might represent the physical address, geographical location, and time zone where the device is deployed.
  • An organization or person that produces or manufactures the device.
  • A person or role that maintains or administers the device.
  • Application-level vCards as described in [RFC6473], one 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 setups, the KIND:device vCard uses RELATED to express its relationship with the ancillary vCard(s). Those supplementary vCards don't need to use RELATED to point back to the KIND:device vCard. This way, the device's own vCard is easy to tell apart from vCards about the vendor organization, the device administrator, and installed applications 💅

The following base properties make sense for vCards that represent devices (this list isn't exhaustive, and other properties might apply too):

  • ADR
  • EMAIL
  • FN
  • GEO
  • IMPP
  • KEY
  • KIND
  • LANG
  • LOGO
  • NOTE
  • ORG
  • PHOTO
  • RELATED
  • REV
  • SOURCE
  • TEL
  • TZ
  • UID
  • URL

Could it be useful to define a more fine-grained taxonomy of devices, like a device KIND with a subtype of router or computer? Totally, yes 🤩 But that taxonomy is out of scope for this document, so we'll leave it for another day 🌈

6.2. Informative References 📚✨

okay so these are the bonus reads 🧚 not required to get the spec, but super helpful if you want the full picture

[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. 🦋

⚠️ bestie, double-check these two! As printed in the original, the [X.200] entry names X.521 and the [X.521] entry names X.200. I've kept them exactly as the original has them so nothing gets changed by accident.

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

That's the whole doc, bestie! 💖 Three legends from Cisco wrote it, so you know it's 🔥 🌈

📦 where this page comes from