[Jmap] JSContact: gender property

[Robert Stepanek <[e-mail]>]

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.