From nobody Wed Dec 1 00:53:11 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE6D3A0833; Wed, 1 Dec 2021 00:53:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163834879016.21268.2963440848761078147@ietfa.amsl.com> Date: Wed, 01 Dec 2021 00:53:10 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-09.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 08:53:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSContact: A JSON representation of contact data Authors : Robert Stepanek Mario Loffredo Filename : draft-ietf-jmap-jscontact-09.txt Pages : 25 Date : 2021-12-01 Abstract: This specification defines a data model and JSON representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-jscontact-09.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 1 01:51:12 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EB13A08ED; Wed, 1 Dec 2021 01:51:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.40.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163835227021.2144.17754224908828451261@ietfa.amsl.com> Date: Wed, 01 Dec 2021 01:51:10 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-vcard-08.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 09:51:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSContact: Converting from and to vCard Authors : Mario Loffredo Robert Stepanek Filename : draft-ietf-jmap-jscontact-vcard-08.txt Pages : 41 Date : 2021-12-01 Abstract: This document defines how to convert contact information as defined in the JSContact [draft-ietf-jmap-jscontact] specification from and to vCard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact-vcard/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-vcard-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-vcard-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Dec 5 23:34:21 2021 Return-Path: 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 3ED153A0804 for ; Sun, 5 Dec 2021 23:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 n8Flw_7LBEaQ for ; Sun, 5 Dec 2021 23:34:16 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA2D3A0803 for ; Sun, 5 Dec 2021 23:34:15 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id o1so17775241uap.4 for ; Sun, 05 Dec 2021 23:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vqTVIxLO6f1tiGXhfqpZ6NYf853QT2blOk07Cce9rkc=; b=nSoZmmQds971gLDxsAsppI8BXuzsU8Oo//1aiW37/uZ7dHqn0RQYiyl/ja4IoWsFyp 3ZJ9W1JwKLlAQV4t1ZVRV4yeVDjvF9lQqBWFPfm6NTWvaPKxbD38D7EzeZ5zYS+AvhtW pzyhFwRQ9noWSPhVwExOAj1DWCFMTg7xhmGpaxRX+3aT9bLoMFFE28bqWH6Y5hgoHOST R8Oz9zUTlFzv6AMW182i7nbbaSWcT14hxpvYDzQQ7NWNLJI3SqihnmCL/hQ6kxDvxFmD Ci4NUEKsbBTqq6wAZ9Ia6A/KWyuh6m5xK9XB61t5fRHx8kb5SIzCQ2xP5qCtoaI0HOJ6 cB1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vqTVIxLO6f1tiGXhfqpZ6NYf853QT2blOk07Cce9rkc=; b=Y6qCY+P2Iwc3NtMQb48HJsTBKQxJi3dUqZR/Z2nTSRTlN1qWJHIHSQCv0Ohb5tIE0f 9su0afdTr92hoGlwzXztLONHxpw/rDoEbDDOqnPUfp+CwPlLFhqAUiA5vX6TKbwKlRm4 kiyEKMD/jGeP8ec/HniD4TEZUnoo679jRAp0sA+hFiZrHW3a4e+G8DUpy2zTCV3ijz3r QFJhTb4BJC2QPg2hWM6Ol0RR98sLFZhucBvZkOkwGKZ8SskjXKmeO9XHLLuiwVNZiP39 UOgEDljAUSrGGqO9Mz1KPugq3e81zSwBXFS1wTlKFi2QFsGIa3w01G9CZfVtxIvToaUH h4/A== X-Gm-Message-State: AOAM533oJlUaJRZdLQBmBNtyMgj66WyNTZCFksMMzkva26upZDRoVOGb HdWw+AAQfe/+CE2dqpcQA2llB+DMKc4KH5D6bgCQTho1 X-Google-Smtp-Source: ABdhPJw558a5IInQAFby/bgz5ahv5i6oei65wkw2IGUTeuCT0OIQ6XFhBTBvuWFhXkHhy+QLjyaG/y8SGUM1FOsrtFU= X-Received: by 2002:a67:3382:: with SMTP id z124mr34089014vsz.57.1638776053403; Sun, 05 Dec 2021 23:34:13 -0800 (PST) MIME-Version: 1.0 References: <163726377805.25481.9069755452446236188@ietfa.amsl.com> In-Reply-To: <163726377805.25481.9069755452446236188@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sun, 5 Dec 2021 23:34:01 -0800 Message-ID: To: jmap@ietf.org Content-Type: multipart/alternative; boundary="0000000000008793d905d27548bc" Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-smime-11.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2021 07:34:20 -0000 --0000000000008793d905d27548bc Content-Type: text/plain; charset="UTF-8" Hi, just to confirm -- this one's ready to ship to the RFC Editor? -MSK On Thu, Nov 18, 2021 at 11:29 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the JSON Mail Access Protocol WG of the IETF. > > Title : S/MIME signature verification extension to JMAP > Author : Alexey Melnikov > Filename : draft-ietf-jmap-smime-11.txt > Pages : 10 > Date : 2021-11-18 > > Abstract: > This document specifies an extension to JMAP for Mail (RFC 8621) for > returning S/MIME signature verification status. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-11 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > --0000000000008793d905d27548bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, just to confirm -- this one's ready to ship t= o the RFC Editor?

-MSK

On Thu, Nov 18, 20= 21 at 11:29 AM <internet-dra= fts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the JSON Mail Access Protocol WG of the IETF.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= S/MIME signature verification extension to JMAP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Alex= ey Melnikov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-jmap-smime-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-11-18

