Subject: [VCARDDAV] KIND:device

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 06 Jan 2012 11:26:32 -0700

<hat type='individual'/>

During discussion of the document that became RFC 6473, we decided that
KIND:thing was too broad so we decided to work on KIND:application and
delay work on something like KIND:device pending the emergence of use
cases for vCards about computing devices as opposed to software
applications. Recently I've been chatting with Gonzalo Salgueiro and Joe
Clarke about device vCards, so the three of us have authored an
Internet-Draft on the topic:

http://www.ietf.org/id/draft-salgueiro-vcarddav-kind-device-00.txt

Note that this document is focused on computing devices, not any random
kind of physical object or machine. This seems like the right approach
to me (let's specify new KIND values only for well-defined aspects of
the broad universe of things that might have vCards), but feedback would
be welcome from the group here on that topic and the document more
generally.

Thanks!

Peter

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

---

From: Zoltan Ordogh <[email-masked]>
Date: Mon, 9 Jan 2012 17:03:35 +0000

Hi Peter,
thank you.
I checked -01:
http://tools.ietf.org/html/draft-salgueiro-vcarddav-kind-device

In section 3:
"The following base properties make sense for vCards that represent devices..."
According to whom? Could this be removed?

Having seen the example in section 4, I wonder if
<kind><text>device</text></kind>
Could be:
<kind><text>device</text></kind>
<kind>
	<parameters>
		<type><text>device-type</text></type>
	</parameters>
	<text>router</text>
</kind>
would make sense (with a device-type registry).

Thank you.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: January 6, 2012 1:27 PM
To: CardDAV
Subject: [VCARDDAV] KIND:device

<hat type='individual'/>

During discussion of the document that became RFC 6473, we decided that KIND:thing was too broad so we decided to work on KIND:application and delay work on something like KIND:device pending the emergence of use cases for vCards about computing devices as opposed to software applications. Recently I've been chatting with Gonzalo Salgueiro and Joe Clarke about device vCards, so the three of us have authored an Internet-Draft on the topic:

Note that this document is focused on computing devices, not any random kind of physical object or machine. This seems like the right approach to me (let's specify new KIND values only for well-defined aspects of the broad universe of things that might have vCards), but feedback would be welcome from the group here on that topic and the document more generally.

Thanks!

Peter

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

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Joe Marcus Clarke <[email-masked]>
Date: Mon, 09 Jan 2012 12:14:35 -0500

> According to whom? Could this be removed?

Thanks for the feedback, Zoltan.  We borrowed that text from
KIND:application as well as the properties chosen.  We did add UID as a
holder for serial number.  The thinking was that the list of properties
there would make sense either to be associated directly to the device or
to a related individual.  These are suggestions and hence we did not use
strong language to enforce their use.

> would make sense (with a device-type registry).

Just like with KIND:application, there could be sub-types.  We
specifically indicate that, but do not address it in this draft.  That
said, I don't think KIND is the right property for this.  This might be
handled in a vendor extension namespace and standardized later.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Support 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: Mon, 09 Jan 2012 10:16:39 -0700

On 1/9/12 10:03 AM, Zoltan Ordogh wrote:
> According to whom? 

By stipulation of the authors. :)

It's something that we need to figure out for each new KIND, so let's
discuss it.

> Could this be removed?

No, because Section 6.1.4 of RFC 6350 states the following about new
values for the KIND property:

      An iana-token.  Additional values may be registered with IANA (see
         Section 10.3.4).  A new value's specification document MUST
         specify which properties make sense for that new kind of vCard
         and which do not.

http://tools.ietf.org/html/rfc6350#section-6.1.4

> would make sense (with a device-type registry).

The same section of RFC 6350 states:

      An x-name.  vCards MAY include private or experimental values for
         KIND.  Remember that x-name values are not intended for general
         use and are unlikely to interoperate.

If we wanted to create a public registry for this, I think we'd want to
define a "device-type" extension in the XML representation, e.g.:

<device xmlns='urn:ietf:params:xml:ns:device-type'>router</device>

Peter

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

---

From: Zoltan Ordogh <[email-masked]>
Date: Mon, 9 Jan 2012 17:31:58 +0000

Hi Peter,

