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

Gonzalo Salgueiro <> Mon, 24 September 2012 02:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4100221F84C5 for <>; Sun, 23 Sep 2012 19:34:50 -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 va0GPyAk+pav for <>; Sun, 23 Sep 2012 19:34:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DCD5521F849C for <>; Sun, 23 Sep 2012 19:34:48 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id q8O2YmKN020375 for <>; Sun, 23 Sep 2012 22:34:48 -0400 (EDT)
Received: from ( []) by (8.13.8+Sun/8.13.8) with ESMTP id q8O2Ye58012649; Sun, 23 Sep 2012 22:34:40 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="windows-1252"
From: Gonzalo Salgueiro <>
In-Reply-To: <>
Date: Sun, 23 Sep 2012 22:34:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Peter Sheerin <>
X-Mailer: Apple Mail (2.1283)
Cc: CardDAV <>
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: Mon, 24 Sep 2012 02:34:50 -0000

Peter - 

I don't mean to do an author pile-on here but I agree that this draft is registration focused and doesn't warrant the detail you request. That said, we are very interested in the IoT/M2M use case of vCard on network elements. We have every intent to do what you request in a subsequent draft defining the base-level vCard for a device.



On Sep 23, 2012, at 4:24 PM, Joe Marcus Clarke wrote:

> 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.
> Joe
>> 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
> Email:
> ----------------------------------------------------------------------------
> _______________________________________________
> VCARDDAV mailing list