VCARDDAV G. Salgueiro
Internet-Draft J. Clarke
Intended status: Standards Track P. Saint-Andre
Expires: July 9, 2012 Cisco Systems
January 6, 2012
vCard KIND:device
draft-salgueiro-vcarddav-kind-device-00
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 July 9, 2012.
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 July 9, 2012 [Page 1]
Internet-Draft vCard KIND:device January 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Salgueiro, et al. Expires July 9, 2012 [Page 2]
Internet-Draft vCard KIND:device January 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", "organization",
"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. 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.
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
Salgueiro, et al. Expires July 9, 2012 [Page 3]
Internet-Draft vCard KIND:device January 2012
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.
The properties included in a device's vCard apply to one of the
following:
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
(e.g., the LOGO property might represent the corporate logo of an
equipment vendor, and the URL might represent the website where
the device's installation and maintenance documentation is
available).
o A person or role that maintains or administers the device (e.g.,
the TEL, EMAIL, and IMPP properties might represent ways to
contact a server or network administrator).
When a property represents some aspect of the device itself, the TYPE
parameter MUST NOT include the values "work" and "home" (see the
definition of the TYPE parameter in Section 5.6 of [RFC6350]). When
a property represents information about an individual associated with
the device (e.g., an individual device administrator as opposed to a
device attribute or an associated organization), TYPE values "home"
and "work" MAY be specified. Whatever TYPE values are used, the
implementation MUST distinguish attributes that are applicable to
individuals related to the device as opposed to those attributes
applicable to the device itself.
The following base properties make sense for vCards that represent
devices (this list is not exhaustive, and other properties might be
applicable as well):
Salgueiro, et al. Expires July 9, 2012 [Page 4]
Internet-Draft vCard KIND:device January 2012
* ADR
* EMAIL
* FN
* GEO
* IMPP
* KEY
* KIND
* LANG
* LOGO
* NOTE
* ORG
* PHOTO
* 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 (e.g., the UID is a serial number) as well as
post-deployment attributes and uses the XML representation of vCard
described in [RFC6351].
Salgueiro, et al. Expires July 9, 2012 [Page 5]
Internet-Draft vCard KIND:device January 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>
<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><text>FTX1234ABCD</text></uid>
<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
</ver>
</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.
Salgueiro, et al. Expires July 9, 2012 [Page 6]
Internet-Draft vCard KIND:device January 2012
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.
[RFC6473] Saint-Andre, P., "vCard KIND:application", RFC 6473,
December 2011.
[X.200] International Telecommunications Union, "Information
Technology - Open Systems Interconnection - Basic
Salgueiro, et al. Expires July 9, 2012 [Page 7]
Internet-Draft vCard KIND:device January 2012
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 July 9, 2012 [Page 8]