Re: [VCARDDAV] Late comments on 'device' KIND

Joe Marcus Clarke <> Sun, 23 September 2012 20:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B25321F84FD for <>; Sun, 23 Sep 2012 13:24:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YLgElMhBnDA9 for <>; Sun, 23 Sep 2012 13:24:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0772721F84F5 for <>; Sun, 23 Sep 2012 13:24:19 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id q8NKOI2g019235; Sun, 23 Sep 2012 16:24:18 -0400 (EDT)
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id q8NKOHBP017682; Sun, 23 Sep 2012 16:24:17 -0400 (EDT)
Message-ID: <>
Date: Sun, 23 Sep 2012 16:24:17 -0400
From: Joe Marcus Clarke <>
Organization: Cisco Systems, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Peter Sheerin <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Subject: Re: [VCARDDAV] Late comments on 'device' KIND
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 Sep 2012 20:24:21 -0000

On 9/23/12 11:22 AM, Peter Sheerin wrote:
> I apologize in advance for stirring the pot at this late date, but I’d
> like to make sure this becomes a very capable and widely used part of
> vCard, and I feel the current draft is missing significant elements
> needed for such success.

I will reply up here to try and present an alternate concept behind this
draft.  First, let me say, I love where your head is, as we have a
number of similar ideas.  However, we wanted to model this draft after
KIND:application.  We only want to define the KIND value here.  The use
cases and more specifics as to exactly what will be in a device-level
vCard come after this.  Our intention is to continue down this track of
thinking, though, and flesh out those over normative items.

What we want to do next is, as you say, tighten the vCard with those
properties that must be in every device-level vCard.  As such, we will
likely be defining some new organizational properties.

> At a high-level, I feel it is under-specified and lacking clear
> definitions of use cases that would inform more consistent usage and
> interaction with devices.
> First, I believe the standard should include XML, binary XML, plain-text
> (normal vCard), and potentially JSON encodings, with examples of each,
> as each of these will have a use. In particular, binary XML and JSON are
> the two most likely data formats to be used in the IETF’s CoAP
> specification, currently being developed to support the Internet of
> Things, and plain-text device cards are likely to be needed for
> interoperability purposes on larger devices, and at a minimum for
> exchange. (CoAP is one of the protocols being promoted by the IPSO
> Alliance, which organized itself as a marketing body for IEEE and IETF
> IoT standards.)

Again, we went after the KIND:application here.  I don't think it's
vital for this draft to include a number of example formats (though that
will likely happen in the subsequent drafts).

I'll let others chime in, but I don't think we want to overload this
draft with additional normative definitions.


> Full disclosure:
> My main consulting gig at the moment is as the Technical Marketing
> Director for an IoT stealth-mode startup, IOTA Computing, Inc. and some
> of my comments here are driven by vision for what the IoT needs for
> discovery and interoperability. But I’m also a long-time fan of vCard
> from when it first existed, and have sporadically been involved over the
> years. (It was my suggestion on this list that resulted in the use of
> the outdated ISO date format specifically to allow birthdays and
> anniversaries to be included without years.) My comments below are
> mainly driven by a desire to be able to have future IoT and larger
> connected devices send their address to my phone, giving them everything
> it needs to determine its admin console URI, protocols spoken, etc.
> Specifics
> The RFC should strive to create a device vCard that is as compact as
> possible. For example, the use of XML namespaces to define the format of
> serial numbers, MAC addresses, etc. in the example is clearly flexible
> for future additions, but also increases the size of the vCard. For such
> properties that are likely to be in nearly every device vCard, I believe
> these formats should be fully specified by this RFC so that the
> representation can be made more compact.
> Expand the Examples
> This draft should include examples in:
> * XML (as now)
> * EXI (Efficient XML Interchange:
> * plain-text (standard vCard 4.0)
> * JSON (I’m not sure if I wish that this RFC be delayed to wait for the
> possible future JSON flavor now being discussed, but I do feel it is
> very important.)
> Additional Properties
> Manufacture Information (MANUF?)
> This should include the manufacturer name (perhaps the RFC could define
> this as being equal to the FN property), model, revision, manufacture
> date/time, and serial number (but with a specific schema referenced,
> instead of one with an URI that begins “”.
> Electronic Address (EADR?)
> This should be used to report the device’s normal (non-admin) address,
> and contain attributes for MAC-48, EUI-64, IPv4, IPv6, and 6LoWPAN.
> Admin Information (ADMIN?)
> This should at a minimum, include the URI for the admin interface, plus:
> protocols and interfaces supported (e.g. HTTP over TCP with TLS, CoAP
> over UDP with DTLS, etc.)
> Capabilities (CAPS?)
> This should be used to indicate the device’s capabilities, such as
> router, switch, gateway, access point, sensor, actuator, etc. And
> contrary to the language in the draft, I would like to suggest that
> defining these and perhaps even creating a registry is within the
> necessary scope of this initiative, even if a separate RFC is needed to
> initiate the registry.
> _______________________________________________
> VCARDDAV mailing list

Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s