Abstract:
=C2=A0 =C2=A0This document specifies an extension to JMAP for Mail (RFC 862= 1) for
=C2=A0 =C2=A0returning S/MIME signature verification status.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-j= map-smime/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/= draft-ietf-jmap-smime-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-jmap-smime-11


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--0000000000008793d905d27548bc-- From nobody Mon Dec 6 03:09:07 2021 Return-Path: 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 68EBE3A03FA for ; Mon, 6 Dec 2021 03:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 KToDFwOoTIA6 for ; Mon, 6 Dec 2021 03:09:01 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAE03A03F3 for ; Mon, 6 Dec 2021 03:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1638788939; d=isode.com; s=june2016; i=@isode.com; bh=/9T3h0o80rdl9ju2lEyQAh6yehmiBMXHg9/yD1aQiLA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=NVZzmuso2VLjIJdjFE+1tojjAPN2M9nbX1Fzg/iP3KaLZYFZcWLanm+5rjmIAEijzva4DP 5Rdls53hlVghsbW4CEogyW6h4uXMO8J+axCVq3uSkHK/irakBzcmasWqqNiF9OW6GAQMP+ etfasXh/RiRKkkKCFpD4JbUyYH7uxjo=; Received: from [192.168.1.222] (host31-49-219-12.range31-49.btcentralplus.com [31.49.219.12]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 6 Dec 2021 11:08:58 +0000 Message-ID: Date: Mon, 6 Dec 2021 11:08:38 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 To: "Murray S. Kucherawy" , jmap@ietf.org References: <163726377805.25481.9069755452446236188@ietfa.amsl.com> From: Alexey Melnikov In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------YknMV7WX1KCiRrzy0KcmJlqH" Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-smime-11.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2021 11:09:06 -0000 --------------YknMV7WX1KCiRrzy0KcmJlqH Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable On 06/12/2021 07:34, Murray S. Kucherawy wrote: > Hi, just to confirm -- this one's ready to ship to the RFC Editor? I have a few minor comments from Neil to address, so this will require 1=20 more revision. > -MSK > > On Thu, Nov 18, 2021 at 11:29 AM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the JSON Mail Access Protocol WG of > the IETF. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: S/MIME signature verification extension > to JMAP > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := Alexey Melnikov > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draf= t-ietf-jmap-smime-11.txt > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: 10 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2021-11-18 > > Abstract: > =C2=A0 =C2=A0This document specifies an extension to JMAP for Mail (RF= C > 8621) for > =C2=A0 =C2=A0returning S/MIME signature verification status. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jmap-smime-11 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------YknMV7WX1KCiRrzy0KcmJlqH Content-Type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable

On 06/12/2021 07:34, Murray S. Kucherawy wrote:

Hi, just to confirm -- this one's ready to ship to the RFC Editor?
I have a few minor comments from Neil to address, so this will require 1 more revision.
-MSK

On Thu, Nov 18, 2021 at 11:29 AM <interne= t-drafts@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the JSON Mail Access Protocol WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: S/MIME signature verification extension to JMAP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Alexey Melnikov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : = draft-ietf-jmap-smime-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 : 2021-11-18

Abstract:
=C2=A0 =C2=A0This document specifies an extension to JMAP for Mail= (RFC 8621) for
=C2=A0 =C2=A0returning S/MIME signature verification status.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-jmap-smime/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc= /html/draft-ietf-jmap-smime-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-jmap-smime-11


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-draf= ts/


_______________________________________________
Jmap mailing list
Jmap@ie= tf.org
https://www.ietf.org/mailman/lis= tinfo/jmap

_______________________________=
________________
Jmap mailing list
Jmap@iet=
f.org
https://www.ietf.org/mailman/listinfo/jmap
--------------YknMV7WX1KCiRrzy0KcmJlqH-- From nobody Mon Dec 6 16:42:53 2021 Return-Path: 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 3FCB93A0C9E for ; Mon, 6 Dec 2021 16:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net 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 7CYtEAAOiNGJ for ; Mon, 6 Dec 2021 16:42:48 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 6C20B3A0C9C for ; Mon, 6 Dec 2021 16:42:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qxmcevLEtfFD6q9q60fnMFLUFIVh605ml0Lt+3tU5UI=; b=ELZpGJZdmvwiWueousJfhwglrX 5kHrJtW1ZpPQD8pa/Du6I/DUeDEZuRIVwgWlC/siYxPNaSe0F74g3t94843P/Vr+6+njpFGZqLA5K uuJWAGejJSLONE4+MHNO7lB2QrTBZ7MZYp/LYnnuJnHBcfkopJmmKcI0M7mX6XI3xZYM=; Received: from [64.71.6.2] (helo=[10.100.11.204]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1muOZB-0003Ro-AC; Mon, 06 Dec 2021 16:42:45 -0800 From: Jim Fenton To: Bron Gondwana Cc: IETF JMAP Mailing List Date: Mon, 06 Dec 2021 16:42:44 -0800 X-Mailer: MailMate (1.14r5820) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; markup=markdown Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Jmap] WGLC review of draft-jmap-blob-07 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 00:42:51 -0000 I had a look at draft-ietf-jmap-blob-07, and have a few comments. Please = bear in mind that I don=E2=80=99t have a great deal of experience with th= e other jmap documents, so some of this might be due to that. General: I found the large number of examples in the document to be a little distr= acting. I would prefer to see them in a non-normative appendix. At a mini= mum, it should be made clear that they=E2=80=99re informative examples, s= o they aren=E2=80=99t depended upon in the event of a conflict between th= e normative text and the example. Specific sections: Section 3: This appears to be a normative reference to [RFC8620], so that= document should be moved from informative to normative in the references= =2E Section 3.1: =E2=80=9CThis=E2=80=9D is apparently a reference to the sect= ion title. What is it about =E2=80=9Cthis=E2=80=9D that represents suppor= t: I guess the advertisement of this string in the capabilities object? P= lease make that more specific so that the section fully specifies what ha= ppens. What happens if some of the parameters (e.g., MaxSizeBlobSet) aren= =E2=80=99t included: do they assume default values are are the limits non= existent? If this appears in accountCapabilities, I presume it also has t= o appear in capabilities; is that specified somewhere? Section 4.1.1: Is this a subset of the Blob/set method, and if so how is = it distinguished? =E2=80=9Cexactly one of=E2=80=9D, =E2=80=9CAlso optiona= lly=E2=80=9D isn=E2=80=99t as formal a definition as I=E2=80=99m used to = in IETF standards-track documents. Often, something like this is specifie= d using ABNF. I don=E2=80=99t have a good idea if this is unambiguous or = not. =E2=80=9Ccan not contain=E2=80=9D -> =E2=80=9CMUST not contain=E2=80=9D Sections 4.1.2, 4.1.3: will result -> MUST result Section 4.2: Do the null meanings of offset and length have the same mean= ing as for create? Is it possible to request both data:asText and data:as= Base64? Some of the requirements seem not to be in normative style, e.g. = =E2=80=9Cthe size value is always=E2=80=9D might be stated as =E2=80=9Cth= e size value MUST be=E2=80=9D and =E2=80=9Cthe key isEncodingProblem is s= et to true=E2=80=9D -> =E2=80=9Cthe key isEncodingProblem MUST be set to = true=E2=80=9D Section 6.3: I=E2=80=99m confused about creating a registry where the exi= sting entries reference a number of different existing specifications. Is= this a registry that was overlooked in the past? (If so, glad you=E2=80=99= re adding it) Nit: Is blob capitalized? It=E2=80=99s inconsistent but mostly capitalized her= e, but RFC 8620 doesn=E2=80=99t capitalize it. Hope this helps, -Jim (without hat) From nobody Tue Dec 7 16:56:00 2021 Return-Path: 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 146963A06E7 for ; Tue, 7 Dec 2021 16:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net 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 s3Zz8L0zhrH2 for ; Tue, 7 Dec 2021 16:55:53 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 1F5AD3A0776 for ; Tue, 7 Dec 2021 16:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:To:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nBzVfjOY5nShbhryDr9+dpavoLvXc2MkLX85E0I8Pdg=; b=uJGFm2Kv88xTRICC1DEG45pvMc NP8bgBcegxJOzyEdhGJ/YE/K1c/jKNs0U8zdt8FAo+Lp2+VHnilHOPVn0esiPfaS/5mjDJZC9ef8s 8goWzgSWMdEaCm3gmmy3a8xBRkXPF7lRNQ3DYoEws1uakcHJWqBST7ch8OnQT8emuJA8=; Received: from [2601:647:4400:1261:d0db:bbe9:9ef9:3aae] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mulFJ-0001Ql-5G for jmap@ietf.org; Tue, 07 Dec 2021 16:55:45 -0800 From: Jim Fenton To: jmap@ietf.org Date: Tue, 07 Dec 2021 16:55:44 -0800 X-Mailer: MailMate (1.14r5820) Message-ID: <0CB9E94B-90EC-46B4-B0A9-464498C02BDD@bluepopcorn.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] WGLC: draft-ietf-jmap-blob-07 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 00:55:58 -0000 There has been one comment during the Last Call period (mine), and the WG= LC is now closed. -Jim On 22 Nov 2021, at 13:35, Jim Fenton wrote: > Per the discussion in our WG meeting on November 9: > > This starts a 2 week Working Group Last Call on draft-ietf-jmap-blob-07= =2E Please provide your feedback on this document by December 7, 2021. > > -Jim > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Mon Dec 20 05:43:23 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF453A0C43; Mon, 20 Dec 2021 05:43:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <164000780114.4767.16392149813732746967@ietfa.amsl.com> Date: Mon, 20 Dec 2021 05:43:21 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-blob-08.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2021 13:43:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP Blob management extension Author : Bron Gondwana Filename : draft-ietf-jmap-blob-08.txt Pages : 27 Date : 2021-12-20 Abstract: The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on defined endpoint. This binary data is called a "blob". This extension adds additional ways to create and access blobs, by making inline method calls within a standard JMAP request. This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-blob/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-blob-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-blob-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Dec 20 05:47:15 2021 Return-Path: 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 447CF3A0C69 for ; Mon, 20 Dec 2021 05:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=S0oU+mR6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TJZiuEDL 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 U8DjrAizmCUo for ; Mon, 20 Dec 2021 05:47:09 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2D43A0C4F for ; Mon, 20 Dec 2021 05:47:09 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 444DD3200E31; Mon, 20 Dec 2021 08:47:05 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Mon, 20 Dec 2021 08:47:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=BaLR 6jxWDRWXxyfb0ZclIlDxX9+P948ScN3T1LJAjTE=; b=S0oU+mR6d7fYMEUO3n33 hz20Hs6mdeo0KUy9VnYuhhdszdTK9E1dCjTt1J//rDI7SeN/pWS11t40qfK0+RCm VdMFs9potRZ0E/wpuN5PuzR/9MFiCL1uEross09QasMe3/jGNTZx5ZT4hQ2n8K/Q nGQP2mn+IvKyArinxZcdXZJKHZ9gSAZlDH4N2q5bL5ljMhG58LTcysW7WdxRwnbS +Qbn24yP0/RIBH0G+zQXJwdXsi3Sp4ASGoGHSY/iqiczu8W/JqnOEOrAA8+2WW/G CJJPlXhZ/KcDAAKakRkMAlzjuZOADERNDpiRg97xJwBBB1RkiBKt6zJHqMKLBQuk GA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=BaLR6j xWDRWXxyfb0ZclIlDxX9+P948ScN3T1LJAjTE=; b=TJZiuEDLAfBsfkV7aQ3tbq uua33edfye3lYLOgCw+dGyJHe8xZA3GWAY5gBgtV+JrU73RLWNKE8jA56HQ6EXRe 5O5kWXtB/SlXFldzPnAazhCtylxZbqkXMiJG0QJvqwPib1c93+tyWE8i9cnjmIe4 aaIRU6rua0fazQed9k5JQQEssgKBe9QYzu7GhUauI55P1RFibiV2Lziy7eteZ9kZ 2VhzXLYm9xn0AkLAkjb6HJdEnGgWazgiafI2kGWtGTpnj+7S3H1urLytflB4f04e eh8pi7ArG59HstmQZwTGx44ufA86UPN3SkGFXo55nMAbOeLZHQsQ+5/0G4LwbMCw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddtvddgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepffdvkeefgeelieeutedttdffheevvefffeekuddvtddt keeigfejuddvhfdvudelnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 20903AC0DD1; Mon, 20 Dec 2021 08:47:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4524-g5e5d2efdba-fm-20211214.001-g5e5d2efd Mime-Version: 1.0 Message-Id: <9af2f7e5-1dcb-4cef-8b59-7b6e7ca2cb76@dogfood.fastmail.com> In-Reply-To: References: Date: Tue, 21 Dec 2021 00:46:29 +1100 From: "Bron Gondwana" To: "Jim Fenton" , "Neil Jenkins" Cc: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=8ea8f6f2b51e4f9f8211f67d927c5549 Archived-At: Subject: Re: [Jmap] WGLC review of draft-jmap-blob-07 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2021 13:47:14 -0000 --8ea8f6f2b51e4f9f8211f67d927c5549 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Jim, and sorry for taking so long to get back to you! Neil - you're added to explicit CC because I have a question for you in = here about the 'ifInState' and 'state' fields in a Blob/{get,set} and wh= at we should do about it. On Tue, Dec 7, 2021, at 11:42, Jim Fenton wrote: > I had a look at draft-ietf-jmap-blob-07, and have a few comments. Plea= se bear in mind that I don=E2=80=99t have a great deal of experience wit= h the other jmap documents, so some of this might be due to that. >=20 > General: >=20 > I found the large number of examples in the document to be a little di= stracting. I would prefer to see them in a non-normative appendix. At a = minimum, it should be made clear that they=E2=80=99re informative exampl= es, so they aren=E2=80=99t depended upon in the event of a conflict betw= een the normative text and the example. This is tricky in general - I have found that not having enough examples= leads to poorer quality implementations. In the event of a conflict be= tween the normative text and an example, that's just as bad as a conflic= t between one part of the normative text and another part of the normati= ve text, and requires errata. I don't see much value in "making it clea= r that they're informative" because people will check against them anywa= y. Which probably means for the one which I wrote by hand, I should test it= against a real implementation! I'm as sure that it's right as I am tha= t the prose is right though! All the other examples exist as test cases in our Cassandane test framew= ork for Cyrus IMAP, because that was easier than trying to write them by= hand! > Specific sections: >=20 > Section 3: This appears to be a normative reference to [RFC8620], so t= hat document should be moved from informative to normative in the refere= nces. Oh for sure - that will be mmark. I used the "normative" version of the= RFC link coding: `[@!RFC8620]` everywhere except the registry table, so= it decided I didn't really mean normative. Woohoo. Fixed. Thanks, and my apologies for not proof-reading that myself. The other t= wo informative references should stay that way, as you can implement thi= s without them. >=20 > Section 3.1: =E2=80=9CThis=E2=80=9D is apparently a reference to the s= ection title. What is it about =E2=80=9Cthis=E2=80=9D that represents su= pport: I guess the advertisement of this string in the capabilities obje= ct? Please make that more specific so that the section fully specifies w= hat happens.=20 Updated with language cribbed from RFC9007 which is the most recent publ= ished JMAP extension that does something similar. > What happens if some of the parameters (e.g., MaxSizeBlobSet) aren=E2=80= =99t included: do they assume default values are are the limits nonexist= ent? If this appears in accountCapabilities, I presume it also has to ap= pear in capabilities; is that specified somewhere? No, it can only appear in accountCapabilities, as specified in the previ= ous paragraph. I have gone back and made it a MUST that servers support 64 items, and t= hat clients assume that if it's not present. Likewise I've said that a = lack of maxSizeBlobSet just means "assume that it's maxSizeUpload". >=20 > Section 4.1.1: Is this a subset of the Blob/set method, and if so how = is it distinguished? A standard set method, per RFC8620: https://datatracker.ietf.org/doc/html/rfc8620#section-5.3 It is distinguished by being the `create` argument to a standard `/set` = method. All `/set` methods take arguments. But you make a good point -= I should probably define that Blobs do not have a state as such, so it = is an error to provide ifInState argument. Neil - do we have a good generic way to handle objects for which there's= no valid `state`? > =E2=80=9Cexactly one of=E2=80=9D, =E2=80=9CAlso optionally=E2=80=9D is= n=E2=80=99t as formal a definition as I=E2=80=99m used to in IETF standa= rds-track documents. Often, something like this is specified using ABNF.= I don=E2=80=99t have a good idea if this is unambiguous or not. JMAP has not used ABNF in any of its specifications. How would you prop= ose saying a set containing precisely one of A, B or C in prose? > =E2=80=9Ccan not contain=E2=80=9D -> =E2=80=9CMUST not contain=E2=80=9D Yes, thanks - fixed. > Sections 4.1.2, 4.1.3: will result -> MUST result Hmm.... maybe. At least within the scope of this document that is true. It would be possible within this JMAP syntax for a future specification = (which must be selected with a new capability) to alter this behaviour (= for example: by adding an expiry time to unreferenced blobs and allowing= `update` to change the expiry time and `delete` to remove the blob imme= diately). So I don't want to sling too many MUSTs around for the behavi= our of things which are legitimate extension points. I would prefer to leave this as is. It's clear enough without encouragi= ng implementations to hard code assumptions by scattering MUST. > Section 4.2: Do the null meanings of offset and length have the same m= eaning as for create? Yes. I guess it was unclear if you queried it. Improved. >=20 > Is it possible to request both data:asText and data:asBase64?=20 Yes. This is quite expected to anybody familiar with JMAP, where you ca= n fetch multiple representations of the same data in the same request. = RFC8621 in particular allows fetching different representations of heade= rs using very similar syntax - but it's an error to set the same field t= wice, e.g: o If a "bodyStructure" property is given, there MUST NOT be "textBody", "htmlBody", or "attachments" properties. o If given, the "bodyStructure" EmailBodyPart MUST NOT contain a property representing a header field that is already defined on the top-level Email object. o Within an EmailBodyPart: * The client may specify a partId OR a blobId, but not both. If a partId is given, this partId MUST be present in the "bodyValues" property. But you can certainly fetch either or both with an Email/get. > Some of the requirements seem not to be in normative style, e.g. =E2=80= =9Cthe size value is always=E2=80=9D might be stated as =E2=80=9Cthe siz= e value MUST be=E2=80=9D and =E2=80=9Cthe key isEncodingProblem is set t= o true=E2=80=9D -> =E2=80=9Cthe key isEncodingProblem MUST be set to tru= e=E2=80=9D Hmm. Yes. Am fixing these ones and reviewing for similar. > Section 6.3: I=E2=80=99m confused about creating a registry where the = existing entries reference a number of different existing specifications= . Is this a registry that was overlooked in the past? (If so, glad you=E2= =80=99re adding it) Yes. There was much discussion on that very topic. It was overlooked t= o a large extent because there was no real need for it until this docume= nt added backreferences. You could also follow the JMAP capabilities re= gistry to find the documents for each one, and then read the description= s for the types that they provide... though that wasn't really clear abo= ut whether you could ask for push notifications about them. And definitely the existing documents did not specify whether their type= s were amenable to being used for backreferences - because that wasn't a= thing yet! - so this document defines that for the existing types in ex= isting documents. Future documents will need to specify each of their t= ypes and whether they can be used for backreferences or push notificatio= ns in this registry as well. > Nit: >=20 > Is blob capitalized? It=E2=80=99s inconsistent but mostly capitalized = here, but RFC 8620 doesn=E2=80=99t capitalize it. Mu. Blob-the-object is capitalised, in the same way that RFC8621 capita= lises 'Email' when referencing an object. It shouldn't be otherwise. I= 've gone through and lowered all the cases where it's not directly refer= encing the JMAP wire object. I could see an argument for going the oth= er way too, but I'm happy with lower. I've uploaded a -08 just to show my workings. Let me know if that resol= ves everything to your satisfaction other than maybe the open question t= hat I've asked Neil for advice/suggestions on. Thanks, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --8ea8f6f2b51e4f9f8211f67d927c5549 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Jim, and sorry for taking so long to get back to yo= u!

