Peter Saint-Andre | 6 Jan 19:26 2012

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:

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/
Zoltan Ordogh | 9 Jan 18:03 2012

Re: KIND:device

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: vcarddav-bounces <at> ietf.org [mailto:vcarddav-bounces <at> ietf.org] On Behalf Of Peter Saint-Andre
Sent: January 6, 2012 1:27 PM
To: CardDAV
Subject: [VCARDDAV] KIND:device

<hat type='individual'/>
(Continue reading)

Joe Marcus Clarke | 9 Jan 18:14 2012
Picon

Re: KIND:device

On 1/9/12 12:03 PM, Zoltan Ordogh wrote:
> 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?

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.

> 
> 
> 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>
(Continue reading)

Simon Perreault | 11 Jan 15:51 2012
Picon

Re: KIND:device

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

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

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
Joe Marcus Clarke | 11 Jan 19:38 2012
Picon

Re: KIND:device

On 1/11/12 9:51 AM, Simon Perreault wrote:
> 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... ;)

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?

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

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
(Continue reading)

Simon Perreault | 11 Jan 20:01 2012
Picon

Re: KIND:device

On 01/11/2012 01:38 PM, Joe Marcus Clarke wrote:
> On 1/11/12 9:51 AM, Simon Perreault wrote:
>> 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... ;)
>
> 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?

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

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
(Continue reading)

Joe Marcus Clarke | 11 Jan 20:10 2012
Picon

Re: KIND:device

On 1/11/12 2:01 PM, Simon Perreault wrote:
> On 01/11/2012 01:38 PM, Joe Marcus Clarke wrote:
>> On 1/11/12 9:51 AM, Simon Perreault wrote:
>>> 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... ;)
>>
>> 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?
> 
> 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.

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
(Continue reading)

Peter Saint-Andre | 9 Jan 18:16 2012

Re: KIND:device

On 1/9/12 10:03 AM, Zoltan Ordogh wrote:
> 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? 

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

> Having seen the example in section 4, I wonder if
> <kind><text>device</text></kind>
(Continue reading)

Zoltan Ordogh | 9 Jan 18:31 2012

Re: KIND:device

Hi Peter,

> > In section 3:
> > "The following base properties make sense for vCards that represent devices..."
> > 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

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.

> 
> > 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).
> 
(Continue reading)

Simon Perreault | 11 Jan 15:55 2012
Picon

Re: KIND:device

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

-- 
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
Joe Marcus Clarke | 11 Jan 20:15 2012
Picon

Re: KIND:device

On 1/11/12 9:55 AM, Simon Perreault wrote:
> 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?

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

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

--

-- 
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: jclarke <at> cisco.com

----------------------------------------------------------------------------
Peter K. Sheerin | 16 Jan 01:36 2012

Re: KIND:device

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
Peter <at> Petesguide.com
+1 650 898 7383
(From my iPhone)

On Jan 11, 2012, at 11:15 AM, Joe Marcus Clarke <jclarke <at> cisco.com> wrote:

> On 1/11/12 9:55 AM, Simon Perreault wrote:
>> 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?
> 
> 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.
(Continue reading)


Gmane