Subject: [VCARDDAV] two component GENDER (was Re: I-D Action:draft-ietf-vcarddav-vcardrev-15.txt)

From: Tantek Çelik <[email-masked]>
Date: Thu, 16 Dec 2010 00:11:53 -0800

On Wed, Dec 15, 2010 at 21:48, Peter Saint-Andre <[email-masked]> wrote:
> 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.
>>
>> GENDER
>>
>> 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:
>>
>> http://www.ietf.org/mail-archive/web/vcarddav/current/msg01784.html
>>
>> 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:
>>
>> https://wiki.mozilla.org/VCard4-draft-13-review#GENDER
>
> 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
>  reserved.

Right, this is what I didn't understand, as just a single text value
with 2 predefined values and <free-form text> was not proposed before
this.

> If I recall correctly, the idea was that free-form text would be
> allowed, such as:
>
>   GENDER:VALUE=text:Fellow

I think that's where the miscommunication was, probably due to my
failure to provide specific syntax examples at the time.  The idea was
that free-form text would be allowed IN ADDITION, such as:

GENDER:M;Fellow

> Instead of:
>   GENDER:male

Instead of

GENDER:M

> People could also register well-known values, such as:
>
>   GENDER:queer
>
> 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.

Close.

GENDER:;queer

(though in practice I'd expect many values, like 'queer', to be left
unregistered, as different people have quite different definitions).

More examples:

GENDER:M
GENDER:F
GENDER:M;Fellow
GENDER:F;Bird
GENDER:O;intersex
GENDER:;queer

All from here for reference:

https://wiki.mozilla.org/VCard4-draft-13-review#GENDER

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

---

From: Simon Perreault <[email-masked]>
Date: Thu, 16 Dec 2010 08:56:44 -0500

> with 2 predefined values and <free-form text> was not proposed before

Trying to find an explanation...

The two-component proposal was on the slides. See slide 9:
http://www.ietf.org/proceedings/79/slides/vcarddav-0.pdf
If the slides were not accurate, I did send them before the meeting, so
there was the possibility to look at them and send feedback.

I also wanted to point you to the full audio recording, but it looks
like there is a gap that falls exactly on when our meeting happened:
http://79archive.dyndns.org/ietf79/
I think we're in channel 4, wednesday 15:10-16:10. But I can't find it.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 16 Dec 2010 08:32:12 -0700

> unregistered, as different people have quite different definitions).

That seems to be endemic to the topic.

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).

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 16 Dec 2010 18:14:01 +0100

> someone registered "queer" with IANA).
+1
Registering values for a free-text field (which #1 would be as I understand it) seems rather strange.

--
Florian Zeitz

---

From: Tantek Çelik <[email-masked]>
Date: Thu, 16 Dec 2010 15:02:53 -0800

> 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

---

From: Sarah Dopp <[email-masked]>
Date: Thu, 16 Dec 2010 15:40:56 -0800

"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. 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

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? 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. I suspect, though, that in actual
application, only one component will be used at a time.

No recommendations or endorsements here. Just observations.

~Sarah

On Thu, Dec 16, 2010 at 3:02 PM, Tantek Çelik <[email-masked]>wrote:

> > Registering values for a free-text field (which #1 would be as I
> understand
> > it) seems rather strange.
>
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> 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

---

From: Tantek Çelik <[email-masked]>
Date: Thu, 16 Dec 2010 15:58:13 -0800

On Thu, Dec 16, 2010 at 15:40, Sarah Dopp <[email-masked]> wrote:
> 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

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

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

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.

Thanks,

Tantek

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 16 Dec 2010 17:19:54 -0700

> options for the sex component and finer granularity of gender

Hi Tantek and Sarah,

Are you proposing that we have two fields, SEX and GENDER?

The SEX field would have values of M,F,U,O, but could be left empty.

The GENDER field would be free-form text.

Am I hearing you correctly?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tantek Çelik <[email-masked]>
Date: Thu, 16 Dec 2010 16:40:15 -0800

> Am I hearing you correctly?

Not two fields.

One structured field "GENDER" with two components: "sex" and "gender
identity", as described here:

These should not be disconnected into separate fields because they are
frequently tightly dependent.

This essence of the proposal (one structured field with two
components) is unchanged since I wrote up my draft 13 review.

Thanks,

Tantek

---

From: Sarah Dopp <[email-masked]>
Date: Thu, 16 Dec 2010 16:45:50 -0800

Thanks for addressing these, Tantek.  I like your thinking, and your plan
has my support.

Sarah

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 16 Dec 2010 17:52:04 -0700

> components) is unchanged since I wrote up my draft 13 review.

OK, thanks for the clarification. That sounds like a reasonable approach
to me (with my individual contributor hat on). I look forward to hearing
from the document editors and other participants.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Kevin Marks <[email-masked]>
Date: Thu, 16 Dec 2010 19:19:35 -0800

I think this makes sense as a way to fit the two facets together
clearly, without either straightjacketing the other. If we take the
long list of user-enetered genders on metafilter, they map into this
pretty clearly:

http://stuff.metafilter.com/genders/genderfield.txt

+-- Uses: 109640; Tokens: 1 -----------------+

GENDER:U;
+-- Uses: 3589; Tokens: 1 -----------------+
male
GENDER:M;male
+-- Uses: 1237; Tokens: 1 -----------------+
female
GENDER:F;female
+-- Uses: 592; Tokens: 1 -----------------+
m
GENDER:M;m
+-- Uses: 218; Tokens: 1 -----------------+
f
GENDER:F;f
+-- Uses: 119; Tokens: 1 -----------------+
dude
GENDER:M;dude
+-- Uses: 89; Tokens: 1 -----------------+
lady
GENDER:F;lady
+-- Uses: 80; Tokens: 1 -----------------+
girl
GENDER:F;girl
+-- Uses: 76; Tokens: 1 -----------------+
yes
GENDER:U;yes
+-- Uses: 73; Tokens: 1 -----------------+
xy
GENDER:M;xy
+-- Uses: 53; Tokens: 1 -----------------+
boy
GENDER:M;boy
+-- Uses: 51; Tokens: 1 -----------------+
guy
GENDER:M;male
+-- Uses: 49; Tokens: 1 -----------------+
xx
GENDER:F;xx
+-- Uses: 48; Tokens: 1 -----------------+
man
GENDER:M;man
+-- Uses: 39; Tokens: 1 -----------------+
mail
GENDER:U;mail
+-- Uses: 26; Tokens: 1 -----------------+
femme
GENDER:F;femme
+-- Uses: 24; Tokens: 1 -----------------+
chick
GENDER:F;chick
+-- Uses: 22; Tokens: 1 -----------------+
bloke
GENDER:M;bloke
+-- Uses: 21; Tokens: 1 -----------------+
woman
GENDER:F;woman
+-- Uses: 18; Tokens: 2 -----------------+
girly girl
GENDER:F;girly girl
male.
GENDER:M;male.
+-- Uses: 14; Tokens: 1 -----------------+
outie
GENDER:M;outie
+-- Uses: 13; Tokens: 1 -----------------+
girly
GENDER:F;girly
+-- Uses: 12; Tokens: 3 -----------------+
male-ish
GENDER:M;male-ish
nuts
GENDER:U;nuts
robot
GENDER:N;robot
+-- Uses: 10; Tokens: 6 -----------------+
fella
GENDER:M;fella
fembot
GENDER:F;fembot
innie
GENDER:F;innie
manly
GENDER:M;manly
mostly male
GENDER:O;mostly male
â™‚
GENDER:U;â™‚