Subject: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-15.txt

From: [email-masked]
Date: Thu, 09 Dec 2010 06:15:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the vCard and CardDAV Working Group of the IETF.

	Title           : vCard Format Specification
	Author(s)       : S. Perreault, P. Resnick
	Filename        : draft-ietf-vcarddav-vcardrev-15.txt
	Pages           : 79
	Date            : 2010-12-09

This document defines the vCard data format for representing and
exchanging a variety of information about individuals and other
entities (e.g., formatted and structured name and delivery addresses,
email address, multiple telephone numbers, photograph, logo, audio
clips, etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-15.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 09 Dec 2010 09:22:13 -0500

> 	Filename        : draft-ietf-vcarddav-vcardrev-15.txt

This version contains changes that resulted from the working group
meeting in Beijing.

Change log:

   o  Reverted N to the 5-component format of vCard 3.

   o  Removed DDAY, BIRTH, and DEATH.

   o  First two components in ADR SHOULD be empty.

   o  Removed the LABEL property.

   o  Removed the binary value type and the ENCODING and FMTTYPE
      parameters.

   o  Renamed SEX to GENDER.  Set predefined values to "male" and
      "female".

   o  Reverted TEL to take a text value by default, but SHOULD be reset
      to a URI.

   o  Refer to iCalendar for CALSCALE.

   o  Removed the "thing" value for KIND.

   o  RELATED now uses XFN 1.1 for its value.

   o  Dropped the VERSION parameter.  XML MUST be version 1.0.

   o  Dropped the CLASS property.

   o  Property and parameter names SHOULD be upper-case.

   o  Use ABNF for cardinality notation.

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: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Dec 2010 08:05:45 -0700

Thanks, Simon!

For other folks, the full diff is here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-15

---

From: Joseph Smarr <[email-masked]>
Date: Wed, 15 Dec 2010 07:50:30 -0800

Simon-what an awesome spec update! :) Thanks for the quick
turnaround incorporating all the feedback from Beijing. Sorry for the delay
on more detailed feedback, we did actually meet a couple weeks ago as
discussed, but once the new drafts came out, we wanted a chance to look over
them more closely. Expect more detailed feedback in a couple days.

In the meantime, I noticed one quick typo to fix:
6.3.1: "are the plagued" -> "are plagued".

Thanks, js

On Thu, Dec 9, 2010 at 6:22 AM, Simon Perreault <[email-masked]
> wrote:

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

---

From: Tantek Çelik <[email-masked]>
Date: Wed, 15 Dec 2010 19:31:13 -0800

I've reviewed the meeting minutes from the Beijing meeting and all the
draft 14 to draft 15 differences (thanks for the URL Peter).

In addition, I was happy to see that this URL worked:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-vcarddav-vcardrev-14

for draft 13 to draft 14 differences.

Draft 15 is a *huge* improvement over draft 13.

THANK YOU Peter, Simon, Marc and everyone else who worked hard to
incorporate feedback and changes. Your efforts and consideration are
greatly appreciated.

Over the next few days I'll be reading draft 15 thoroughly and
updating my section-by-section review accordingly, attempting to take
into account the respective email threads.

One particularly important feature change that I wanted to comment on
without delay however is the adoption of the new GENDER property.

GENDER

While I certainly applaud the increasing of flexibility from an enum
to plain text field, I'd like to please ask the group to consider
adopting the GENDER property as originally proposed with two
components, a sex enum (M(ale),F(emale),N(one),O(ther),U(nknown)) and
a plain text gender identity label. Both of these are necessary for
supporting flexibility for human diversity and for representing
existing publishing practices and gender specific search user
interfaces.

The two component GENDER property proposal was met with approval by
Kevin Marks and Sarah Dopp:

http://www.ietf.org/mail-archive/web/vcarddav/current/msg01784.html

And as a result I had presumed there was at least weak consensus in
the group on this specific proposal since there were no objections and
no further messages on that thread. I must admit I was a little
surprised to see a single component GENDER property instead (I am
assuming this was simply a minor oversight rather than an explicit
decision).