Neil - you're added to explicit CC because I have a qu= estion for you in here about the 'ifInState' and 'state' fields in a Blo= b/{get,set} and what we should do about it.

On Tue, Dec 7, 2021, at 11:42, Jim Fenton = wrote:
I had a look at draft-ietf-jmap-blob-07, and ha= ve a few comments. Please bear in mind that I don=E2=80=99t have a great= deal of experience with the other jmap documents, so some of this might= be due to that.

General:

I found the larg= e number of examples in the document to be a little distracting. I would= prefer to see them in a non-normative appendix. At a minimum, it should= be made clear that they=E2=80=99re informative examples, so they aren=E2= =80=99t depended upon in the event of a conflict between the normative t= ext and the example.

This is tricky in gener= al - I have found that not having enough examples leads to poorer qualit= y implementations.  In the event of a conflict between the normativ= e text and an example, that's just as bad as a conflict between one part= of the normative text and another part of the normative text, and requi= res errata.  I don't see much value in "making it clear that they'r= e informative" because people will check against them anyway.
<= div style=3D"font-family:Arial;">
Which probably means for the one which I wrote by hand, I should te= st it against a real implementation!  I'm as sure that it's right a= s I am that the prose is right though!

All the other exam= ples exist as test cases in our Cassandane test framework for Cyrus IMAP= , because that was easier than trying to write them by hand!

