Re: [VCARDDAV] two component GENDER

Tantek Çelik <> Thu, 16 December 2010 23:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EDC53A6A28 for <>; Thu, 16 Dec 2010 15:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mh3Wx9ipy8+I for <>; Thu, 16 Dec 2010 15:57:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2EEB83A6A1F for <>; Thu, 16 Dec 2010 15:57:08 -0800 (PST)
Received: by gyd12 with SMTP id 12so50400gyd.31 for <>; Thu, 16 Dec 2010 15:58:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=8oUBVZJGgy4Z8+7vCk7zrnzi2KqzgAIzXFEymYKqR+s=; b=tNEUs9F6hfp3KzzG+vpx1Zw7Fh6SqjpzyzHtLLVer9DfOsTIPVEd37rOEvBec91WOk k9yJ2liCQkAiLPVl01nKcUQsvtLDAMlhwT9XLFHKdpF8Si8rK48A3g/wJ6hDY5J0tebU PRhm3KeGje9DETWJP20l5srWW3PKQhYzsZat8=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=dFv2pTpHPm6ANmYJIsyo+pQ6ruNNRv7fdWTMwev+t6MuiFnbsqyp02UAvI1KIHTFmq phiMnoFJaTMxsEKI5OAOxjHNRLGDjrHS0tgswrcGgfgBte8/AyRMAj7wGAq2sE3AV2MV FwgWvhI2Nj0K2g4CfHvAgRIhIAVLrHoSAKZgo=
Received: by with SMTP id j20mr1573627agc.117.1292543933608; Thu, 16 Dec 2010 15:58:53 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 16 Dec 2010 15:58:13 -0800 (PST)
In-Reply-To: <>
References: <> <> <1292519641.15091.6.camel@Nokia-N900> <> <>
From: =?UTF-8?Q?Tantek_=C3=87elik?= <>
Date: Thu, 16 Dec 2010 15:58:13 -0800
X-Google-Sender-Auth: tRLtAYLGPGkhH_AmEVIQURQ_Ee4
Message-ID: <>
To: Sarah Dopp <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [VCARDDAV] two component GENDER
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 23:57:09 -0000

On Thu, Dec 16, 2010 at 15:40, Sarah Dopp <> wrote:
> "I'd prefer to *not* make the sex component extensible for now, until a
> good case can be made based on real world examples that demonstrates
> that such extensibility is necessary / useful above and beyond the use
> cases for flexibility gender identity (which are already covered by
> that respective free-text component)."
> The real-world example there is Intersex.

Agreed, and that's specifically the use-case for the "O(ther)"
enumerated SEX component value.

> Some people are born with blended
> sex characteristics, either physical or hormonal or both.  In most of these
> cases, parents and doctors assign the person to the gender they resemble
> most (and that assignment may or may not stick as the person grows). But the
> medical sex is still different.  For stats on the frequency of the different
> types of these case, look at the Intersex Society of North America's
> numbers:

Agreed. An intersex person may according to background/preference
choose to list M, F, or O as their SEX component.

> That said, since this project is more about data management and personal
> identity than medical records, I'm not quite sure what to advocate for
> here.
> Tantek, do you think there are cases where a form will ask users for both
> their sex AND their gender?

Implicitly, yes, and there are already some (a few) sites that do this.

That is, there are sites (e.g. Digg, and previously, Pownce) that
provide a long list of possible "Gender" values which are a
combination of various "male" labels, "female" labels, and other
labels.  By choosing one of these options, the user chooses a gender
identity label, and an implied sex in many of the cases as well.

> Your system sounds like good data management: it
> will allow any system to have either pre-defined or free-form values without
> one data set muddling up the other.

This is *precisely* correct, and in fact, the goal here is to allow
for backward compatibility with the (perhaps simplistic) data models
of some sites, while enabling such systems to evolve to allow more
options for the sex component and finer granularity of gender

> I suspect, though, that in actual
> application, only one component will be used at a time.

In practice I foresee the majority of sites using the enum to start
with (per the data gathered at on real world
examples), with a few sites using both.

My *hope* is that as with many formats, that newer systems that
support the vCard4 contact information schema will take into
consideration the possibility of supporting both, and may do so,
either like, or perhaps with their own UI.

> No recommendations or endorsements here. Just observations.

I hope the above clarifications help.  Please let me know if you have
any suggested improvements, or if there are any problems with the
above examples and explanations.

> ~Sarah



> On Thu, Dec 16, 2010 at 3:02 PM, Tantek Çelik <>
> wrote:
>> On Thu, Dec 16, 2010 at 09:14, Florian Zeitz <>
>> wrote:
>> > Some time ago stpeter wrote:
>> >> But, if someone registers "queer", the result would be what?
>> >>
>> >> 1. GENDER:;queer
>> >>
>> >> or
>> >>
>> >> 2. GENDER:queer
>> >>
>> >> My impression from the discussion in Beijing was #2, not #1 (if, again,
>> >> someone registered "queer" with IANA).
>> >>
>> > +1
>> > Registering values for a free-text field (which #1 would be as I
>> > understand
>> > it) seems rather strange.
>> Peter, Florian, I stand corrected.
>> You're right, it doesn't make sense to have an IANA registry for a
>> free-text field (gender-identity component of gender).
>> That leaves the question of whether or not it makes sense to have the
>> sex component of gender be extensible / registerable.
>> Frankly I'm not sure that it does.
>> Or rather, I believe the enum set proposed (M,F,O,N,U) for the sex
>> component is sufficient for vCard4.
>> Since we already have a free-text field for arbitrary labeling with
>> gender-identity, I believe that maps well to our goals of sufficient
>> flexibility to allow expression of human diversity.
>> I'd prefer to *not* make the sex component extensible for now, until a
>> good case can be made based on real world examples that demonstrates
>> that such extensibility is necessary / useful above and beyond the use
>> cases for flexibility gender identity (which are already covered by
>> that respective free-text component).
>> Thanks,
>> Tantek
>> --
>> - I made an HTML5 tutorial!
>> _______________________________________________
>> VCARDDAV mailing list
> --
> Sarah Dopp
> site:   /   blog:   /   tweet:
> art:   /   show:   /   love:
> _______________________________________________
> VCARDDAV mailing list

-- - I made an HTML5 tutorial!