Subject: [Jmap] JSContact: gender property

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 23 Dec 2021 14:37:46 +0100

One open question for JSContact was if and how to store gender-specific information for a contact. In the next RFC version, we intend to address this by introduction of the "grammaticalGender" property. We look forward to your feedback.
 * The "grammaticalGender" property defines which grammatical gender to use to address or refer to the contact that is represented by the JSContact object.
 * For example, several human languages require a grammatical gender for salutations. In German the salutations "Sehr geehrte" and "Sehr geehrter" are used for single-person female and male  addreeses, respectively. The "grammaticalGender" property defines which gender to use in this case. Its value can be overridden per language in the "localizations" property.
 * The allowed values are (in alphabetical order): "animate", "female", "inanimate", "male", "neuter". Other grammatical genders need to be registered.

A related property in VCARD is the GENDER <https://datatracker.ietf.org/doc/html/rfc6350#section-6.2.7> property, which aims to store both the biological sex and the gender identity of a contact. However, GENDER does not adequately address the purpose of the "grammaticalGender" property:
 * human sex and grammatical gender of a contact may differ, so the biological sex component of GENDER is no indicator how to grammatically address this contact.
 * the gender identity of GENDER is a free-text value, which introduces ambiguity which grammatical gender to use. The examples for GENDER strengthen this assumption.

This leaves the question if we need to introduce an additional property to map GENDER to JSContact. We do not think so:
 * It seems that the majority of applications used the biological sex component of GENDER to store the grammatical gender of a contact. This now is provided by the "grammaticalGender" property and mapping from VCARD to JSContact should be straight-forward.
 * For applications that actually require to store biological sex, the current definition of the GENDER sex component seems inadequate. While it allows for a superset of ISO/IEC 521 <https://en.wikipedia.org/wiki/ISO/IEC_5218>8, it  does not support for "intersex" (Note how the examples for GENDER suggest to store "intersex" as gender identity, which does not allow intersex persons to define a preferred gender identity). In addition, even biological sex seems to be ambiguous <https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(19)32764-3/fulltext>.
 * We do not know if a free-text gender identity is useful for applications. Gender studies suggest that gender identities may differ by context and that there as many genders likely to exist as human beings. This suggests that more complex value types might be required. Most likely, processing of gender is application-specific and we are no experts to provide a standard that fits all requirements.

Cheers,
Robert

P.S.: Cross-posting this both to JMAP and CALEXT as both working groups have expertise on address book and contact applications.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 23 Dec 2021 08:48:18 -0500

I also wonder if we might want to add a property for a user's preferred 
pronouns.  vCard doesn't currently have such a property, but it was 
mentioned somewhere (CalConnect?) that this is something that should be 
considered as an addition.  I believe that I have a draft of a draft for 
such a vCard property laying around somewhere.

On 12/23/21 8:37 AM, Robert Stepanek wrote:
> One open question for JSContact was if and how to store 
> gender-specific information for a contact. In the next RFC version, we 
> intend to address this by introduction of the "grammaticalGender" 
> property. We look forward to your feedback.
>
>   * The "grammaticalGender" property defines which grammatical gender
>     to use to address or refer to the contact that is represented by
>     the JSContact object.
>   * For example, several human languages require a grammatical gender
>     for salutations. In German the salutations "Sehr geehrte" and
>     "Sehr geehrter" are used for single-person female and male 
>     addreeses, respectively. The "grammaticalGender" property defines
>     which gender to use in this case. Its value can be overridden per
>     language in the "localizations" property.
>   * The allowed values are (in alphabetical order): "animate",
>     "female", "inanimate", "male", "neuter". Other grammatical genders
>     need to be registered.
>
>
> A related property in VCARD is the GENDER 
> <https://datatracker.ietf.org/doc/html/rfc6350#section-6.2.7> 
> property, which aims to store both the biological sex and the gender 
> identity of a contact. However, GENDER does not adequately address the 
> purpose of the "grammaticalGender" property:
>
>   * human sex and grammatical gender of a contact may differ, so the
>     biological sex component of GENDER is no indicator how to
>     grammatically address this contact.
>   * the gender identity of GENDER is a free-text value, which
>     introduces ambiguity which grammatical gender to use. The examples
>     for GENDER strengthen this assumption.
>
>
> This leaves the question if we need to introduce an additional 
> property to map GENDER to JSContact. We do not think so:
>
>   * It seems that the majority of applications used the biological sex
>     component of GENDER to store the grammatical gender of a contact.
>     This now is provided by the "grammaticalGender" property and
>     mapping from VCARD to JSContact should be straight-forward.
>   * For applications that actually require to store biological sex,
>     the current definition of the GENDER sex component seems
>     inadequate. While it allows for a superset ofISO/IEC 521
>     <https://en.wikipedia.org/wiki/ISO/IEC_5218>8, it  does not
>     support for "intersex" (Note how the examples for GENDER suggest
>     to store "intersex" as gender identity, which does not allow
>     intersex persons to define a preferred gender identity). In
>     addition, even biological sex seems to be ambiguous
>     <https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(19)32764-3/fulltext>.
>   * We do not know if a free-text gender identity is useful for
>     applications. Gender studies suggest that gender identities may
>     differ by context and that there as many genders likely to exist
>     as human beings. This suggests that more complex value types might
>     be required. Most likely, processing of gender is
>     application-specific and we are no experts to provide a standard
>     that fits all requirements.
>
>
> Cheers,
> Robert
>
> P.S.: Cross-posting this both to JMAP and CALEXT as both working 
> groups have expertise on address book and contact applications.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: Andreas Hauser <[email-masked]>
Date: Thu, 23 Dec 2021 15:51:18 +0100