Specific sections:
=

Section 3: This appears to be a normative reference to [RFC8= 620], so that document should be moved from informative to normative in = the references.
=

Oh for sure - that will be mmark.  I used the "= normative" version of the RFC link coding: [@!RFC8620]= everywhere except the registry table, so it decided I didn't rea= lly mean normative.  Woohoo.  Fixed.

Thanks, and my apologies for not proof-= reading that myself.  The other two informative references should s= tay that way, as you can implement this without them.

=

Section= 3.1: =E2=80=9CThis=E2=80=9D is apparently a reference to the section ti= tle. What is it about =E2=80=9Cthis=E2=80=9D that represents support: I = guess the advertisement of this string in the capabilities object? Pleas= e make that more specific so that the section fully specifies what happe= ns.

<= div style=3D"font-family:Arial;">Updated with language cribbed from RFC9= 007 which is the most recent published JMAP extension that does somethin= g similar.

What happens if some of the parameters (e.g., MaxSizeBlobSet) aren=E2=80= =99t included: do they assume default values are are the limits nonexist= ent? If this appears in accountCapabilities, I presume it also has to ap= pear in capabilities; is that specified somewhere?

No, it can only appear in accountCapabilities, as specified in th= e previous paragraph.

I have gone back and made it a MUST= that servers support 64 items, and that clients assume that if it's not= present.  Likewise I've said that a lack of maxSizeBlobSet just me= ans "assume that it's maxSizeUpload".


= Section 4.1.1: Is this a subset of the Blob/set method, and if so how is= it distinguished?

A standard set method, pe= r RFC8620:


It is distinguished by being the create argument to a standard /set m= ethod.  All /set methods take arguments.&n= bsp; But you make a good point - I should probably define that Blobs do = not have a state as such, so it is an error to provide ifInState argumen= t.

Neil - do we have a good generic way to handle objects= for which there's no valid state?

=E2=80=9Cexactly one = of=E2=80=9D, =E2=80=9CAlso optionally=E2=80=9D isn=E2=80=99t as formal a= definition as I=E2=80=99m used to in IETF standards-track documents. Of= ten, something like this is specified using ABNF. I don=E2=80=99t have a= good idea if this is unambiguous or not.

JM= AP has not used ABNF in any of its specifications.  How would you p= ropose saying a set containing precisely one of A, B or C in prose?
<= /div>

=E2=80=9Ccan n= ot contain=E2=80=9D -> =E2=80=9CMUST not contain=E2=80=9D

Yes, thanks - fixed.

Sections 4.1.2, 4.1.3: will result -> MUS= T result

Hmm.... maybe.  At least withi= n the scope of this document that is true.

It would be po= ssible within this JMAP syntax for a future specification (which must be= selected with a new capability) to alter this behaviour (for example: b= y adding an expiry time to unreferenced blobs and allowing update to change the expiry time and delete= to remove the blob immediately).  So I don't want to sling = too many MUSTs around for the behaviour of things which are legitimate e= xtension points.

I would prefer to leave this as is. = ; It's clear enough without encouraging implementations to hard code ass= umptions by scattering MUST.
=
Section 4.2: Do the null meanings of offset and lengt= h have the same meaning as for create?

Yes.&nb= sp; I guess it was unclear if you queried it.  Improved.
<= div style=3D"font-family:Arial;">

Is it possible to request both data:asText and data= :asBase64?

=
Yes.  This is quite expecte= d to anybody familiar with JMAP, where you can fetch multiple representa= tions of the same data in the same request.  RFC8621 in particular = allows fetching different representations of headers using very similar = syntax - but it's an error to set the same field twice, e.g:

   o  I=
f a "bodyStructure" property is given, there MUST NOT be
      "textBody", "htmlBody", or "attachments" properties.

   o  If =
given, the "bodyStructure" EmailBodyPart MUST NOT contain a
      property representing a header field that is already defined on
      the top-level Email object.

   o  Within an EmailBodyPart:

      *  The client may specify a partId OR a blobId, but not both.  If
         a partId is given, this partId MUST be present in the
         "bodyValues" property.

But you can certainly fet= ch either or both with an Email/get.

Some of the requirements seem not to be in no= rmative style, e.g. =E2=80=9Cthe size value is always=E2=80=9D might be = stated as =E2=80=9Cthe size value MUST be=E2=80=9D and =E2=80=9Cthe key = isEncodingProblem is set to true=E2=80=9D -> =E2=80=9Cthe key isEncod= ingProblem MUST be set to true=E2=80=9D

Hmm.=   Yes.  Am fixing these ones and reviewing for similar.

Section 6.3: I=E2= =80=99m confused about creating a registry where the existing entries re= ference a number of different existing specifications. Is this a registr= y that was overlooked in the past? (If so, glad you=E2=80=99re adding it= )

