Re: [VCARDDAV] two component GENDER
Tantek Çelik <tantek@cs.stanford.edu> Thu, 16 December 2010 23:57 UTC
Return-Path: <tantek@gmail.com>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDC53A6A28 for <vcarddav@core3.amsl.com>; Thu, 16 Dec 2010 15:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh3Wx9ipy8+I for <vcarddav@core3.amsl.com>; Thu, 16 Dec 2010 15:57:08 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 2EEB83A6A1F for <vcarddav@ietf.org>; Thu, 16 Dec 2010 15:57:08 -0800 (PST)
Received: by gyd12 with SMTP id 12so50400gyd.31 for <vcarddav@ietf.org>; Thu, 16 Dec 2010 15:58:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=gmail.com; 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 10.90.111.20 with SMTP id j20mr1573627agc.117.1292543933608; Thu, 16 Dec 2010 15:58:53 -0800 (PST)
MIME-Version: 1.0
Sender: tantek@gmail.com
Received: by 10.90.220.16 with HTTP; Thu, 16 Dec 2010 15:58:13 -0800 (PST)
In-Reply-To: <AANLkTi=Qcnw+e4vox_9QKLAuxYiCFyhMyP8wFvcAqrB3@mail.gmail.com>
References: <AANLkTikmTKSwBVYYtUmEnPB=9Vd9d9ei8KxS5e_-MWTQ@mail.gmail.com> <4D0A30FC.20201@stpeter.im> <1292519641.15091.6.camel@Nokia-N900> <AANLkTino=jVf6iAbs1A7jwRNBgbpm=R7z-btEwcaTbA9@mail.gmail.com> <AANLkTi=Qcnw+e4vox_9QKLAuxYiCFyhMyP8wFvcAqrB3@mail.gmail.com>
From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Thu, 16 Dec 2010 15:58:13 -0800
X-Google-Sender-Auth: tRLtAYLGPGkhH_AmEVIQURQ_Ee4
Message-ID: <AANLkTikMsop-juuN=Rdro23g5QXAqbuDSk9XOX2gZojy@mail.gmail.com>
To: Sarah Dopp <sarah@sarahdopp.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: vcarddav@ietf.org
Subject: Re: [VCARDDAV] two component GENDER
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Dec 2010 23:57:09 -0000
On Thu, Dec 16, 2010 at 15:40, Sarah Dopp <sarah@sarahdopp.com> 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: http://www.isna.org/faq/frequency 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 identity. > 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 microformats.org 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 Digg.com, 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 > Thanks, Tantek > On Thu, Dec 16, 2010 at 3:02 PM, Tantek Çelik <tantek@cs.stanford.edu> > wrote: >> >> On Thu, Dec 16, 2010 at 09:14, Florian Zeitz <florob@babelmonkeys.de> >> 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 >> >> -- >> http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5 >> _______________________________________________ >> VCARDDAV mailing list >> VCARDDAV@ietf.org >> https://www.ietf.org/mailman/listinfo/vcarddav > > > > -- > Sarah Dopp > site: http://sarahdopp.com / blog: http://doppjuice.com / tweet: > http://twitter.com/sarahdopp > art: http://genderfork.com / show: http://queeropenmic.com / love: > http://cultureconductor.com > > > _______________________________________________ > VCARDDAV mailing list > VCARDDAV@ietf.org > https://www.ietf.org/mailman/listinfo/vcarddav > > -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
- [VCARDDAV] two component GENDER (was Re: I-D Acti… Tantek Çelik
- Re: [VCARDDAV] two component GENDER (was Re: I-D … Simon Perreault
- Re: [VCARDDAV] two component GENDER Peter Saint-Andre
- Re: [VCARDDAV] two component GENDER Florian Zeitz
- Re: [VCARDDAV] two component GENDER Tantek Çelik
- Re: [VCARDDAV] two component GENDER Sarah Dopp
- Re: [VCARDDAV] two component GENDER Tantek Çelik
- Re: [VCARDDAV] two component GENDER Peter Saint-Andre
- Re: [VCARDDAV] two component GENDER Tantek Çelik
- Re: [VCARDDAV] two component GENDER Sarah Dopp
- Re: [VCARDDAV] two component GENDER Peter Saint-Andre
- Re: [VCARDDAV] two component GENDER Kevin Marks