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;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