Yes.  There was much discussion on th= at very topic.  It was overlooked to a large extent because there w= as no real need for it until this document added backreferences.  Y= ou could also follow the JMAP capabilities registry to find the document= s for each one, and then read the descriptions for the types that they p= rovide... though that wasn't really clear about whether you could ask fo= r push notifications about them.

And definitely the exist= ing documents did not specify whether their types were amenable to being= used for backreferences - because that wasn't a thing yet! - so this do= cument defines that for the existing types in existing documents.  = Future documents will need to specify each of their types and whether th= ey can be used for backreferences or push notifications in this registry= as well.

= Nit:

Is blob capitalized? It=E2=80=99s inconsistent but m= ostly capitalized here, but RFC 8620 doesn=E2=80=99t capitalize it.
<= /div>

Mu.  Blob-the-object is capitalised, in the= same way that RFC8621 capitalises 'Email' when referencing an object.&n= bsp; It shouldn't be otherwise.  I've gone through and lowered all = the cases where it's not directly referencing the JMAP wire object. = ;  I could see an argument for going the other way too, but I'm hap= py with lower.

I've uploaded a -08 just to show my workin= gs.  Let me know if that resolves everything to your satisfaction o= ther than maybe the open question that I've asked Neil for advice/sugges= tions on.

Thanks,

Bron.

--
  Bron Gondwana, C= EO, Fastmail Pty Ltd
  brong@fast= mailteam.com


