Re: [VCARDDAV] two component GENDER
Sarah Dopp <sarah@sarahdopp.com> Fri, 17 December 2010 00:44 UTC
Return-Path: <doppjuice@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 A48D33A6A2C for <vcarddav@core3.amsl.com>; Thu, 16 Dec 2010 16:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.376
X-Spam-Level:
X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, 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 JFffg8BtWRZw for <vcarddav@core3.amsl.com>; Thu, 16 Dec 2010 16:44:25 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 564963A6A21 for <vcarddav@ietf.org>; Thu, 16 Dec 2010 16:44:25 -0800 (PST)
Received: by yxt33 with SMTP id 33so65164yxt.31 for <vcarddav@ietf.org>; Thu, 16 Dec 2010 16:46:11 -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:content-type; bh=mEXhPH41YXMQM06ba1DS0TFEY2P363OUiNhUUmF3EjA=; b=Iy8mqgoX1oT6MDi3TuWVBZitpLxkKJtn0q6rVJ2drhGmI04K2IweHKtY/GywFR0lr6 ki/gTHX9lS+Ag4LVSRuToXWeKSqcGXFs0QV61yNsrK13SypXMYa6B8HZKSgLT5H8HuzB vqSYl3iSocPfaOPC2DSXYJoHMUyCI0Ce4ecZw=
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:content-type; b=p8k15xGOxwugJp56a3a9fa1jTVOPdiBj/M62Z112BIEgG9tr6Txx1DbjxaT0dSRxix GpnDzRic4IrpXlMp89hfZWZhP73Giw5jzb36JVxlT3UsEytz1PP2EiG0oEwvHG8/L1f9 OzCD0Velk4/p59xUEg+Z6giGPzrtdlEPZltow=
Received: by 10.236.109.12 with SMTP id r12mr51934yhg.32.1292546770885; Thu, 16 Dec 2010 16:46:10 -0800 (PST)
MIME-Version: 1.0
Sender: doppjuice@gmail.com
Received: by 10.236.109.45 with HTTP; Thu, 16 Dec 2010 16:45:50 -0800 (PST)
In-Reply-To: <AANLkTikMsop-juuN=Rdro23g5QXAqbuDSk9XOX2gZojy@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> <AANLkTikMsop-juuN=Rdro23g5QXAqbuDSk9XOX2gZojy@mail.gmail.com>
From: Sarah Dopp <sarah@sarahdopp.com>
Date: Thu, 16 Dec 2010 16:45:50 -0800
X-Google-Sender-Auth: 9_BYVfMWsgCpZXeLmdQn5jAm350
Message-ID: <AANLkTi=w67qKXG9ufgEoLV4k9apbAWa1yryKCa2r75Ox@mail.gmail.com>
To: vcarddav@ietf.org
Content-Type: multipart/alternative; boundary="0023547c8b1d225e5c0497907f28"
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: Fri, 17 Dec 2010 00:44:27 -0000
Thanks for addressing these, Tantek. I like your thinking, and your plan has my support. Sarah On Thu, Dec 16, 2010 at 3:58 PM, Tantek Çelik <tantek@cs.stanford.edu>wrote: > 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 > -- 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] 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