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

From: Peter Sheerin <[email-masked]>
Date: Sun, 23 Sep 2012 08:22:46 -0700

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.

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.

---

From: Joe Marcus Clarke <[email-masked]>
Date: Sun, 23 Sep 2012 16:24:17 -0400

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

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.

> the two most likely data formats to be used in the IETF’s CoAP

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

> discovery and interoperability. But I’m also a long-time fan of vCard
> * JSON (I’m not sure if I wish that this RFC be delayed to wait for the
> instead of one with an URI that begins “example.com”.
> 
> This should be used to report the device’s normal (non-admin) address,
> This should be used to indicate the device’s capabilities, such as
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> 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: [email-masked]

----------------------------------------------------------------------------

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 23 Sep 2012 15:39:13 -0600

On 9/23/12 2:24 PM, Joe Marcus Clarke 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.

What Joe said. The issues you raise are interesting and important, but
out of scope for simply defining a new value for KIND.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Sun, 23 Sep 2012 22:34:40 -0400

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

---

From: Peter Sheerin <[email-masked]>
Date: Mon, 24 Sep 2012 08:33:26 -0700

Thanks, all!

My bad. That's what I get for only occasionally getting involved in RFC 
development.

I will take another look at the draft with the intended scope in mind, 
and see if I have any relevant comments.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 24 Sep 2012 09:36:29 -0600

On 9/24/12 9:33 AM, Peter Sheerin wrote:
> Thanks, all!
> 
> My bad. That's what I get for only occasionally getting involved in
> RFC development.

We all need to start somewhere. ;-)

> I will take another look at the draft with the intended scope in
> mind, and see if I have any relevant comments.

Thanks. Your feedback is appreciated!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/