--8ea8f6f2b51e4f9f8211f67d927c5549-- From nobody Tue Dec 21 13:57:26 2021 Return-Path: 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 E058B3A13C2 for ; Tue, 21 Dec 2021 13:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net 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 k8gOYBT-uB67 for ; Tue, 21 Dec 2021 13:57:20 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 E8F0F3A13C1 for ; Tue, 21 Dec 2021 13:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XX0Du+S3G+n9PwGb4A/LT/5rWAgT8aDT/IAvGdgTx3U=; b=lHi9qou/zfUh2kvCirGbgwfcVK bCG9QMH99voDxhNI7gE6NfVFzwcVFsal9My8AtekuKykxpIthmtqE+LpEBA5DOfEZRpOhMIMzhHQC W4/TrWAh60fzPPDK6IOy1FSyaPQ6HKlt+c728bRjDva4uNdXdP+5n1IuGgLYf8YXexoM=; Received: from [2601:647:4400:1261:a807:6869:70fd:1eed] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mzn8G-0002yp-Vg; Tue, 21 Dec 2021 13:57:17 -0800 From: Jim Fenton To: Bron Gondwana Cc: Neil Jenkins , IETF JMAP Mailing List Date: Tue, 21 Dec 2021 13:57:15 -0800 X-Mailer: MailMate (1.14r5852) Message-ID: <757B1E1A-8797-476B-B072-996AF9C9185A@bluepopcorn.net> In-Reply-To: <9af2f7e5-1dcb-4cef-8b59-7b6e7ca2cb76@dogfood.fastmail.com> References: <9af2f7e5-1dcb-4cef-8b59-7b6e7ca2cb76@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] WGLC review of draft-jmap-blob-07 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2021 21:57:25 -0000 Inline=E2=80=A6I wasn=E2=80=99t sure where to cut so this might be a bit = of a verbose reply. On 20 Dec 2021, at 5:46, Bron Gondwana wrote: > Thanks Jim, and sorry for taking so long to get back to you! > > Neil - you're added to explicit CC because I have a question for you in= here about the 'ifInState' and 'state' fields in a Blob/{get,set} and wh= at we should do about it. > > On Tue, Dec 7, 2021, at 11:42, Jim Fenton wrote: >> I had a look at draft-ietf-jmap-blob-07, and have a few comments. Plea= se bear in mind that I don=E2=80=99t have a great deal of experience with= the other jmap documents, so some of this might be due to that. >> >> General: >> >> I found the large number of examples in the document to be a little di= stracting. I would prefer to see them in a non-normative appendix. At a m= inimum, it should be made clear that they=E2=80=99re informative examples= , so they aren=E2=80=99t depended upon in the event of a conflict between= the normative text and the example. > > This is tricky in general - I have found that not having enough example= s leads to poorer quality implementations. In the event of a conflict be= tween the normative text and an example, that's just as bad as a conflict= between one part of the normative text and another part of the normative= text, and requires errata. I don't see much value in "making it clear t= hat they're informative" because people will check against them anyway. > > Which probably means for the one which I wrote by hand, I should test i= t against a real implementation! I'm as sure that it's right as I am tha= t the prose is right though! > > All the other examples exist as test cases in our Cassandane test frame= work for Cyrus IMAP, because that was easier than trying to write them by= hand! I completely agree on the importance of examples. This is mostly a style = thing, but I find the spec easier to navigate with the examples concentra= ted in one or more appendices. But this is fine if you and others prefer = in-line examples. >> Specific sections: >> >> Section 3: This appears to be a normative reference to [RFC8620], so t= hat document should be moved from informative to normative in the referen= ces. > > Oh for sure - that will be mmark. I used the "normative" version of th= e RFC link coding: `[@!RFC8620]` everywhere except the registry table, so= it decided I didn't really mean normative. Woohoo. Fixed. > > Thanks, and my apologies for not proof-reading that myself. The other = two informative references should stay that way, as you can implement thi= s without them. Sounds good. >> >> Section 3.1: =E2=80=9CThis=E2=80=9D is apparently a reference to the s= ection title. What is it about =E2=80=9Cthis=E2=80=9D that represents sup= port: I guess the advertisement of this string in the capabilities object= ? Please make that more specific so that the section fully specifies what= happens. > > Updated with language cribbed from RFC9007 which is the most recent pub= lished JMAP extension that does something similar. > >> What happens if some of the parameters (e.g., MaxSizeBlobSet) aren=E2=80= =99t included: do they assume default values are are the limits nonexiste= nt? If this appears in accountCapabilities, I presume it also has to appe= ar in capabilities; is that specified somewhere? > > No, it can only appear in accountCapabilities, as specified in the prev= ious paragraph. > > I have gone back and made it a MUST that servers support 64 items, and = that clients assume that if it's not present. Likewise I've said that a = lack of maxSizeBlobSet just means "assume that it's maxSizeUpload". Good; thanks. >> >> Section 4.1.1: Is this a subset of the Blob/set method, and if so how = is it distinguished? > > A standard set method, per RFC8620: > > https://datatracker.ietf.org/doc/html/rfc8620#section-5.3 > > It is distinguished by being the `create` argument to a standard `/set`= method. All `/set` methods take arguments. But you make a good point -= I should probably define that Blobs do not have a state as such, so it i= s an error to provide ifInState argument. > > Neil - do we have a good generic way to handle objects for which there'= s no valid `state`? Thanks for the explanation; will wait for Neil=E2=80=99s response as well= =2E >> =E2=80=9Cexactly one of=E2=80=9D, =E2=80=9CAlso optionally=E2=80=9D is= n=E2=80=99t as formal a definition as I=E2=80=99m used to in IETF standar= ds-track documents. Often, something like this is specified using ABNF. I= don=E2=80=99t have a good idea if this is unambiguous or not. > > JMAP has not used ABNF in any of its specifications. How would you pro= pose saying a set containing precisely one of A, B or C in prose? The place I=E2=80=99m having the most trouble is the syntax of the Catena= teSourceObject in section 4.1.1. Is the blobId source a third alternative= to data:asText or data:asBase64? Or is it in addition? It might be clear= er if there was a defined [blobIdSource] think and you listed that as a t= hird alternative. Otherwise it=E2=80=99s confusing because the =E2=80=9Co= r a blobId source=E2=80=9D is at the same level as the =E2=80=9Cexactly o= ne of=E2=80=9D. >> =E2=80=9Ccan not contain=E2=80=9D -> =E2=80=9CMUST not contain=E2=80=9D= > > Yes, thanks - fixed. > >> Sections 4.1.2, 4.1.3: will result -> MUST result > > Hmm.... maybe. At least within the scope of this document that is true= =2E > > It would be possible within this JMAP syntax for a future specification= (which must be selected with a new capability) to alter this behaviour (= for example: by adding an expiry time to unreferenced blobs and allowing = `update` to change the expiry time and `delete` to remove the blob immedi= ately). So I don't want to sling too many MUSTs around for the behaviour= of things which are legitimate extension points. > > I would prefer to leave this as is. It's clear enough without encourag= ing implementations to hard code assumptions by scattering MUST. I still see this as specifying unambiguously what the behavior of the ser= ver should be. If there=E2=80=99s an extension later it would be =E2=80=9C= updates RFC xxxx=E2=80=9D and can change that behavior. >> Section 4.2: Do the null meanings of offset and length have the same m= eaning as for create? > > Yes. I guess it was unclear if you queried it. Improved. Thanks. >> Is it possible to request both data:asText and data:asBase64? > > Yes. This is quite expected to anybody familiar with JMAP, where you c= an fetch multiple representations of the same data in the same request. = RFC8621 in particular allows fetching different representations of header= s using very similar syntax - but it's an error to set the same field twi= ce, e.g: > > o If a "bodyStructure" property is given, there MUST NOT be > "textBody", "htmlBody", or "attachments" properties. > > o If given, the "bodyStructure" EmailBodyPart MUST NOT contain a > property representing a header field that is already defined on > the top-level Email object. > > o Within an EmailBodyPart: > > * The client may specify a partId OR a blobId, but not both. If= > a partId is given, this partId MUST be present in the > "bodyValues" property. > > But you can certainly fetch either or both with an Email/get. Thanks for educating me on this. >> Some of the requirements seem not to be in normative style, e.g. =E2=80= =9Cthe size value is always=E2=80=9D might be stated as =E2=80=9Cthe size= value MUST be=E2=80=9D and =E2=80=9Cthe key isEncodingProblem is set to = true=E2=80=9D -> =E2=80=9Cthe key isEncodingProblem MUST be set to true=E2= =80=9D > > Hmm. Yes. Am fixing these ones and reviewing for similar. Thanks. >> Section 6.3: I=E2=80=99m confused about creating a registry where the = existing entries reference a number of different existing specifications.= Is this a registry that was overlooked in the past? (If so, glad you=E2=80= =99re adding it) > > Yes. There was much discussion on that very topic. It was overlooked = to a large extent because there was no real need for it until this docume= nt added backreferences. You could also follow the JMAP capabilities reg= istry to find the documents for each one, and then read the descriptions = for the types that they provide... though that wasn't really clear about = whether you could ask for push notifications about them. > > And definitely the existing documents did not specify whether their typ= es were amenable to being used for backreferences - because that wasn't a= thing yet! - so this document defines that for the existing types in exi= sting documents. Future documents will need to specify each of their typ= es and whether they can be used for backreferences or push notifications = in this registry as well. Makes sense. >> Nit: >> >> Is blob capitalized? It=E2=80=99s inconsistent but mostly capitalized = here, but RFC 8620 doesn=E2=80=99t capitalize it. > > Mu. Blob-the-object is capitalised, in the same way that RFC8621 capit= alises 'Email' when referencing an object. It shouldn't be otherwise. I= 've gone through and lowered all the cases where it's not directly refere= ncing the JMAP wire object. I could see an argument for going the other= way too, but I'm happy with lower. You might want to check 4.1.2 and 4.1.3 again on that. > I've uploaded a -08 just to show my workings. Let me know if that reso= lves everything to your satisfaction other than maybe the open question t= hat I've asked Neil for advice/suggestions on. See above. Probably wait for Neil before turning the crank on another rev= ision. -Jim From nobody Thu Dec 23 05:38:22 2021 Return-Path: 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 19DC23A0964; Thu, 23 Dec 2021 05:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=upPch1Kg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WfUzKl9B 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 PqxbVUNyXxNq; Thu, 23 Dec 2021 05:38:10 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E073A095D; Thu, 23 Dec 2021 05:38:09 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A7BDA5C0159; Thu, 23 Dec 2021 08:38:08 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Thu, 23 Dec 2021 08:38:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm1; bh=SRhmK1ZTALxlImmO0jO1yY55/6Aw7MA zsdPwYVyZ1xs=; b=upPch1KgoZCOC2fgihfnYOQqJsU7b7Pj/9emsUaUW8wmB1o 0yaBgtaz2l46SapVOpPKzzAHydGHvSWLNQ7JBuYZmn43tMS2QeBAuQ3LZmkKWbKW l471b4n8m5SoirBqYIINz7ovOlstdqDHEPRQhWKQ6WT8Ayr4cWbcbEUjq0hpR/rI NjB5wTT/7Qk4uJH45aioVuazmIC2qGLEW4LzqsnFY9ES5ZzMAS0O/PIej3xvjslA p8vg9saRKdkh+lDc7zeUhvcq0sbzvCDyMi6yF/DWrFsbwtqwVHAT2Bvv+bidAKrN rKNJllphSj6LDe5eDdRGsicUKSFCjamkp6lySFA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=SRhmK1ZTALxlImmO0jO1yY55/6Aw7 MAzsdPwYVyZ1xs=; b=WfUzKl9Bnk8HB1fUnMP7TIuVIiqIFaJSPaxzH61Tg8CfT 59EWzhuyYJJQvbO/u3C8QycoD9UqDqmWf3cmLiWO5fyABRZixo34MCQZ/yuu6CXI FPXVlD/zuRtnVog+wRbtIxfAiuprdKIQ1pPGo2gJH+5/o4DPmjIx+YsqRITfZeUq NsSEevDnZ8B1qw3t0wBtw8rOuJyCoMih+ZWNN4Il1bVtB654iKatoF13AudnBZyj OFE4S+ybtmN2K/xuT97KF868ZHoUg6ltlF0KSUcupoNIsTVH1QbK/F3BuS+aZJLi fywOGQHKlC5Y/4eVswirW4zUWG/V1wOboxduUpYSw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddtkedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepffevgefhiefgvd dttdetvdetjefggeffveettdegleetueeghfevleehleeggfelnecuffhomhgrihhnpehi vghtfhdrohhrghdpfihikhhiphgvughirgdrohhrghdpthhhvghlrghntggvthdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshht ohesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7056CAC03DB; Thu, 23 Dec 2021 08:38:08 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4525-g8883000b21-fm-20211221.001-g8883000b Mime-Version: 1.0 Message-Id: Date: Thu, 23 Dec 2021 14:37:46 +0100 From: "Robert Stepanek" To: jmap@ietf.org Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=57940cacf5d34d45897250108bf030d8 Archived-At: Subject: [Jmap] JSContact: gender property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2021 13:38:15 -0000 --57940cacf5d34d45897250108bf030d8 Content-Type: text/plain 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 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 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 . * 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. --57940cacf5d34d45897250108bf030d8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
One open q= uestion for JSContact was if and how to store gender-specific informatio= n for a contact. In the next RFC version, we intend to address this by i= ntroduction of the "grammaticalGender" property. We look forward to your= feedback.
  • The "grammaticalGender" property defines whi= ch grammatical gender to use to address or refer to the contact that is = represented by the JSContact object.
  • For example, several hu= man languages require a grammatical gender for salutations. In German th= e salutations "Sehr geehrte" and "Sehr geehrter" are used for single-per= son female and male  addreeses, respectively. The "grammaticalGende= r" property defines which gender to use in this case. Its value can be o= verridden per language in the "localizations" property.
  • The = allowed values are (in alphabetical order): "animate", "female", "inanim= ate", "male", "neuter". Other grammatical genders need to be registered.=

A related property in VCARD is the GEN= DER property, which aims to store both the biological sex and the ge= nder 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 se= x 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 example= s for GENDER strengthen this assumption.