I am more than happy to contribute specification text if necessary.
I've iterated a bit more here:

https://wiki.mozilla.org/VCard4-draft-13-review#GENDER

Thanks again for all the great improvements in draft 15.  Hoping there
is still time for a few more minor fixes / updates.

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 15 Dec 2010 22:48:11 -0700

Hi Tantek, thanks for the feedback.

> https://wiki.mozilla.org/VCard4-draft-13-review#GENDER

The meeting notes said:

  - Resolution: Rename SEX to GENDER. Change values to (male, female,
  <free-form text>). IANA registry for additional values that could be
  reserved.

If I recall correctly, the idea was that free-form text would be
allowed, such as:

   GENDER:VALUE=text:Fellow

Instead of:

   GENDER:male

People could also register well-known values, such as:

   GENDER:queer

You seem to be proposing that the free-form text would supplement one of
the defined values (or no value at all). Correct? I just want to make
sure that I understand the proposal.

Peter

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 16 Dec 2010 08:46:45 -0500

> https://wiki.mozilla.org/VCard4-draft-13-review#GENDER

I have no issue with copying that verbatim if it's the working group's
consensus.

Simon

---

From: Kepeng Li <[email-masked]>
Date: Thu, 30 Dec 2010 14:28:53 +0800

Happy New Year!

FYI that I uploaded a new I-D draft for vCard extensions.

Welcome comments and suggestions.

Thanks,
Kind Regards
Kepeng
--------------------------------------------------------------------------------------------------
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : vCard Format Extensions : DDAY, BIRTH, and DEATH
	Author(s)       : K. Li, B. Leiba
	Filename        : draft-li-vcarddav-vcard-id-property-extensions-00.txt
	Pages           : 8
	Date            : 2010-12-29

This document defines an extension to the vCard data format for
representing and exchanging information about the date of death, the
place of birth, and the place of death of the object the vCard
represents.

Note

Discussion and suggestions for improvement are requested, and should
be sent to [email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-li-vcarddav-vcard-id-property-extensions-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-li-vcarddav-vcard-id-property-extensions-00.txt>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Dec 2010 11:48:34 -0500

> Welcome comments and suggestions.

Great!

- I'm sure this draft could be extended with more genealogy properties.
There have been many such proposals on this mailing list.
See also: http://microformats.org/wiki/genealogy
But I'm fine with only these three properties if you don't find
collaborators.

- Please please please merge sections 3 and 5.

  - Section 3 should contain the registration template along with any
additional information you feel like including.

  - Section 5 should be very short. Please be kind with IANA and make
their life easy. Only list the exact actions that you would like them to
take. For example:

    Add the following to the vCard Properties registry:

      +-----------+--------------+---------+------------------------+
      | Namespace | Property     | Status  | Reference              |
      +-----------+--------------+---------+------------------------+
      |           | DDAY         | Current | RFCXXXX, section 3.1   |
      |           | BIRTH        | Current | RFCXXXX, section 3.2   |
      |           | DEATH        | Current | RFCXXXX, section 3.3   |
      +-----------+--------------+---------+------------------------+

That's it. IANA doesn't care about the registration template. That's for
the expert reviewer to inspect. Only tell IANA what they need to know,
i.e. changes to registries.

Simon

P.S. I'm glad that you kept the funny examples! ;)
-- 
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: Kepeng Li <[email-masked]>
Date: Fri, 31 Dec 2010 17:23:53 +0800

Hi Simon,

Thanks for your review.

> But I'm fine with only these three properties if you don't find

Let me check if other extensions can merged into this draft, or we can have
other extension drafts.

> take.

Sounds reasonable to me, thanks for the suggestion.

Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Simon Perreault
发送时间: 2010年12月31日 0:49
收件人: [email-masked]
主题: Re: [VCARDDAV] I-D Action:
draft-li-vcarddav-vcard-id-property-extensions-00.txt

Great!

Simon