Subject: [VCARDDAV] KIND:thing

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 06 Apr 2011 11:00:57 -0600

<hat type='individual'/>

I've submitted a document that starts to define KIND:thing (which was
removed from the base spec):

http://www.ietf.org/id/draft-saintandre-vcard-thing-00.txt

Feedback is welcome.

Peter

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

---

From: Likepeng <[email-masked]>
Date: Tue, 12 Apr 2011 07:03:10 +0000

Two suggestions:

1. It would be better if we can have one example in the draft, even it is very simple. :-)

2. It would be better if we can have a registration table in IANA registration section, something like this:
       +----------+------------+---------+----------------------------------+
       | Property | Value  | Status  | Reference           |
       +----------+------------+---------+-----------------------------------+
       | KIND   | individual | Current | RFCXXXX, Section 6.1.4 |
       | KIND   | group    | Current | RFCXXXX, Section 6.1.4 |
       | KIND   | org      | Current | RFCXXXX, Section 6.1.4 |
       | KIND   | location  | Current | RFCXXXX, Section 6.1.4 |

Kind Regards
Kepeng
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, April 07, 2011 1:01 AM
To: CardDAV
Subject: [VCARDDAV] KIND:thing

<hat type='individual'/>

I've submitted a document that starts to define KIND:thing (which was removed from the base spec):

Feedback is welcome.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 Apr 2011 15:30:28 -0600

> Two suggestions:

Thanks for the feedback.

> 1. It would be better if we can have one example in the draft, even it is very simple. :-)

I have one here:

http://xmpp.org/extensions/xep-0292.html#things

But I'll add one to the I-D.

> 2. It would be better if we can have a registration table in IANA registration section, something like this:

Well, I'm not trying to register the existing values, only a new one, so
I don't think it's appropriate to show all of the existing values from
the base spec.

Peter

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

---

From: Likepeng <[email-masked]>
Date: Wed, 13 Apr 2011 01:27:07 +0000

>I'm not trying to register the existing values, only a new one, so

I mean, add this:
        +----------+------------+---------+----------------------------------+
        | Property | Value  | Status  | Reference           |
        +----------+------------+---------+-----------------------------------+
        | KIND   | thing  | Current | RFCXXXX, Section 2     |

Kind Regards
Kepeng
-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Wednesday, April 13, 2011 5:30 AM
To: Likepeng
Cc: CardDAV
Subject: Re: [VCARDDAV] KIND:thing

Thanks for the feedback.

I have one here:

Peter

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Apr 2011 08:08:05 -0400

> I mean, add this:

If you do this, note that the "Status" column is gone in recent drafts.

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: Likepeng <[email-masked]>
Date: Thu, 14 Apr 2011 01:03:44 +0000

>note that the "Status" column is gone in recent drafts.

OK, then I also need to remove that column in my draft, to be consistent.

Just another question, I notice that in vCardrev-19, the Namespace column is empty. Should we remove this column?

           +----------------+--------------+-------------------------------+
           | Namespace | Property  | Reference          |
           +----------------+--------------+-------------------------------+
           |          | SOURCE  | RFCXXXX, Section 6.1.3 |

Thanks,
Kind Regards
Kepeng
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Wednesday, April 13, 2011 8:08 PM
To: [email-masked]
Subject: Re: [VCARDDAV] KIND:thing

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
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Thu, 14 Apr 2011 08:37:24 -0400

On 2011-04-13 21:03, Likepeng wrote:
> Just another question, I notice that in vCardrev-19, the Namespace
> column is empty. Should we remove this column?

No, this is intentional.

   Namespace:  Empty for the global namespace, "VND-NNNN-" for a vendor-
      specific property (where NNNN is replaced by the vendor's PEN).

All properties in drafts so far are in the global namespace, therefore
the namespace column is empty.

Simon

---

From: Barry Leiba <[email-masked]>
Date: Tue, 19 Apr 2011 09:25:43 -0400

I just saw this....

In addition to what Kepeng says about the IANA Considerations section:

>         +----------+------------+----------------------------------+
>         | Property | Value  | Reference           |
>         +----------+------------+-----------------------------------+
>         | KIND   | thing  | RFCXXXX, Section 2     |

...I'll note that you haven't paid the slightest attention to vcardrev
section 10.2.6, which gives the template for making the request.
Section 2 should contain that template, and the current content of
section 2 should probably be in the "Conformance" item of the
template.

But I think I'd go a *little* farther with the explanation, given that
we had a lot of push to crisp up the definition of the other KIND
values in the vcardrev spec.  As Kepeng said, examples will help, and
maybe that's all that's needed.

(Also also, you might want to name the next version
"draft-saintandre-vcarddav-thing", so the tools track it as a related
document.)

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Apr 2011 07:37:24 -0600

> In addition to what Kepeng says about the IANA Considerations section:

I still think that visual layout of the table is a matter for the IANA
registry, not the registration request.

> section 10.2.6, which gives the template for making the request.

Thanks for the pointer. I didn't pay much attention to anything because
I had a few spare minutes to crank out a -00 draft. I'll post an updated
version soon.

> section 2 should probably be in the "Conformance" item of the

Yep.

> maybe that's all that's needed.

I have an example here:

That's in the XML representation, but I'll port it over to the textual
representation.

> "draft-saintandre-vcarddav-thing", so the tools track it as a related

Good point, will do.

Thanks for the feedback!

Peter

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

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 19 Apr 2011 10:06:05 -0400

Hi Peter,

> That's in the XML representation, but I'll port it over to the textual

If we are going to use the "generic" kind "things" I think we are also 
going to want to be able to classify them in other ways. The example you 
give is identifying an xmpp server. In the calendaring & scheduling space 
we would like to distinguish various scheduleable "things" or resources 
(<http://tools.ietf.org/html/draft-cal-resource-schema>). That needs to be 
done in an interoperable manner though, which kind of suggests a taxonomy 
of "things" perhaps in an IANA registry? Or perhaps something like that 
already exists?

Similar to that, I would like to make use of the Location Types registry 
(<http://www.iana.org/assignments/location-type-registry/location-type-registry.xml>) 
to add additional information to KIND:location. I think perhaps a TYPE= 
parameter on KIND would be a good option, eg.:

KIND;TYPE=airport:location

KIND;TYPE=theater:location

Though some of the types in that registry are arguably "things", e.g. 
"aircraft", "truck" etc.

-- 
Cyrus Daboo

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Apr 2011 08:29:42 -0600

On 4/19/11 8:06 AM, Cyrus Daboo wrote:
> Hi Peter,
> 
> --On April 19, 2011 7:37:24 AM -0600 Peter Saint-Andre
> <[email-masked]> wrote:
> 
> give is identifying an xmpp server. In the calendaring & scheduling
> space we would like to distinguish various scheduleable "things" or
> resources (<http://tools.ietf.org/html/draft-cal-resource-schema>). That
> needs to be done in an interoperable manner though, which kind of
> suggests a taxonomy of "things" perhaps in an IANA registry? Or perhaps
> something like that already exists?
> 

The location types seem useful because we already have them. But how
deep a taxonomy do we want to define for things, and is that the job of
the vCard community? I think KIND:thing is useful, but I'm much less
sure about TYPE=server or even TYPE=server;SUBTYPE=im and so on. This
isn't service discovery (or at least I don't think that's the purpose of
vCard).

For reference, in the XMPP community we've defined a wide range of
things that are of interest to us:

http://xmpp.org/registrar/disco-categories.html

But I'm not yet convinced that those identities, and others like them
from other communities, need to be represented in vCard (I'm not even
convinced that some of them are all that useful in XMPP itself).

Peter

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