This leaves the question if we need to introduce an additional propert= y to map GENDER to JSContact. We do not think so:
  • It se= ems that the majority of applications used the biological sex component = of GENDER to store the grammatical gender of a contact. This now is prov= ided by the "grammaticalGender" property and mapping from VCARD to JSCon= tact should be straight-forward.
  • For applications that actua= lly require to store biological sex, the current definition of the GENDE= R sex component seems inadequate. While it allows for a superset of ISO/IEC 5218, it&= nbsp; does not support for "intersex" (Note how the examples for GENDER = suggest to store "intersex" as gender identity, which does not allow int= ersex persons to define a preferred gender identity). In addition, even = biological sex seems to be ambiguous.
  • We do not know if a free-text gender identity is useful for applic= ations. Gender studies suggest that gender identities may differ by cont= ext 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 pr= ovide a standard that fits all requirements.

Cheers,
Robert

P.S.: Cr= oss-posting this both to JMAP and CALEXT as both working groups have exp= ertise on address book and contact applications.
--57940cacf5d34d45897250108bf030d8-- From nobody Thu Dec 23 05:48:27 2021 Return-Path: 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 EAA763A09A1; Thu, 23 Dec 2021 05:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=DvkyuwH/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OYJpow9Z 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 cwjLl2t6BP8f; Thu, 23 Dec 2021 05:48:20 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B59B3A099E; Thu, 23 Dec 2021 05:48:20 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 66F525C01BA; Thu, 23 Dec 2021 08:48:19 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 23 Dec 2021 08:48:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:message-id:date:mime-version:subject:to:cc :references:from:in-reply-to; s=fm1; bh=ik14oPkUYGuCxJhG9SLMNUMt +exjmc5FE1dg4OOe7yo=; b=DvkyuwH//uA833LxxgT3nSUXcWGRZvh/woGRP1iA FvOtNMhkEdk61RrDOkYr2PGbflbD8rVukrKFtK8KfWqMw1XaoTlWralagpqD/Eu0 ihIV7J2s6YI0CSI41XxAGCYR39u8J0xQVPwpZaV8KyvtVMISZIBlKudWeAuxIAsa izzwInhoSrINjz05aVS7SQeBkLjLyWjlWTqG99RcbLGczBSkhLWllNp2pfCgw+xL 66AS/pDHUgMVh+myeqxXE/Za92/7k1gvu3PvDYINg0hhDVmKArCt0MQhCezOHQue Z/d60R3nEPRarH7hv1CtMZtnQFf+otgvl1bgshaU5V+oqg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ik14oP kUYGuCxJhG9SLMNUMt+exjmc5FE1dg4OOe7yo=; b=OYJpow9Z13ySo/VnanrgKP gkgFvlWIF6ZOYcn8mM10Q8/3mCKwO4zxWNJoipXDQOqbMmuaySkr/dXfgYfwVgga KugBjx1/LL0EgklfckLxruo0juNQuocfb0Uf8qmtTs0WdrKJzPV6PRvcM3VY9rJk N/JUjI4QbrIJDUIRuoQpjawJ7zU2pMce/dM5Abaa6VVy9XGPisdvBst9ArtUc+Hk uF9WVNzaNUGZ3gHkcp3b+M2CNpvwWNQDtVtpQRL+VIBDndT+bZgTix6/dZ39GoHl 7rCdR8hSvv7PT+Gg8gAj5UOiJY3Lbfeia28ovOwI8GODIOs16TRRAzSwBReskx5w == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddtkedgheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtkfffgggfuffvfhfhjgesrgdtre ertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepfeejhfffgedvvdeiveekgeekte eludduteehgeetveetteegudeguddtgeeguddunecuffhomhgrihhnpehivghtfhdrohhr ghdpfihikhhiphgvughirgdrohhrghdpthhhvghlrghntggvthdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghs thhmrghilhdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 23 Dec 2021 08:48:18 -0500 (EST) Content-Type: multipart/alternative; boundary="------------yIkxR0drMdr0tx6iGTlai0tB" Message-ID: Date: Thu, 23 Dec 2021 08:48:18 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Robert Stepanek , jmap@ietf.org Cc: calsify@ietf.org References: From: Ken Murchison In-Reply-To: Archived-At: Subject: Re: [Jmap] [calsify] JSContact: gender property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2021 13:48:26 -0000 This is a multi-part message in MIME format. --------------yIkxR0drMdr0tx6iGTlai0tB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 > > 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 > 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 > . > * 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 > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------yIkxR0drMdr0tx6iGTlai0tB Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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 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 5218, 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.
  • 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
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------yIkxR0drMdr0tx6iGTlai0tB-- From nobody Thu Dec 23 06:51:34 2021 Return-Path: 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 In-Reply-To: Date: Thu, 23 Dec 2021 15:51:18 +0100 Cc: jmap@ietf.org, calsify@ietf.org Message-Id: References: To: Robert Stepanek X-Mailer: Apple Mail (2.3693.40.0.1.81) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2021 14:51:31 -0000 --Apple-Mail=_546A36D0-EB26-436A-B219-18EFEE5D4750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Robert, Not only is there grammaticalGender but also salutations often differ = based on relationship, like "Dear Robert" / "Dear Sir=E2=80=9C or = =E2=80=9ELieber Robert=E2=80=9C / =E2=80=9ESehr geehrter Herr = Stepanek=E2=80=9C. 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): =E2=80=9EDear %FN=E2=80=9C, =E2=80=9EDear Professor = %LN=E2=80=9C 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 = : >=20 > 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. >=20 > A related property in VCARD is the GENDER = 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. >=20 > 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=C2=A0ISO/IEC 521 = 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 = . > 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. >=20 > Cheers, > Robert >=20 > 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 > https://www.ietf.org/mailman/listinfo/jmap = --Apple-Mail=_546A36D0-EB26-436A-B219-18EFEE5D4750 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = Robert,

Not only is = there grammaticalGender but also salutations often differ based on = relationship, like "Dear Robert" / "Dear Sir=E2=80=9C or =E2=80=9ELieber = Robert=E2=80=9C / =E2=80=9ESehr geehrter Herr Stepanek=E2=80=9C.

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): = =E2=80=9EDear %FN=E2=80=9C, =E2=80=9EDear Professor %LN=E2=80=9C = 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 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 5218, 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.
  • 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
https://www.ietf.org/mailman/listinfo/jmap

