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

Peter Saint-Andre <> Thu, 16 December 2010 05:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 624B928C193 for <>; Wed, 15 Dec 2010 21:46:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.671
X-Spam-Status: No, score=-101.671 tagged_above=-999 required=5 tests=[AWL=-0.572, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1vI2ZOGjFjus for <>; Wed, 15 Dec 2010 21:46:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 456CA3A6E01 for <>; Wed, 15 Dec 2010 21:46:32 -0800 (PST)
Received: from squire.local ( []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id AD8AA4009B; Wed, 15 Dec 2010 23:00:46 -0700 (MST)
Message-ID: <>
Date: Wed, 15 Dec 2010 22:48:11 -0700
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: =?UTF-8?B?VGFudGVrIMOHZWxpaw==?= <>
References: <20101209141501.27588.92282.idtracker@localhost> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
OpenPGP: url=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030302030907050007020804"
Subject: Re: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-15.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Dec 2010 05:46:33 -0000

Hi Tantek, thanks for the feedback.

On 12/15/10 8:31 PM, Tantek Çelik wrote:

> One particularly important feature change that I wanted to comment on
> without delay however is the adoption of the new GENDER property.
> 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:
> 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:

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

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


Instead of:


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


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