Dear Robert,

Not only is there grammaticalGender but also salutations often differ based on relationship, like "Dear Robert" / "Dear Sir“ or „Lieber Robert“ / „Sehr geehrter Herr Stepanek“.

To make this most useful in practice, a field for salutation might be considered, taking variables for first name (e.g. %FN), nick name and last name (e.g.%LN): „Dear %FN“, „Dear Professor %LN“ etc.

This would also decouple the useful salutation from the less and less useful gender / sex.
Where still, should the salutation field not be filled, one might consider suggestions from the gender / sex fields.

Best
Andreas

> Am 23.12.2021 um 14:37 schrieb Robert Stepanek <[email-masked]>:
> 
> The "grammaticalGender" property defines which grammatical gender to use to address or refer to the contact that is represented by the JSContact object.
> For example, several human languages require a grammatical gender for salutations. In German the salutations "Sehr geehrte" and "Sehr geehrter" are used for single-person female and male  addreeses, respectively. The "grammaticalGender" property defines which gender to use in this case. Its value can be overridden per language in the "localizations" property.
> The allowed values are (in alphabetical order): "animate", "female", "inanimate", "male", "neuter". Other grammatical genders need to be registered.
> 
> human sex and grammatical gender of a contact may differ, so the biological sex component of GENDER is no indicator how to grammatically address this contact.
> the gender identity of GENDER is a free-text value, which introduces ambiguity which grammatical gender to use. The examples for GENDER strengthen this assumption.
> 
> It seems that the majority of applications used the biological sex component of GENDER to store the grammatical gender of a contact. This now is provided by the "grammaticalGender" property and mapping from VCARD to JSContact should be straight-forward.
> For applications that actually require to store biological sex, the current definition of the GENDER sex component seems inadequate. While it allows for a superset of ISO/IEC 521 <https://en.wikipedia.org/wiki/ISO/IEC_5218>8, it  does not support for "intersex" (Note how the examples for GENDER suggest to store "intersex" as gender identity, which does not allow intersex persons to define a preferred gender identity). In addition, even biological sex seems to be ambiguous <https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(19)32764-3/fulltext>.
> We do not know if a free-text gender identity is useful for applications. Gender studies suggest that gender identities may differ by context and that there as many genders likely to exist as human beings. This suggests that more complex value types might be required. Most likely, processing of gender is application-specific and we are no experts to provide a standard that fits all requirements.
> 
> Cheers,
> Robert
> 
> Jmap mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jmap <https://www.ietf.org/mailman/listinfo/jmap>

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 24 Dec 2021 06:55:59 +1100

Thanks Robert, I think this is a good, well-reasoned proposal.

On Fri, 24 Dec 2021, at 12:48 AM, Ken Murchison wrote:
> I also wonder if we might want to add a property for a user's preferred pronouns.

Is that not covered by grammaticalGender?

> Not only is there grammaticalGender but also salutations often differ based on relationship, like "Dear Robert" / "Dear Sir“ or „Lieber Robert“ / „Sehr geehrter Herr Stepanek“.

That feels out-of-scope to me, especially if you have to start introducing variable substitution.

—Neil

---

From: "Darcy Iris" <[email-masked]>
Date: Fri, 24 Dec 2021 09:08:27 +1300

Hi! Non-binary trans person here.

> Is that not covered by grammaticalGender?

No, it is not - many people use pronouns that are "outside the norm" so to speak.

As a personal example, I use ae/aer pronouns (see https://pronoun.is/ae/aer for usage examples), and would much prefer people use those even though I would set the theoretical grammaticalGender field for myself to "animate".

Gender is complex, and if you're going to attempt to represent it in anything, that implementation needs to be respectful.

My personal recommendation here is not to use a grammaticalGender field as you've described, instead having only a pronouns field, that allows specifying the "full set" (subject pronoun, object pronoun, possessive determiner, possessive pronoun, reflexive pronoun). Not only does this mean it's relatively language-agnostic, it also means that any implementation can refer to the contact using their actual pronouns. 

—
*Darcy Iris* (ae/aer or they/them pronouns)
[email-masked] • +1 (380) 214-7469 <tel:+13802147469> • +64 20 4747 797 <tel:+64204747797>