= --Apple-Mail=_546A36D0-EB26-436A-B219-18EFEE5D4750-- From nobody Thu Dec 23 11:56:31 2021 Return-Path: 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 5FEE53A09D0; Thu, 23 Dec 2021 11:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.127 X-Spam-Level: X-Spam-Status: No, score=-0.127 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=fastmailteam.com header.b=PFjJ7gGb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jINzAHsw 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 ihFi9BIpeWFi; Thu, 23 Dec 2021 11:56:03 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE163A09A6; Thu, 23 Dec 2021 11:56:02 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 184DC3201C32; Thu, 23 Dec 2021 14:56:01 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Thu, 23 Dec 2021 14:56:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=64Hy6Bh wnxuGualDbtTJ4doXuRlI8LiTrjUUJiC8F3I=; b=PFjJ7gGbUk9Un37y0qLSfPT +F6fY8GjJCRvgKG3fLVfa62gSpL7y+VAZ42fbrSPGs0x0J9f6iyK+PD0eZ+lX/cY XGExIfYUEaG6XEpsBO4sUZrYdu3bfbKYIuzISSZnF0IjI0Nt7Uc/iKmVlWKsT2jm HlMLwBe5mx6R4WyHvZFotT44LCm272sxE8E4HegggrjgI30LmRT8ELy4aelzrVQ5 Gr9yBWmHBT1ITEfDtF6K3yNjMkIgyHEENM/M/etT0T5Pns/XERr4Wv6U7vnSvwZn XtYwhgvtYgzyeSFOtPEoHu6MotPqIMjw/DHxqqpEOoviZc9uu62D6q8qz5mKlNA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=64Hy6B hwnxuGualDbtTJ4doXuRlI8LiTrjUUJiC8F3I=; b=jINzAHswPZssi/SaQxxwEl aNTUnmcLhy3Dufn5KrlE8ChdDdahElJHhwU3VJQLGiNGHvdE7qTYeuKsSV0TE8R2 7sIvu11BtL4f0Jw5yBRAZu/xF/1oF2jOA1eydJF/9SvGfYxjM2g+ZvhCYPJU6I0X BYmVvARgoFT/XcqFIWi8Z7Y4tSuHDJjhMYaCcuNNfR2ouJJKKrjGH+jmKO8PiOQE SKUdo6z8zBrtDWorE1N34v8H5Jy9cBRC00HcYa6M+Z5/ISngIL00w6b2pBgGclCW EVQ4bpeEG7T+317UrCbH5O6HgwIauc62HBt1JkkWTd8psoyrGUc8NDWryDPsZeig == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddtkedgudefudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgv ihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepheeuhfdujedtieevkedvhfffgfelfeelhfefkeehhfek leekhfefueefveffjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6BCA0AC03DB; Thu, 23 Dec 2021 14:56:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4525-g8883000b21-fm-20211221.001-g8883000b Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 24 Dec 2021 06:55:59 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" , calsify@ietf.org Content-Type: multipart/alternative; boundary=477d0bba401a4514ab839281c681d336 Archived-At: Subject: Re: [Jmap] [calsify] JSContact: gender property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2021 19:56:11 -0000 --477d0bba401a4514ab839281c681d336 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 preferre= d pronouns. Is that not covered by grammaticalGender? On Fri, 24 Dec 2021, at 1:51 AM, Andreas Hauser wrote: > Not only is there grammaticalGender but also salutations often differ = based on relationship, like "Dear Robert" / "Dear Sir=E2=80=9C or =E2=80= =9ELieber Robert=E2=80=9C / =E2=80=9ESehr geehrter Herr Stepanek=E2=80=9C. That feels out-of-scope to me, especially if you have to start introduci= ng variable substitution. =E2=80=94Neil --477d0bba401a4514ab839281c681d336 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Rob= ert, I think this is a good, well-reasoned proposal.

<= /div>
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 t= hat not covered by grammaticalGender?

On Fr= i, 24 Dec 2021, at 1:51 AM, Andreas Hauser wrote:
Not only is there grammaticalGender but also salutations often dif= fer based on relationship, like "Dear Robert" / "Dear Sir=E2=80=9C or =E2= =80=9ELieber Robert=E2=80=9C / =E2=80=9ESehr geehrter Herr Stepanek=E2=80= =9C.

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

=E2=80=94Neil
--477d0bba401a4514ab839281c681d336-- From darcy@iris.ac.nz Thu Dec 23 12:08:56 2021 Return-Path: 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 C86823A09D3 for ; Thu, 23 Dec 2021 12:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iris.ac.nz header.b=HpEBmjdq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DWjLY8XZ 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 wYEDWg5dAQA2 for ; Thu, 23 Dec 2021 12:08:51 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F193A09CE for ; Thu, 23 Dec 2021 12:08:51 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 81E995C0055 for ; Thu, 23 Dec 2021 15:08:50 -0500 (EST) Received: from imap46 ([10.202.2.96]) by compute6.internal (MEProxy); Thu, 23 Dec 2021 15:08:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iris.ac.nz; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=RWC9SMz8GQ9rWLzXil1pLvJsweOg+qw LgQjwjufiIzg=; b=HpEBmjdq5qk610RKo79Y159ZjNcExoF+oNLNHcLHy8O/4JY 9GMKnJTyFe/llTDyHUO+hqPuZEPy5zlmyJ05Rc/hb3HQdPv94quY1AHO4Qql47y8 NILsUMBcMWVpqrU683y4b9b+bKKFpIAsaRkktiIOg7AhlGQ99PP+lTeCeZdjIB3I 24EDQ0JDTRugDLwbvo/6lHVvmPK5u+tgJChmnbP/YmkBqkyRTek0iG2SbMFwP1nO 2xTLyDTI9HIYrD6DfaFvKfppiDZ13S0HOCi+QiqUV+NGoyGZCZi3Z2YxFRCY0bip vuSUwnZ6OJwxr60eUwCcuRzI5ma23lhZSUfRwKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RWC9SM z8GQ9rWLzXil1pLvJsweOg+qwLgQjwjufiIzg=; b=DWjLY8XZlrGu/H62/mltwq aNE/VhP9GwTaOWy19kKlpIvSfHlKMYemSlEmzEhFCPzsZNHI1+XYYdT1PUUmTstd KiSpz6mLp9bkn5ztNFlX2QkTqMcVci/LHuqsm39YROWKj73zHNDrEEYXZzp++m4F vyz7Jd3w22sjrAbfmcMCVv4+tKKV/ijmP40m/XMdp/NxaYsPyDmE+gMV4L6Q0DKm n4MFlv5HQj5axP+MHSOo0EWNKgbUWZZ3lSSvs0IaW0g/4gPOOtgv0jou1tokaNEs CSAr4H05cCyPJjZ47FlaTK5LznQvNIicCImr4vfk4BtF8Yq1gXe+zJjUMsNT4HCw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddtkedgudefgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreerjeenucfhrhhomhepfdffrghrtgihucfkrhhishdfuceouggrrhgthiesihhr ihhsrdgrtgdrnhiiqeenucggtffrrghtthgvrhhnpeehgfdvkefhvdfhjeffteejkeejff etteduheeludevfffhteevhedvhfelheetjeenucffohhmrghinhepphhrohhnohhunhdr ihhsnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug grrhgthiesihhrihhsrdgrtgdrnhii X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3F4361EE007B; Thu, 23 Dec 2021 15:08:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4525-g8883000b21-fm-20211221.001-g8883000b Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 24 Dec 2021 09:08:27 +1300 From: "Darcy Iris" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=6353b40fbae340538b72718faf20aec8 Archived-At: X-Mailman-Approved-At: Sat, 25 Dec 2021 18:34:32 -0800 Subject: Re: [Jmap] [calsify] JSContact: gender property X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2021 20:09:49 -0000 --6353b40fbae340538b72718faf20aec8 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi! Non-binary trans person here. On Fri, Dec 24, 2021, at 08:55, Neil Jenkins wrote: > 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 preferr= ed pronouns. >=20 > 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 tho= ugh I would set the theoretical grammaticalGender field for myself to "a= nimate". Gender is complex, and if you're going to attempt to represent it in any= thing, 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 s= pecifying the "full set" (subject pronoun, object pronoun, possessive de= terminer, possessive pronoun, reflexive pronoun). Not only does this mea= n it's relatively language-agnostic, it also means that any implementati= on can refer to the contact using their actual pronouns.=20 =E2=80=94 *Darcy Iris* (ae/aer or they/them pronouns) darcy@iris.ac.nz =E2=80=A2 +1 (380) 214-7469 =E2=80=A2= +64 20 4747 797 --6353b40fbae340538b72718faf20aec8 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi! Non-bi= nary trans person here.

On Fri, Dec 24, 2021, a= t 08:55, Neil Jenkins wrote:
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 t= hat not covered by grammaticalGender?

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

As a personal exampl= e, I use ae/aer pronouns (see http= s://pronoun.is/ae/aer for usage examples), and would much prefer peo= ple use those even though I would set the theoretical grammaticalGender = field for myself to "animate".

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

My p= ersonal recommendation here is not to use a grammaticalGender field as y= ou've described, instead having only a pronouns field, that allows speci= fying the "full set" (subject pronoun, object pronoun, possessive determ= iner, possessive pronoun, reflexive pronoun). Not only does this mean it= 's relatively language-agnostic, it also means that any implementation c= an refer to the contact using their actual pronouns. 

= =E2=80=94
Darcy Iris (ae/aer or they/them pronouns)=
darcy@iris.ac.nz&= nbsp;=E2=80=A2 +1 (380) 214-7469 =E2= =80=A2 +64 20 4747 797
<= div class=3D"signature">

--6353b40fbae340538b72718faf20aec8--