> No, because Section 6.1.4 of RFC 6350 states the following about new values for the KIND property:
> 

I meant the paragraph about what makes sense and what does not.
Joe pointed out that it's informative (not normative), so it's ok.

> > <kind><text>device</text></kind> Could be:
> If we wanted to create a public registry for this, I think we'd want to define a "device-type"
> extension in the XML representation, e.g.:
> 

I think that a registry would be a good idea.
As for the format - whatever works.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Jan 2012 09:51:31 -0500

On 01/09/2012 12:14 PM, Joe Marcus Clarke wrote:
> We did add UID as a holder for serial number.

I'd be careful with that idea. What tells a vCard consumer that the UID 
property also happens to contain a serial number? Seems like pointless 
overloading to me. Better just create a new serial number property. It's 
free, you know... ;)

> handled in a vendor extension namespace and standardized later.

Mkay... But it would truly be sad if KIND:DEVICE gets standardized but 
everything else doesn't so basically KIND:DEVICE becomes a new ex-dash 
playground where only one vendor plays.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Jan 2012 09:55:08 -0500

Question for the authors: section 1 (Introduction) says: "Since then, 
use cases for device vCards have emerged." What are they, precisely? 
What are your (the authors') use cases?

Question for the WG: would anyone else have a use case for this? Does 
anyone else want this?

Simon

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 11 Jan 2012 13:38:43 -0500

> overloading to me. Better just create a new serial number property. It's

I do.  I was arguing that a "unique identifier" for a device would
likely be a serial number since that is burned into the device.  Gonzalo
and I were debating this further and I'm coming around to provisioning a
serial number property vs. overloading UID.  But since UID can hold a
text value like this, it would be legal to do a serial number here, right?

> playground where only one vendor plays.

We're following the model of KIND:application here.  Sub-types and those
properties that might be applicable to different devices is outside the
scope of this draft.  We do not want to make this vendor-specific,
though.  Throughout our thinking on this we have been considering a
number of devices that would come from a number of vendors.  We want to
provide easier identity and asset tracking through well-structured data.
 The use case we have put in the draft can be implemented by any vendor
of any type of networked element.

Joe

---

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Jan 2012 14:01:04 -0500

> text value like this, it would be legal to do a serial number here, right?

I'm not sure you understood my point.

Yes it would be *legal* for the UID property to hold a serial number.

The problem I'm thinking of would arise if, in *any* circumstance, you 
try to *interpret* the UID property as a serial number, or you try to 
*extract* a serial number from it. If you don't want to do that, fine, 
but then I'd still be curious as to why a randomly-generated UUID 
wouldn't be easier.

Simon

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 11 Jan 2012 14:10:22 -0500

> but then I'd still be curious as to why a randomly-generated UUID

I got the point.  I was getting clarification in my last sentence, but
the overall message is that I agree it would be better to use a new
property that would be specific to serial number.  In that way, one
would know that they are reading a serial number and a UUID could still
be used as a way of grouping devices in, say, group vCards.

Joe

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 11 Jan 2012 14:15:52 -0500

> What are your (the authors') use cases?

We enumerate one in the draft around asset and identity tracking.  By
using device vCards, we can have structured data around what the device
is, where it is, what are its capabilities, and who is responsible.
This can be shared in a number of ways (e.g., HTTP, Webfinger, XMPP,
etc.).  It would potentially be more effective to access such data as a
vCard vs. making a number of SNMP queries to pull bits and pieces.

Joe

---

From: "Peter K. Sheerin" <[email-masked]>
Date: Sun, 15 Jan 2012 16:36:43 -0800

My 2¢:

It would be awesome if a device vCard included enough information to locate its admin interface URL on the network.

For instance, having the default IP address and MAC address on a Wi-Fi router encoded in a vCard 2D barcode on the unit would allow a smartphone app to connect to the admin interface (if the default address was actually used—extremely common in home networks), or search the network for that MAC address, in order to locate it.

They could also be used to distribute directories of APs available for use in a corporate environment. Here, fields to indicate which IEEE protocols, bands, auth methods the device supports would be useful, along with a URI (to another vCard or URL) pointing to the resource authorized to issue login credentials would improve the end-user experience.

-- 
Peter Sheerin
[email-masked]
+1 650 898 7383
(From my iPhone)