vCard KIND:device
draft-salgueiro-vcarddav-kind-device-04

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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 31, 2013.

Copyright Notice

Copyright (c) 2012 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.

Table of Contents

• 1. Introduction
• 2. Conventions Used in This Document
• 3. Scope
• 4. Example
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

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. Additionally, [RFC6473] has defined a value of "application" for the KIND property to represent software applications.

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. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them. However, they should not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure.

3. 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 such that basic information such as 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 MAY 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:

• The device itself (e.g., the FN 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 timezone 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] for each application installed on the device.
  
  

When a device has vCards other than its KIND:device vCard, those vCards SHOULD be linked together with RELATED (see the definition of the RELATED organizational property in Section 6.6.6 of [RFC6350]). 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.

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.

4. 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).

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

5. IANA Considerations

The IANA is requested to add "device" to the registry of property values for vCard4. In conformance with Section 10.2.6 of [RFC6350], the registration is as follows, where the reference is to RFCXXXX.

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 RFCXXXX.

[[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to this specification, and remove this paragraph on publication.]]

6. Security Considerations

Use of vCards to represent devices is not envisioned to introduce security considerations beyond those specified for vCards in general as described in [RFC6350].

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses