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

Gonzalo Salgueiro <gsalguei@cisco.com> Mon, 24 September 2012 02:34 UTC

Return-Path: <gsalguei@cisco.com>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4100221F84C5 for <vcarddav@ietfa.amsl.com>; Sun, 23 Sep 2012 19:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va0GPyAk+pav for <vcarddav@ietfa.amsl.com>; Sun, 23 Sep 2012 19:34:49 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5521F849C for <vcarddav@ietf.org>; Sun, 23 Sep 2012 19:34:48 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8O2YmKN020375 for <vcarddav@ietf.org>; Sun, 23 Sep 2012 22:34:48 -0400 (EDT)
Received: from rtp-gsalguei-8914.cisco.com (rtp-gsalguei-8914.cisco.com [10.116.132.53]) by chook.cisco.com (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 <gsalguei@cisco.com>
In-Reply-To: <505F6FF1.8000407@cisco.com>
Date: Sun, 23 Sep 2012 22:34:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D33AF96C-7D2D-429F-83DD-0ECD8EA8BAB7@cisco.com>
References: <505F2946.7070600@PetesGuide.com> <505F6FF1.8000407@cisco.com>
To: Peter Sheerin <Peter@PetesGuide.com>
X-Mailer: Apple Mail (2.1283)
Cc: CardDAV <vcarddav@ietf.org>
Subject: Re: [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: 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.

Cheers,

Gonzalo

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: 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.
>> 
>> 
>> 
>> _______________________________________________
>> VCARDDAV mailing list
>> VCARDDAV@ietf.org
>> https://www.ietf.org/mailman/listinfo/vcarddav
>> 
> 
> 
> -- 
> 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: jclarke@cisco.com
> 
> ----------------------------------------------------------------------------
> _______________________________________________
> VCARDDAV mailing list
> VCARDDAV@ietf.org
> https://www.ietf.org/mailman/listinfo/vcarddav
>