Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6869.
Authors Gonzalo Salgueiro , Joe Clarke , Peter Saint-Andre
Last updated 2012-11-27 (Latest revision 2012-11-26)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 6869 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Pete Resnick
Send notices to cyrus@daboo.name, gsalguei@cisco.com, jclarke@cisco.com, psaintan@cisco.com, draft-salgueiro-vcarddav-kind-device@tools.ietf.org
draft-salgueiro-vcarddav-kind-device-04
VCARDDAV                                                    G. Salgueiro
Internet-Draft                                                 J. Clarke
Intended status: Standards Track                          P. Saint-Andre
Expires: May 30, 2013                                      Cisco Systems
                                                       November 26, 2012

                           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 30, 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.

Salgueiro, et al.         Expires May 30, 2013                  [Page 1]
Internet-Draft              vCard KIND:device              November 2012

Table of Contents

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

Salgueiro, et al.         Expires May 30, 2013                  [Page 2]
Internet-Draft              vCard KIND:device              November 2012

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

Salgueiro, et al.         Expires May 30, 2013                  [Page 3]
Internet-Draft              vCard KIND:device              November 2012

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

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

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

Salgueiro, et al.         Expires May 30, 2013                  [Page 4]
Internet-Draft              vCard KIND:device              November 2012

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

Salgueiro, et al.         Expires May 30, 2013                  [Page 5]
Internet-Draft              vCard KIND:device              November 2012

   <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.         Expires May 30, 2013                  [Page 6]
Internet-Draft              vCard KIND:device              November 2012

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              August 2011.

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

Salgueiro, et al.         Expires May 30, 2013                  [Page 7]
Internet-Draft              vCard KIND:device              November 2012

   [RFC6473]  Saint-Andre, P., "vCard KIND:application", RFC 6473,
              December 2011.

   [X.200]    International Telecommunications 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 Telecommunications Union, "Information
              Technology - Open Systems Interconnection - The Directory:
              Selected Object Classes", ITU-T Recommendation X.200,
              ISO Standard 7498-1, July 1994.

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
   USA

   Phone: +1-303-308-3282
   Email: psaintan@cisco.com

Salgueiro, et al.         Expires May 30, 2013                  [Page 8]