Re: [Jmap] JSContact: gender property

Andreas Hauser <Andreas.Hauser@LMU.de> Thu, 23 December 2021 14:51 UTC

Return-Path: <Andreas.Hauser@LMU.de>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5EE3A16A2; Thu, 23 Dec 2021 06:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.123
X-Spam-Level:
X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lmu.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfy3d__PRomb; Thu, 23 Dec 2021 06:51:26 -0800 (PST)
Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4603A16A1; Thu, 23 Dec 2021 06:51:25 -0800 (PST)
Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 4JKY6c25ZpzycG; Thu, 23 Dec 2021 15:51:20 +0100 (CET)
Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=lmu.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lmu.de; h= x-mailer:references:message-id:date:date:in-reply-to:from:from :subject:subject:mime-version:content-type:content-type:received :received; s=postout; t=1640271079; bh=0LMj9hw9/FeH+N6ir89Nb+9dk Qld2/1x95pPU/iu9ds=; b=dE0chk/+V6BgmuzTjnmCcHS75iwNj038eVnAZuyWC xnlg+DsXaBFfIDTxM5sedY5DzxY6i9q/Y/GglGNXup4SS/oIIp4D3o82uKvfxGrn XO9rE8ttdxFeqbnggeAdKqTJ0euJ1noemtWAc0VoGXWc6IXO/9G9sYzyK2m4xtDb 6OAIvcZq7AS2oEmGXY70fntxJ/LsysjZUZZ841kqYVG7Mn6BW9UaeFKDIcB+k2PS N5XGn3JPNu7RlUL2LCz70RrlQlN2XMVtykWrzepagQ7lPUPVfP3zYBcNW3NCPAlV koJ0FyareDgHvzzQeJ4RrIfn2b0UG3tenMFyoKrIrqMTw==
X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de
Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id tcTBEGkgQ-V9; Thu, 23 Dec 2021 15:51:19 +0100 (CET)
Received: from smtpclient.apple (unknown [IPv6:2a02:810d:980:5f6c:e5fd:214e:dfde:4a42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by postout1.mail.lrz.de (Postfix) with ESMTPSA id 4JKY6b24NDzyTy; Thu, 23 Dec 2021 15:51:18 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_546A36D0-EB26-436A-B219-18EFEE5D4750"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Andreas Hauser <Andreas.Hauser@LMU.de>
In-Reply-To: <d78004af-bd2e-4d26-a5fc-174d2e5da0e3@www.fastmail.com>
Date: Thu, 23 Dec 2021 15:51:18 +0100
Cc: jmap@ietf.org, calsify@ietf.org
Message-Id: <E971A616-867E-4F2F-8BD2-31CEEB70D260@LMU.de>
References: <d78004af-bd2e-4d26-a5fc-174d2e5da0e3@www.fastmail.com>
To: Robert Stepanek <rsto@fastmailteam.com>
X-Mailer: Apple Mail (2.3693.40.0.1.81)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/7_vIO27v1dIfC4wkHHHnT-nAn9E>
Subject: Re: [Jmap] JSContact: gender property
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Dec 2021 14:51:31 -0000

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 <rsto@fastmailteam.com>:
> 
> 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.
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org <mailto:Jmap@ietf.org>
> https://www.ietf.org/mailman/listinfo/jmap <https://www.ietf.org/mailman/listinfo/jmap>