[VCARDDAV] Late comments on 'device' KIND

Peter Sheerin <Peter@PetesGuide.com> Sun, 23 September 2012 15:23 UTC

Return-Path: <Peter@PetesGuide.com>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0370621F848B for <vcarddav@ietfa.amsl.com>; Sun, 23 Sep 2012 08:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KUBnUy5d-KjL for <vcarddav@ietfa.amsl.com>; Sun, 23 Sep 2012 08:23:18 -0700 (PDT)
Received: from homiemail-a37.g.dreamhost.com (caiajhbdccac.dreamhost.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3C33321F8487 for <vcarddav@ietf.org>; Sun, 23 Sep 2012 08:23:18 -0700 (PDT)
Received: from homiemail-a37.g.dreamhost.com (localhost []) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id A5E0D20806B for <vcarddav@ietf.org>; Sun, 23 Sep 2012 08:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=PetesGuide.com; h= message-id:date:from:mime-version:to:subject:content-type; s= petesguide.com; bh=Ek57rrKT5OOUE6dw/gxMRi2UN/M=; b=i954ft+QCyM8/ 5JaO3M3C2qgPF3eRv8wth4aojz5JE4EbTUNxLc77Zvzy2eMu8ryh6+Vs1rku1n5t bi5TucZsKzKLCJhAI1xux1TWgiUaEKNMdJrw9gyQGepcltq+Sk17eSv39Az7nIq2 ZUZlsBnaSKNGCmArkRnaB/QADlLE68=
Received: from [] (ip-64-134-238-192.public.wayport.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: Peter@PetesGuide.com) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPSA id 9CF34208061 for <vcarddav@ietf.org>; Sun, 23 Sep 2012 08:23:15 -0700 (PDT)
Message-ID: <505F2946.7070600@PetesGuide.com>
Date: Sun, 23 Sep 2012 08:22:46 -0700
From: Peter Sheerin <Peter@PetesGuide.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0a2
MIME-Version: 1.0
To: vcarddav@ietf.org
Content-Type: multipart/alternative; boundary="------------050400060700040003020701"
X-Antivirus: avast! (VPS 120921-0, 09/21/2012), Outbound message
X-Antivirus-Status: Clean
Subject: [VCARDDAV] Late comments on 'device' KIND
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Sep 2012 15:23:21 -0000

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.

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

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.


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: http://www.w3.org/XML/EXI/

* 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 "example.com".

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.