From nobody Mon Jan 3 07:36:24 2022 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 368B63A0A8B for ; Mon, 3 Jan 2022 07:36:23 -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=QPq7Sx9L; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D3SY0rWX 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 Uu-LIHg_3ryj for ; Mon, 3 Jan 2022 07:36:18 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A74A3A0A87 for ; Mon, 3 Jan 2022 07:36:18 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 43FD732009E5 for ; Mon, 3 Jan 2022 10:36:17 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Mon, 03 Jan 2022 10:36:17 -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=wzuN7d9 DsC8Bvx2cibkn5NTNTB7FIqunESkIoQ0PXBs=; b=QPq7Sx9Lz4aFCQILnfzTG/R yjZTQV/D/6Ra9v2k1z3FbduXCcHyZe9+H9YpvtU4mZ0S10ybDo44A5+N6i1pL9ba T9c6me7WRxduFKEvYeYhQ8v1lSmOqvnRn6QnWXCHhCtOtQxZdK+raETGgRiDYkoM 5nNf2O9aGS9II5BjZgkfyRAM4NgZycMhpkrWAu+/EIZlwBumWkVrB6gt/Rbk4KMH 8Y0ci2wmM2ceHaGXI+rXXx8URWIIQ/qkw/0XbR1BDblJwyBWJc9/Oj9Rn5R6hzzX nWWqJUHy7FBIbg5RSxbxzsrct3LUr9C1SbKbLahl2NgU/SMhXisWUretPT/x6uA= = 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=wzuN7d 9DsC8Bvx2cibkn5NTNTB7FIqunESkIoQ0PXBs=; b=D3SY0rWXGHqA94/Bkp+8Tx tuI5FBUJ6GAe+FSImX3gjZhoCGXAYYlfmwMA9cVIPp64aE/Bn5a1eI5lTLDW0blv rAtYN8OxXZPb7OCQX42AyHKAHwSsDisnYeTcXMYWNsA8cbVO38kxX9VFRbwVATyX mcvV3yOLd1Nm8DHCNrsqghe1h0ncpZCatvqYHp9vPfdvg8n0T2GXv+10bv3dgPt1 W2eo0wYgNorkRwDM8uTm7hd6f/ol+mnMQkJH/MDuWsWma436wFo1AL0+Jt1JCq0X iafxvb4pIfCooQK2cpGCUvW8nFY4KQCB44qRrzaTC95En9nCxzaEk8Gewh6qOniQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefuddgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepheeguedvtd ekhfetgfeufefgvdeuteegfeefleehvddugeejjefhteeugfevveeinecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 88BAAAC0E99; Mon, 3 Jan 2022 10:36:16 -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: <820e5802-6aba-498d-acb1-3b879f7c8e49@www.fastmail.com> In-Reply-To: References: Date: Mon, 03 Jan 2022 16:35:55 +0100 From: "Robert Stepanek" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=cd672e8f0fae4398945136356140d4e8 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: Mon, 03 Jan 2022 15:36:23 -0000 --cd672e8f0fae4398945136356140d4e8 Content-Type: text/plain On Thu, Dec 23, 2021, at 9:08 PM, Darcy Iris wrote: > My personal recommendation here is not to use a grammaticalGender field as you've described, instead having only a pronouns field, that allows specifying the "full set" (subject pronoun, object pronoun, possessive determiner, possessive pronoun, reflexive pronoun). Not only does this mean it's relatively language-agnostic, it also means that any implementation can refer to the contact using their actual pronouns. grammaticalGender needs to stay. A couple of people asked us about the missing GENDER property from VCARD because they stored the grammatical gender in there, especially for salutations in human languages where a grammatical gender is required. We want to provide them with a straight-forward migration path to JSContact and while doing so stop confusing biological sex with grammatical gender. For salutations, a pronouns property did not seem particularly useful to me: the pronouns are instructive when talking with or about a contact. But for grammatical gender, one would have to know the language the pronouns are defined in, then infer the grammatical gender from the pronoun. That being said, I do see the additional need for pronouns and it seems services and application developers do, too. Notably, the Google People API has the addressMe field in the Person.gender property. It is a free-text field and the examples suggest to store the pronouns in the form "they/them". We could certainly add something similar, but is a free-text form good enough? If a structured property is required, then it should allow for more than just the English language. Unfortunately pronouns soon then get complicated. Cheers, Robert --cd672e8f0fae4398945136356140d4e8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, De= c 23, 2021, at 9:08 PM, Darcy Iris wrote:
My personal recommendation here is not to= use a grammaticalGender field as you've described, instead having only = a pronouns field, that allows specifying the "full set" (subject pronoun= , object pronoun, possessive determiner, possessive pronoun, reflexive p= ronoun). Not only does this mean it's relatively language-agnostic, it a= lso means that any implementation can refer to the contact using their a= ctual pronouns. 

grammati= calGender needs to stay. A couple of people asked us about the missing G= ENDER property from VCARD because they stored the grammatical gender in = there, especially for salutations in human languages where a grammatical= gender is required. We want to provide them with a straight-forward mig= ration path to JSContact and while doing so stop confusing biological se= x with grammatical gender.
For salutations, a pronouns pro= perty did not seem particularly useful to me: the pronouns are instructi= ve when talking with or about a contact. But for grammatical gender, one= would have to know the language the pronouns are defined in, then infer= the grammatical gender from the pronoun.

T= hat being said, I do see the additional need for pronouns and it seems s= ervices and application developers do, too. Notably, the Google People A= PI has the addressMe field in the Person.gender property. It is a free-t= ext field and the examples suggest to store the pronouns in the form "th= ey/them".
We could certainly add something similar, but is= a free-text form good enough? If a structured property is required, the= n it should allow for more than just the English language. Unfortunately= pronouns soon then get complicated.

Cheers= ,
Robert
--cd672e8f0fae4398945136356140d4e8-- From nobody Mon Jan 3 07:47:10 2022 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 82E153A00E9; Mon, 3 Jan 2022 07:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 pnU8vk2BiTMm; Mon, 3 Jan 2022 07:47:04 -0800 (PST) Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EC23A00E3; Mon, 3 Jan 2022 07:47:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 710B5A0B6; Mon, 3 Jan 2022 16:47:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.audriga.com Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzDwnPEs6oei; Mon, 3 Jan 2022 16:46:30 +0100 (CET) Received: from [192.168.0.94] (HSI-KBW-46-223-162-197.hsi.kabel-badenwuerttemberg.de [46.223.162.197]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 21231A06A; Mon, 3 Jan 2022 16:46:30 +0100 (CET) Content-Type: multipart/alternative; boundary="------------x93mL27bFHckL07yYYdOh0ZY" Message-ID: <9ab3530b-2e85-806b-bcf8-0cf5a11781a4@audriga.com> Date: Mon, 3 Jan 2022 16:46:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: calsify@ietf.org, IETF JMAP Mailing List References: From: Joris Baum Cc: Hans-Joerg Happel 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: Mon, 03 Jan 2022 15:47:09 -0000 This is a multi-part message in MIME format. --------------x93mL27bFHckL07yYYdOh0ZY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Robert and happy new year everyone :) , I also like the proposal and would also vote for keeping it simple and not introduce things like variable substitution. For our use case it is not necessary to add a biological sex component to JSCalendar. Having grammaticalGender definitely improves mapping from vCard to JSCalendar. As the topic of gender is apparently quite complex and also dynamic, maybe it would be a good idea to point to the Vendor-Specific Property Extension definition in the gender property section again? This way we could encourage developers to come up with their own extensions. Regards, Joris On 23.12.21 20:55, Neil Jenkins wrote: > Thanks Robert, I think this is a good, well-reasoned proposal. > > On Fri, 24 Dec 2021, at 12:48 AM, Ken Murchison wrote: >> I also wonder if we might want to add a property for a user's >> preferred pronouns. > > Is that not covered by grammaticalGender? > > 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“ or „Lieber >> Robert“ / „Sehr geehrter Herr Stepanek“. > > That feels out-of-scope to me, especially if you have to start > introducing variable substitution. > > —Neil > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Joris Baum Tel: +49 721 170293 16 Fax: +49 721 170293 179 http://www.audriga.com |http://www.twitter.com/audriga -------------------------------------------------------------------------- audriga GmbH | Durlacher Allee 47 | 76131 Karlsruhe Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034 Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel -------------------------------------------------------------------------- --------------x93mL27bFHckL07yYYdOh0ZY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Robert and happy new year everyone :) ,

I also like the proposal and would also vote for keeping it simple and not introduce things like variable substitution. For our use case it is not necessary to add a biological sex component to JSCalendar. Having grammaticalGender definitely improves mapping from vCard to JSCalendar.

As the topic of gender is apparently quite complex and also dynamic, maybe it would be a good idea to point to the Vendor-Specific Property Extension definition in the gender property section again? This way we could encourage developers to come up with their own extensions.

Regards,

Joris


On 23.12.21 20:55, Neil Jenkins wrote:
Thanks Robert, I think this is a good, well-reasoned proposal.

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

Is that not covered by grammaticalGender?

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“ or „Lieber Robert“ / „Sehr geehrter Herr Stepanek“.

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

—Neil

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

-- 
Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

http://www.audriga.com | http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Durlacher Allee 47 | 76131 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------
--------------x93mL27bFHckL07yYYdOh0ZY-- From nobody Mon Jan 3 08:21:08 2022 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 1684B3A0798; Mon, 3 Jan 2022 08:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 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_H3=0.001, RCVD_IN_MSPIKE_WL=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=TRo8zMnq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lOKyo9mY 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 wKjYu-2FQwSi; Mon, 3 Jan 2022 08:20:57 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665DB3A0793; Mon, 3 Jan 2022 08:20:57 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 560743200C4A; Mon, 3 Jan 2022 11:20:54 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Mon, 03 Jan 2022 11:20:54 -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=m+qb U4XNpHAlftg3ZYdpp9hRf0TddjFKzgoTEMbqAVM=; b=TRo8zMnqnX/aMTWE2UkD M53xiw8e+EwTGRX1lXaINz1SMc6kSZYWTnLx9JsZ7t+eaj7iPMxkQro+TCyJhYe8 0w3BSggmqKzxDezXLBN/Z2yHOGA+LpCTsaPPDh9xPXr7dnUs4qOjli5RP/da4hY6 1t6P++3FnGO0tX5BkT6wk12N9wBH+kvyTAHG0F5WFw+EYW6E0hKSfU03POCg4vAo HMFr2w481bBKgTFp/zmLTZj1ElPYWpRDzQRHPBKViPB2pD3jpQLwLA52GlXf4mQN wcDDHvhkSdAdo1KI2QhoM6/sJHTNT0y1QWPoHyfp95NVphtl5eoQytzTGNQMKOJu 5w== 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=m+qbU4 XNpHAlftg3ZYdpp9hRf0TddjFKzgoTEMbqAVM=; b=lOKyo9mYx6Xze7i2z+fLw/ zYSrjyZLQpPlkX/NEygob4JNCK/MSj88O8t/zBqgZmWHzreIE7xaXkab8dfetw4g 2FW0Hm862CPlJSQLXJ5NB8Dx9qc8DkMZf5xWowu6LbrB1/c47keX+l/mVX318o/S 0U70uismrnTEhn9r2lnTrpcvshHRG1fu8yirhfOc9TJnuCzv5jLIlzja/clbkKyU InIIjsew1QDZ8NCPHk5zD1ayhl+EaG5OWj/pCUd2zodxJbAyGcTu9rKu5sgVqiF7 RTJnChHRIueSAiwQNdA5hpE1wfPSNJi9cpjIEouY+TGe7vQFHJQ25Da8VoAGFT2Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefuddgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdftohgs vghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpefgheeuhfetuedthfejiedvheelleeufefggffftdeu tdfgvdfhfeeffefgheeggfenucffohhmrghinhepuhhnihgtohguvgdrohhrghenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgr shhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 76694AC0E99; Mon, 3 Jan 2022 11:20:53 -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: Mon, 03 Jan 2022 17:20:33 +0100 From: "Robert Stepanek" To: "Andreas Hauser" Cc: jmap@ietf.org, calsify@ietf.org Content-Type: multipart/alternative; boundary=9d3b2da4985041d9995b8a227feb6f88 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: Mon, 03 Jan 2022 16:21:02 -0000 --9d3b2da4985041d9995b8a227feb6f88 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Andreas, On Thu, Dec 23, 2021, at 3:51 PM, 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. Agreed (I am a German native speaker, too). > 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 la= st name (e.g.%LN): =E2=80=9EDear %FN=E2=80=9C, =E2=80=9EDear Professor %= LN=E2=80=9C etc. I agree with Neil that the JSContact spec does not seem the right place = for this. Such templates should rather go in the applications and servic= es that build on the contacts data. Note that some of the template langu= age that you suggest is covered by the Unicode Person Name Formatting sp= ec: https://www.unicode.org/review/pri434/ We made sure that the naming = properties in JSContact use the same terminology to interoperate with th= at PRI434. What we might consider instead is to allow setting modifiers on the gram= matical gender: grammaticalGender: - gender: ("animate", "female", ...") (mandatory) - modifiers (optional): list of - value - type ("formality", "deixis", "number") =20 where "formality": allows values "intimate", "familiar", "distanced" "deixis": allows values "proximal", "medial", "distal" "number": allows "singular" and "plural" This should cover a good number of human languages. However, I am not a = linguist and I am afraid none on this mailing is either? Cheers, Robert --9d3b2da4985041d9995b8a227feb6f88 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Andreas= ,

On Thu, Dec 23, 2021, at 3:51 PM, Andreas= Hauser wrote:
Not only is there grammaticalGender but als= o 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 gee= hrter Herr Stepanek=E2=80=9C.

= Agreed (I am a German native speaker, too).

To make this most useful in practice, a field for salutat= ion might be considered, taking variables for first name (e.g. %FN), nic= k name and last name (e.g.%LN): =E2=80=9EDear %FN=E2=80=9C, =E2=80=9EDea= r Professor %LN=E2=80=9C etc.

= I agree with Neil that the JSContact spec does not seem the right place = for this. Such templates should rather go in the applications and servic= es that build on the contacts data. Note that some of the template langu= age that you suggest is covered by the Unicode Person Name Formatting sp= ec: https://www.unico= de.org/review/pri434/ We made sure that the naming properties in JSC= ontact use the same terminology to interoperate with that PRI434.

What we might consider instead is to allow settin= g modifiers on the grammatical gender:

gram= maticalGender:
  - gender:  ("animate", "female"= , ...") (mandatory)
  - modifiers (optional): list of=
      - value
&nbs= p;     - type ("formality", "deixis", "number")
<= /div>
  
where

"formality": allows values "intimate", "familiar", "distanced"
"deixis": allows values "proximal", "medial", "distal"
"number": allows "singular" and "plural"

This should cover a good number of human languages. However, I am not a= linguist and I am afraid none on this mailing is either?
=
Cheers,
Robert
--9d3b2da4985041d9995b8a227feb6f88-- From nobody Tue Jan 4 04:07:22 2022 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 03B303A118A; Tue, 4 Jan 2022 04:07:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: brong@fastmailteam.com, jmap-chairs@ietf.org, jmap@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164129804093.5023.7746500831649043748@ietfa.amsl.com> Date: Tue, 04 Jan 2022 04:07:20 -0800 Archived-At: Subject: [Jmap] jmap - New Meeting Session Request for IETF 113 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: Tue, 04 Jan 2022 12:07:21 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana joint with: extra Number of Sessions: 1 Length of Session(s): unspecified Number of Attendees: 20 Conflicts to Avoid: Chair conflict: calext extra dispatch sedate Technology overlap: uta httpbis emailcore dmarc People who must be present: Alexey Melnikov Kenneth Murchison Murray Kucherawy Michael Douglass Jim Fenton Neil Jenkins Bron Gondwana Mario Loffredo Robert Stepanek Rene Cordier Joris Baum Hans-Jorg Happel Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jan 4 04:10:36 2022 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 B830E3A1B85 for ; Tue, 4 Jan 2022 04:10:34 -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=DDsDlnsh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IKUW9myW 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 U1fApjb7PGWF for ; Tue, 4 Jan 2022 04:10:29 -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 BEDBB3A1B83 for ; Tue, 4 Jan 2022 04:10:29 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1BFBF5C01A9 for ; Tue, 4 Jan 2022 07:10:29 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Tue, 04 Jan 2022 07:10:29 -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=OhQhuyc 7NqzZfD6MYOsF9a2IMdl8cvpJxhhae1yEmAs=; b=DDsDlnsh7gXD/PwtPSviiMr eUuSAt9RGwxrXmWthSBuSBGgVGjucKALExRjfCzGHU9HpjSKMT97U2QMPnaYx4V2 Z9Ec65zcQmP/lguWe0pN+hOW6+IcR7im19HDMWmljiiIk3tLJxZPCm39/qRQVsq6 /gCK4YPYvyQH/1EQKkleTHql9iiIwMm4YmHFTN+wop65+pLs8S631j7tQzQE3FBc DbWxEfybv+UbGHXwtoewfX0cSht47Hqf4gJFJFVlym/mbXj2X9V52Ey7OaTV/i/e jUuD4KPhhJORJfitkazpuZBmqz9yK27cC6GyQVe5Ts4y21PUOwonUn4n6rTWaMg= = 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=OhQhuy c7NqzZfD6MYOsF9a2IMdl8cvpJxhhae1yEmAs=; b=IKUW9myWlLGHsnLferGA9l xExNo54TVbh/VQozxmpr+mKX2MImtrnQX+GHzUGPOyRiqwnG0CwUBncLyDtiwX1I Th1M7kFGYv8YolkSoF1pmClkv0j+hoNHfVShZ6FOmBnbVDGGpyxi9P6m3UWCgQAl jFtJxB6050zZbytWfSi33/2k71oU6aljm/45Jlj9bwbKbsBoQKjduMlEGRGUudJg X0HodCMKh+5KiDLaNepNwn1fdMBixdeNp91vBCqNyV14e/+2T6UW1yALHRhpWq+e 9uyepEKXoFhar1DlIh0JnH1g52AOWArk5rjn2TRN8w9aYfuJoJJPs+PyCeTM6fbw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudeffedgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffveefiefgje evteehheelgeetleetveeguedthfehgffhtdejhfdvhefhtdekgfenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E8D3DAC0E99; Tue, 4 Jan 2022 07:10:28 -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: <4c0e8a9e-bad0-4388-8811-1f92401540a4@dogfood.fastmail.com> In-Reply-To: <164129804093.5023.7746500831649043748@ietfa.amsl.com> References: <164129804093.5023.7746500831649043748@ietfa.amsl.com> Date: Tue, 04 Jan 2022 23:10:04 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=731ecd6f7597440cadfec41e93049997 Archived-At: Subject: Re: [Jmap] jmap - New Meeting Session Request for IETF 113 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, 04 Jan 2022 12:10:35 -0000 --731ecd6f7597440cadfec41e93049997 Content-Type: text/plain I expect EXTRA will only need a few minutes for the couple of documents that are running there, so it didn't make sense to request a whole separate session. Nice that the datatracker now lets you combine sessions and request adjacency and all sorts of nice things! We may, depending on the recharter timing, be giving up jscontact to the CALEXT working group, which will also free up some time - but by then hopefully Fastmail is will be running JMAP-Calendars in production as well, so that's going to give us lots of experience to talk about! Cheers, Bron. On Tue, Jan 4, 2022, at 23:07, IETF Meeting Session Request Tool wrote: > > > A new meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. > > > --------------------------------------------------------- > Working Group Name: JSON Mail Access Protocol > Area Name: Applications and Real-Time Area > Session Requester: Bron Gondwana > joint with: extra > > Number of Sessions: 1 > Length of Session(s): unspecified > Number of Attendees: 20 > Conflicts to Avoid: > Chair conflict: calext extra dispatch sedate > Technology overlap: uta httpbis emailcore dmarc > > > > > People who must be present: > Alexey Melnikov > Kenneth Murchison > Murray Kucherawy > Michael Douglass > Jim Fenton > Neil Jenkins > Bron Gondwana > Mario Loffredo > Robert Stepanek > Rene Cordier > Joris Baum > Hans-Jorg Happel > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --731ecd6f7597440cadfec41e93049997 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I expect EXTRA will only need a few minutes for the couple= of documents that are running there, so it didn't make sense to request= a whole separate session.  Nice that the datatracker now lets you = combine sessions and request adjacency and all sorts of nice things!
=

We may, depending on the recharter timing, be giving up jsco= ntact to the CALEXT working group, which will also free up some time - b= ut by then hopefully Fastmail is will be running JMAP-Calendars in produ= ction as well, so that's going to give us lots of experience to talk abo= ut!

Cheers,
Bron.

On Tue= , Jan 4, 2022, at 23:07, IETF Meeting Session Request Tool wrote:


A new meeting session request has just been = submitted by Bron Gondwana, a Chair of the jmap working group.
=


----------------------= -----------------------------------
Working Group Name: JSON Mail Access Protocol
Area Name: Applications and Real-Time Area
Session Requester: Bron Gondwana
joint with:  extra

Number of Sessions: 1
Length of Session(s): unspecified
Number of Attendees: 20
Conflicts to Avoid: 
C= hair conflict: calext extra dispatch sedate
Technology overlap: uta httpbis emailcore dmarc
=

       


People who must be present:
  Alexey Melnikov
  Kenneth Murchison
  Murray Kucherawy
  Michael Douglass
  Jim Fenton
  Neil Jenkins
 = ; Bron Gondwana
  Mario = Loffredo
  Robert Stepan= ek
  Rene Cordier
  Joris Baum
  Hans-Jorg Happel

Resourc= es Requested:

Special Requests:
  
---------------------------------------------------------


_________________________= ______________________
Jmap m= ailing list


--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


= --731ecd6f7597440cadfec41e93049997-- From nobody Wed Jan 5 09:17:47 2022 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 0E0453A1200; Wed, 5 Jan 2022 09:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 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=-0.714, 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 gOSDd8yQbtjj; Wed, 5 Jan 2022 09:17:35 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A257A3A11FD; Wed, 5 Jan 2022 09:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1641403050; d=isode.com; s=june2016; i=@isode.com; bh=ZOuklyWvl+Yf1VumOLoapSyGQ3/F76h60ACkHXHG9Ac=; 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=VDzKv9/7ZSLYCR1nCFCbzGXDzms+WIWUzUFGX8ZvMkBBauIW6sTeEnknoKoene3bU6UJcS AaNy+kJT/dpLet1lgdZXleSuLUwpKC70Kyy9lJgxJMA6+5Diae587LBbVH0HR2jU0Qxuzo 3Xl8qaapyiT8/GC83lNLFfB9KKHOEwo=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 5 Jan 2022 17:17:30 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: Date: Wed, 5 Jan 2022 17:17:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 From: Alexey Melnikov To: =?UTF-8?B?157XoNeX150g15PXldeT15In?= , Warren Kumari Cc: opsdir@ietf.org, brong@fastmailteam.com, jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, The IESG , jmap-chairs@ietf.org References: <163468502899.24369.8234838512678972724@ietfa.amsl.com> <2bdf9246-e450-194b-36ac-e5c6f6216325@isode.com> In-Reply-To: <2bdf9246-e450-194b-36ac-e5c6f6216325@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------nCcV0DJXn9A1uxWT04h830Ym" Archived-At: Subject: Re: [Jmap] Warren Kumari's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) 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, 05 Jan 2022 17:17:41 -0000 --------------nCcV0DJXn9A1uxWT04h830Ym Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Hi Menachem, As Warren pointed out, I've addressed most of your comments in earlier=20 version. The upcoming -12 will clarify your comment #5: > 5. In section 6 "Security Considerations" - it would be nice to have some = additional explanation of the recommendation to cache the results for 10 min= utes. Is this to be done on the server side or at the client? Should there b= e a reference here to other documents on signature verification? After further discussion with the WG, 10 minutes were changed to 24=20 hours, which is a better period for certificate expiration. The value=20 was determined empirically. In regards to signature verification, I've added references to RFC 8551=20 and RFC 8550 elsewhere in the document. Best Regards, Alexey On 21/10/2021 14:59, Alexey Melnikov wrote: > > Hi Menachem/Warren, > > My apologies, I don't think I've seen the OpsDir review, so I will=20 > reply to it separately. > > In regards to lack of "Updates: 8621": as this defines a JMAP=20 > extension that doesn't modify the base JMAP protocol (other than=20 > extending it), it is not customary to include "Updates: 8621". Or to=20 > rephrase: a reader of RFC 8621 doesn't need to know about existence of=20 > this document unless there is desire to implement it. > > Best Regards, > > Alexey > > On 20/10/2021 06:02, =D7=9E=D7=A0=D7=97=D7=9D =D7=93=D7=95=D7=93=D7=92' wr= ote: >> Hello, >> >> I was not involved in any email discussions regarding my review. >> >> Thank you kindly. >> >> Best Regards, >> Menachem >> >> =E2=80=AB=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=93= =D7=B3, 20 =D7=91=D7=90=D7=95=D7=A7=D7=B3 2021 =D7=91-2:10 =D7=9E=D7=90=D7= =AA =E2=80=AAWarren Kumari via=20 >> Datatracker=E2=80=AC=E2=80=8F <=E2=80=AAnoreply@ietf.org=E2=80=AC=E2=80= =8F>:=E2=80=AC >> >> Warren Kumari has entered the following ballot position for >> draft-ietf-jmap-smime-09: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to >> cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/blog/handling-iesg-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT >> positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ >> >> >> >> ---------------------------------------------------------------------= - >> COMMENT: >> ---------------------------------------------------------------------= - >> >> Thanks to Menachem Dodge for the OpsDir review; I see that the >> author has >> incorporated / addressed many of the comments/nits, but I don't >> think I saw any >> sort of discussion around the "Please consider whether the >> document header >> should indicate "Updates: 8621"." (which Benjamin also referenced). >> >> It is entirely possible that I completely missed any discussions, >> but I'd be >> interested in an answer if possible. >> --------------nCcV0DJXn9A1uxWT04h830Ym Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Menachem,

As Warren pointed out, I've addressed most of your comments in earlier version. The upcoming -12 will clarify your comment #5:

= 

5. In section 6 "Security Considera=
tions" - it would be nice to have some additional explanation of the reco=
mmendation to cache the results for 10 minutes. Is this to be done on the=
 server side or at the client? Should there be a reference here to other =
documents on signature verification?
After further discussion with the WG, 10 minutes were changed to 24 hours, which is a better period for certificate expiration. The value was determined empirically.

In regards to signature verification, I've added references to RFC 8551 and RFC 8550 elsewhere in the document.

Best Regards,

Alexey


On 21/10/2021 14:59, Alexey Melnikov wrote:

Hi Menachem/Warren,

My apologies, I don't think I've seen the OpsDir review, so I will reply to it separately.

In regards to lack of "Updates: 8621": as this defines a JMAP extension that doesn't modify the base JMAP protocol (other than extending it), it is not customary to include "Updates: 8621". Or to rephrase: a reader of RFC 8621 doesn't need to know about existence of this document unless there is desire to implement it.

Best Regards,

Alexey

On 20/10/2021 06:02, =D7=9E=D7=A0=D7= =97=D7=9D =D7=93=D7=95=D7=93=D7=92' wrote:
Hello,

I was not involved in any email discussions regarding my review.

Thank you kindly.

Best Regards,
Menachem

=E2=80=AB=D7=91=D7=AA=D7=90= =D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=93=D7=B3, 20 =D7=91=D7=90=D7=95= =D7=A7=D7=B3 2021 =D7=91-2:10 =D7=9E=D7=90=D7=AA =E2=80=AAWarren Kumari vi= a Datatracker=E2=80=AC=E2=80=8F <=E2=80=AAnoreply@ietf.org=E2=80=AC= =E2=80=8F>:=E2=80=AC
Warren Kumari has entered the following ballot position for
draft-ietf-jmap-smime-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/h= andling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.or= g/doc/draft-ietf-jmap-smime/



---------------------------------------------------------------------- COMMENT:
----------------------------------------------------------------------
Thanks to Menachem Dodge for the OpsDir review; I see that the author has
incorporated / addressed many of the comments/nits, but I don't think I saw any
sort of discussion around the "Please consider whether the document header
should indicate "Updates: 8621"." (which Benjamin also referenced).

It is entirely possible that I completely missed any discussions, but I'd be
interested in an answer if possible.
--------------nCcV0DJXn9A1uxWT04h830Ym-- From nobody Wed Jan 5 11:43:51 2022 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 5F8613A0E0F; Wed, 5 Jan 2022 11:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 USn_Y2PO_Cm8; Wed, 5 Jan 2022 11:43:40 -0800 (PST) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 2FB313A0E08; Wed, 5 Jan 2022 11:43:40 -0800 (PST) Received: by mail-ua1-x933.google.com with SMTP id u6so473788uaq.0; Wed, 05 Jan 2022 11:43:40 -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 :cc; bh=7ZBRQ28zyvWweYm72x+kduJ1E8juRlHKdl3N1DRnM3A=; b=XllrXoutkUzDgsow/ntGGGoqADxZZmpr1kslqawN/FP9SIZeI3T2a72tjEtr5YvQff j6SjD9SS5/msj52UYoDMitTcw/iZ2sfdPbvc2+Zi0QnkaJS4WUdVtHUbaw4+hSRByG/2 +s/SnKCsImQ6JdRqp0ZdJNqiV5p52tIqaXgpSdAky95gY/FMsTsdjDKmEUMl5sUotkqZ yJfxuv42nVmWcXlgDQQkkZnlvQaDjXdUP5X6Lze5OX/2JgTB89t6L9znzQsEmqYcGSCj 9l2rVDBoamTA2SYRqVP3dDk5AueHogT4JEjROPg3YSW24uIU11txsxL8h2YKVDiYJT+4 zQLQ== 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:cc; bh=7ZBRQ28zyvWweYm72x+kduJ1E8juRlHKdl3N1DRnM3A=; b=796SRD89ztkxVB+7XbTynCsx2tHZ6Sj93r7/d7eos6UEpjz7putHgHOC4qwAKv9Pzm JnrqTQwRv4BqqiZvVHIKrE2zlfES0Z+kn+1nyWF/ArwGWbbK6kAd5rUM89Rkb0mYGQwB lUJq9syjWPya1lp9AwybnePB0GRRwlgYuVc5YEbuswewZ7k8IN3ju5Rk9rKsy7uib+xI qEUZJ6uoePLDkALXChAjDB1XH/fUAFX4kdtvyafkbtKy6pyZ8aLRf4iRiXJc8XZqUbJr Pg6C5Ku8XNIgbRdFiZOxCqOIZgqqaJ+OPeFOU35QhgFM1//nG7+G1mCY5JqDaA/CfkI8 tmIQ== X-Gm-Message-State: AOAM531LSKxgEd/UcKdI0LqMJRRtPsAAsDGl9+8rMipkZlDUj9L+LAOA AC+Z1T1e431hGCE5Y1/gLWEUSXqU2CLrbHWV4NaDcTo= X-Google-Smtp-Source: ABdhPJyvz5cbFzkFhOoCchqWHWZA/wW1l0FbgYB8pE9d6LdWEwMKbLv0AUP3Xzlm2HuJflKKwA0Q70fbgrsfYY/4W2Q= X-Received: by 2002:ab0:215a:: with SMTP id t26mr9029760ual.49.1641411819157; Wed, 05 Jan 2022 11:43:39 -0800 (PST) MIME-Version: 1.0 References: <163468502899.24369.8234838512678972724@ietfa.amsl.com> <2bdf9246-e450-194b-36ac-e5c6f6216325@isode.com> In-Reply-To: From: =?UTF-8?B?157XoNeX150g15PXldeT15In?= Date: Wed, 5 Jan 2022 21:43:27 +0200 Message-ID: To: Alexey Melnikov Cc: Warren Kumari , opsdir@ietf.org, brong@fastmailteam.com, jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, The IESG , jmap-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000693d9405d4daf809" Archived-At: Subject: Re: [Jmap] Warren Kumari's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) 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, 05 Jan 2022 19:43:45 -0000 --000000000000693d9405d4daf809 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Alexey, Thanks very much for addressing my comments and for keeping me informed. Best Regards, Menachem =E2=80=AB=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=93=D7= =B3, 5 =D7=91=D7=99=D7=A0=D7=95=D7=B3 2022 =D7=91-19:17 =D7=9E=D7=90=D7=AA = =E2=80=AAAlexey Melnikov=E2=80=AC=E2=80=8F <=E2=80=AA alexey.melnikov@isode.com=E2=80=AC=E2=80=8F>:=E2=80=AC > Hi Menachem, > > As Warren pointed out, I've addressed most of your comments in earlier > version. The upcoming -12 will clarify your comment #5: > > 5. In section 6 "Security Considerations" - it would be nice to have some= additional explanation of the recommendation to cache the results for 10 m= inutes. Is this to be done on the server side or at the client? Should ther= e be a reference here to other documents on signature verification? > > After further discussion with the WG, 10 minutes were changed to 24 hours= , > which is a better period for certificate expiration. The value was > determined empirically. > > In regards to signature verification, I've added references to RFC 8551 > and RFC 8550 elsewhere in the document. > > Best Regards, > > Alexey > > > On 21/10/2021 14:59, Alexey Melnikov wrote: > > Hi Menachem/Warren, > > My apologies, I don't think I've seen the OpsDir review, so I will reply > to it separately. > > In regards to lack of "Updates: 8621": as this defines a JMAP extension > that doesn't modify the base JMAP protocol (other than extending it), it = is > not customary to include "Updates: 8621". Or to rephrase: a reader of RFC > 8621 doesn't need to know about existence of this document unless there i= s > desire to implement it. > > Best Regards, > > Alexey > On 20/10/2021 06:02, =D7=9E=D7=A0=D7=97=D7=9D =D7=93=D7=95=D7=93=D7=92' w= rote: > > Hello, > > I was not involved in any email discussions regarding my review. > > Thank you kindly. > > Best Regards, > Menachem > > =E2=80=AB=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=93= =D7=B3, 20 =D7=91=D7=90=D7=95=D7=A7=D7=B3 2021 =D7=91-2:10 =D7=9E=D7=90=D7= =AA =E2=80=AAWarren Kumari via Datatracker=E2=80=AC=E2=80=8F > <=E2=80=AAnoreply@ietf.org=E2=80=AC=E2=80=8F>:=E2=80=AC > >> Warren Kumari has entered the following ballot position for >> draft-ietf-jmap-smime-09: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions= / >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks to Menachem Dodge for the OpsDir review; I see that the author ha= s >> incorporated / addressed many of the comments/nits, but I don't think I >> saw any >> sort of discussion around the "Please consider whether the document head= er >> should indicate "Updates: 8621"." (which Benjamin also referenced). >> >> It is entirely possible that I completely missed any discussions, but I'= d >> be >> interested in an answer if possible. > > --000000000000693d9405d4daf809 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Alexey,

<= /div>
Thanks very much for addressing my comments and for k= eeping me informed.

Best R= egards,
Menachem

=
=E2=80=AB=D7=91=D7=AA=D7=90=D7=A8=D7= =99=D7=9A =D7=99=D7=95=D7=9D =D7=93=D7=B3, 5 =D7=91=D7=99=D7=A0=D7=95=D7=B3= 2022 =D7=91-19:17 =D7=9E=D7=90=D7=AA =E2=80=AAAlexey Melnikov=E2=80=AC=E2= =80=8F <=E2=80=AAalexey.mel= nikov@isode.com=E2=80=AC=E2=80=8F>:=E2=80=AC
=20 =20 =20

Hi Menachem,

As Warren pointed out, I've addressed most of your comments in earlier version. The upcoming -12 will clarify your comment #5:

5. In section 6 "Sec=
urity Considerations" - it would be nice to have some additional expla=
nation of the recommendation to cache the results for 10 minutes. Is this t=
o be done on the server side or at the client? Should there be a reference =
here to other documents on signature verification?
After further discussion with the WG, 10 minutes were changed to 24 hours, which is a better period for certificate expiration. The value was determined empirically.

In regards to signature verification, I've added references to RFC 8551 and RFC 8550 elsewhere in the document.

Best Regards,

Alexey


On 21/10/2021 14:59, Alexey Melnikov wrote:
=20

Hi Menachem/Warren,

My apologies, I don't think I've seen the OpsDir review, s= o I will reply to it separately.

In regards to lack of "Updates: 8621": as this defines a= JMAP extension that doesn't modify the base JMAP protocol (other tha= n extending it), it is not customary to include "Updates: 8621&q= uot;. Or to rephrase: a reader of RFC 8621 doesn't need to know about existence of this document unless there is desire to implement it.

Best Regards,

Alexey

On 20/10/2021 06:02, =D7=9E=D7=A0=D7=97=D7=9D =D7=93=D7=95=D7=93= =D7=92' wrote:
=20
Hello,

I was not involved in any email discussions regarding my review.

Thank you kindly.

Best Regards,
Menachem

=E2=80=AB=D7=91=D7=AA=D7=90= =D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=93=D7=B3, 20 =D7=91=D7=90=D7=95= =D7=A7=D7=B3 2021 =D7=91-2:10 =D7=9E=D7=90=D7=AA =E2=80=AAWarren Kumari via = Datatracker=E2=80=AC=E2=80=8F <=E2=80=AAnoreply@ietf.org=E2=80=AC=E2=80=8F>:=E2=80=AC<= br>
Warren Kumari h= as entered the following ballot position for
draft-ietf-jmap-smime-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.iet= f.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/= draft-ietf-jmap-smime/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Menachem Dodge for the OpsDir review; I see that the author has
incorporated / addressed many of the comments/nits, but I don't think I saw any
sort of discussion around the "Please consider whether the document header
should indicate "Updates: 8621"." (which Benjami= n also referenced).

It is entirely possible that I completely missed any discussions, but I'd be
interested in an answer if possible.
--000000000000693d9405d4daf809-- From nobody Thu Jan 6 03:47:43 2022 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 32C5F3A07EA for ; Thu, 6 Jan 2022 03:47:41 -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=FS7dbXS5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XOolVMcy 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 YjG3XowXPhHG for ; Thu, 6 Jan 2022 03:47:36 -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 3BB353A07E6 for ; Thu, 6 Jan 2022 03:47:36 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 490F73201F94; Thu, 6 Jan 2022 06:47:32 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Thu, 06 Jan 2022 06:47:32 -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=lP6i eCA/dfW5h/B+FLlm2q4woj7eEPcLK2qpB9NNP1E=; b=FS7dbXS5FRLGCHth3iwT 4GhQZTrAh01O7m4SHAH7tMrDO0a7wZxf6GCZna4uIDaX7zOxdRgjyfG8UcPvVfFU wmjuVPRVML90Q8TKuAbPNYKaH4CBbplea3GGkyGebeItFzuVfLBh8cCeXU6mMsWQ C+MBrDlLqjJfsULDqbhSJ7sekJfOPDqExkROx7Vd9kkhNdQefVk5W+9Fsit+xzpJ 4C5MawcTx0ecFL+MgTJr17mZDerDdeNBAPJr2scatkUOP6q6wElBC/VdwQJn/3wW YEhI6BcpLZm1AaRn94oNQEuoItocLXNS9ma4SQxMpy+IjBW98WmNhQJONUNf4GF4 Cw== 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=lP6ieC A/dfW5h/B+FLlm2q4woj7eEPcLK2qpB9NNP1E=; b=XOolVMcy4QjzjjU0Akc172 M0gf97nKtn8pmZnSSm0Lhwt7xl0zQj1VfSfbfEaiKJZc0RbPArt+1fh3Oqzd6SOa KxN6VwA9J7FzqB/5TJO0tOyUw4N3fjjjrcCLwkVaOokMrkpbUxUQpA3KQqn3HHSs FoCELgycYT32JJVMRPzbeAV8bJGljIDd+v/ZRdTKjMlY2LM8iBCK/4J6B+8Phuou QiuAancp9E2HTT12p77UykX9YMp6UONNNca0Y6JdsWusHgwrGLxhurkWQWC9LsJo 4L5W4SMm26ps0nMUx6Q7sgotywwLgsbB+yKe9pwHojbiQYz+Jb/E0cA9bKogzOYg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefledgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeehuefhudejtdeiveekvdfhfffgleeflefhfeekhefhkeel kefhfeeufeevffejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 62AB4AC0E99; Thu, 6 Jan 2022 06:47:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4526-gbc24f4957e-fm-20220105.001-gbc24f495 Mime-Version: 1.0 Message-Id: <55e856b7-2e48-4f31-9281-f6154fd48867@localhost:3000> In-Reply-To: <9af2f7e5-1dcb-4cef-8b59-7b6e7ca2cb76@dogfood.fastmail.com> References: <9af2f7e5-1dcb-4cef-8b59-7b6e7ca2cb76@dogfood.fastmail.com> Date: Thu, 06 Jan 2022 22:47:26 +1100 From: "Neil Jenkins" To: "Bron Gondwana" , "Jim Fenton" Cc: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=a5eb0cc56ce24b628f1841247f8f5a52 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: Thu, 06 Jan 2022 11:47:41 -0000 --a5eb0cc56ce24b628f1841247f8f5a52 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 21 Dec 2021, at 12:46 AM, Bron Gondwana wrote: > 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 i= t is an error to provide ifInState argument. >=20 > Neil - do we have a good generic way to handle objects for which there= 's no valid `state`? Bron and I discussed this out of band today and came to the conclusion t= his is actually different enough to the standard `/set` method that we s= hould not try to force it into that (requiring a bunch of exceptions to = the standard behaviour to be documented), but should define a new method= instead, e.g. `Blob/upload`. This simply won't take an `ifInState` argu= ment or return states. =E2=80=94Neil --a5eb0cc56ce24b628f1841247f8f5a52 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, 21= Dec 2021, at 12:46 AM, Bron Gondwana wrote:
It is dist= inguished by being the cr= eate 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.

Ne= il - do we have a good generic way to handle objects for which there's n= o valid state?
=

Bron and I discussed this out of = band today and came to the conclusion this is actually different enough = to the standard /set method that we should not try to force = it into that (requiring a bunch of exceptions to the standard behaviour = to be documented), but should define a new method instead, e.g. Blo= b/upload. This simply won't take an ifInState argumen= t or return states.

=E2=80=94Neil
--a5eb0cc56ce24b628f1841247f8f5a52-- From nobody Thu Jan 6 04:14:37 2022 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 6D60E3A08ED; Thu, 6 Jan 2022 04:14:30 -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: <164147127034.30056.7716467771631507332@ietfa.amsl.com> Date: Thu, 06 Jan 2022 04:14:30 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-smime-12.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: Thu, 06 Jan 2022 12:14:31 -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 : S/MIME signature verification extension to JMAP Author : Alexey Melnikov Filename : draft-ietf-jmap-smime-12.txt Pages : 11 Date : 2022-01-06 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-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-12 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Thu Jan 6 04:21:10 2022 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 54D2F3A091E for ; Thu, 6 Jan 2022 04:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 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, NICE_REPLY_A=-0.714, 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 7yMBRPddHYAD for ; Thu, 6 Jan 2022 04:21:03 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 423AE3A091C for ; Thu, 6 Jan 2022 04:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1641471662; d=isode.com; s=june2016; i=@isode.com; bh=7uXz0sfKdVYdryFoYF+KT5pzc6qnM3zlV+NHX0Czq7g=; 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=mcoDsUVxxLSMHOjeuR209Y+AriTY7R/wcM2TlpFlhkU70K9VSrfej6GQ12FnED1Cf6XNM0 JtWrgI/jJtSJ3iepQttur+FllcsvQA002Fd6uLzmAq2c8wMtGJFH1Q4RJA+tJCCPjF16Gx a8bR/dCGlGRvFjdhgeYyi7UU3OXLIf4=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 6 Jan 2022 12:21:02 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <9c429cc7-e4ee-b3c3-e54a-2cacab6e9ed3@isode.com> Date: Thu, 6 Jan 2022 12:21:01 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 To: jmap@ietf.org, "Murray S. Kucherawy" References: <164147127034.30056.7716467771631507332@ietfa.amsl.com> From: Alexey Melnikov In-Reply-To: <164147127034.30056.7716467771631507332@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-smime-12.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: Thu, 06 Jan 2022 12:21:08 -0000 Hi all, On 06/01/2022 12:14, internet-drafts@ietf.org wrote: > 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-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-12 This version addresses the last comment from Neil about interaction with Email/changes. Basically it recommends that "smimeVerifiedAt" changes don't cause inclusion in Email/changes result, but changes to "smimeStatus", "smimeStatusAtDelivery" and/or "smimeErrors" do. This would allow use of Email/changes for monitoring for S/MIME status changes. Murray, I think this version is ready for approval. Best Regards, Alexey From nobody Wed Jan 12 00:16:37 2022 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 5F2083A0987; Wed, 12 Jan 2022 00:16:32 -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=Gr3K8Dpr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nr4A9HWa 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 9eP31ryj5eES; Wed, 12 Jan 2022 00:16:27 -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 52EE33A0980; Wed, 12 Jan 2022 00:16:27 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B03E85C046C; Wed, 12 Jan 2022 03:16:26 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Wed, 12 Jan 2022 03:16:26 -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=eY1KULr c/9pm86TnpFBDgeAatJsqNWlwHT7DN+8Xfkc=; b=Gr3K8DprG/Ynzz2ZoE9aGjY jPdJDahBCkretsZ31jlRd2GEaLKMdTdVxLocGn2chave6B5DJ+DcftNGDP6xndYc nU4EU7TmPVxEXqEihLJrV7Uzil1ebVZZSjlgxhCEtKSyTCNp8cHSHcxvMGsgaoW6 OIb/hE9bW64B7SGAZAUNt4pjLVW7UEcKEZx87HGk+iZBnDEHK3PUiIZMtK/inuOF xreNA84UNllZ1ZPQlY68xGjhSXMTTraBIujd/Z5E+1kt6N1Nt1uM4LyMWkoeIoba XSxOEUVC0+58tbCuHqTrLAr5W57aDGEHCb4pZUtkP4E0QknUKABKLqjWxlGPGsg= = 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=eY1KUL rc/9pm86TnpFBDgeAatJsqNWlwHT7DN+8Xfkc=; b=nr4A9HWaIVwRjOoDo8gCuL MeDrloXMACnW7Pa26x65a6hvUmgB8eECoedErf8Gk/uwvGHAe+Wk04uiPIn047XA U506YV5BH3V/lzol5tJgnH1yOwNJ3Z+46q5lQ+VUkEevKCVtFi1WJR3q6grC4sEl G+ubFPaMCUSQOlt6CDXWKVB1nV+06AScsAImh2FbyXKrCjXMU/S5+QrABJkA5FNT +6GmA12l42xjivD9lAtRQj13jaXn38DP0fQZHrwG0wWiCu0iq/yVf9NGI+nQplqU 1g0byHvZE4T6iI9GEIKMT10K6BTokHOHicrBfhDDDqZZAOxYTgZl9kHIKb1uog6w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehgedguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshht ohesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeethfffff ekueekveelleeglefhgeefjeeugeetkeejkefgtdfhheehvdehhedvhfenucffohhmrghi nhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5728AAC0E99; Wed, 12 Jan 2022 03:16:26 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4569-g891f756243-fm-20220111.001-g891f7562 Mime-Version: 1.0 Message-Id: In-Reply-To: <4f2544e4-cd6b-48f5-8b17-95035450f006@www.fastmail.com> References: <1e90f8b2-2d51-4034-8a77-a2dc5c6b31f3@localhost:3000> <4f2544e4-cd6b-48f5-8b17-95035450f006@www.fastmail.com> Date: Wed, 12 Jan 2022 09:16:06 +0100 From: "Robert Stepanek" To: calsify@ietf.org, jmap@ietf.org Content-Type: multipart/alternative; boundary=308c4fcaff5143729133cc615e980cd3 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: Wed, 12 Jan 2022 08:16:36 -0000 --308c4fcaff5143729133cc615e980cd3 Content-Type: text/plain Sorry for the double cross-post, but earlier in this thread the jmap mailing list got split off. On Wed, Jan 12, 2022, at 9:13 AM, Robert Stepanek wrote: > > On Fri, Jan 7, 2022, at 9:10 AM, Robert Stepanek wrote: >> The next RFC draft will reflect these decisions. Thanks to all of you for your input. > > And this is what we will get published in the next draft version soon: > > 2.2.6. speakToAs > > Type: SpeakToAs (optional). > > Provides information how to address, speak to or refer to the entity > that is represented by this card. A SpeakToAs object has the > following properties, of which at least one property other than @type > MUST be set: > > * @type: String (mandatory). Specifies the type of this object. > This MUST be SpeakToAs. > > * grammaticalGender: String (optional). Defines which grammatical > gender to use in salutations and other grammatical constructs. > Allowed values are: > > - animate > - female > - inanimate > - male > - neuter > > Note that the grammatical gender does not allow to infer the > gender identities or biological sex of the contact. > > * pronouns: String (optional). Defines the gender pronouns that the > contact chooses to use for themselves. Any value or form is > allowed. Examples in English include she/her and they/them/ > theirs. > > The property values SHOULD be localized in the language defined in > the language property. They MAY be overridden in the localizations > property (Section 2.5.1). > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --308c4fcaff5143729133cc615e980cd3 Content-Type: text/html
Sorry for the double cross-post, but earlier in this thread the jmap mailing list got split off.

On Wed, Jan 12, 2022, at 9:13 AM, Robert Stepanek wrote:

On Fri, Jan 7, 2022, at 9:10 AM, Robert Stepanek wrote:
The next RFC draft will reflect these decisions. Thanks to all of you for your input.

And this is what we will get published in the next draft version soon:

2.2.6.  speakToAs

   Type: SpeakToAs (optional).

   Provides information how to address, speak to or refer to the entity
   that is represented by this card.  A SpeakToAs object has the
   following properties, of which at least one property other than @type
   MUST be set:

   *  @type: String (mandatory).  Specifies the type of this object.
      This MUST be SpeakToAs.

   *  grammaticalGender: String (optional).  Defines which grammatical
      gender to use in salutations and other grammatical constructs.
      Allowed values are:

      -  animate
      -  female
      -  inanimate
      -  male
      -  neuter

      Note that the grammatical gender does not allow to infer the
      gender identities or biological sex of the contact.

   *  pronouns: String (optional).  Defines the gender pronouns that the
      contact chooses to use for themselves.  Any value or form is
      allowed.  Examples in English include she/her and they/them/
      theirs.

   The property values SHOULD be localized in the language defined in
   the language property.  They MAY be overridden in the localizations
   property (Section 2.5.1).

_______________________________________________
calsify mailing list


--308c4fcaff5143729133cc615e980cd3-- From nobody Thu Jan 13 01:04:55 2022 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 EC36E3A0F09; Thu, 13 Jan 2022 01:04:53 -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.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <164206469391.29750.6657881927092720696@ietfa.amsl.com> Date: Thu, 13 Jan 2022 01:04:53 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-10.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: Thu, 13 Jan 2022 09:04:54 -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-10.txt Pages : 26 Date : 2022-01-13 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-10.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-10 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sun Jan 16 23:37:27 2022 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 509483A0B08; Sun, 16 Jan 2022 23:37:19 -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.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <164240503923.13116.15351594530964236727@ietfa.amsl.com> Date: Sun, 16 Jan 2022 23:37:19 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-vcard-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: Mon, 17 Jan 2022 07:37:20 -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-09.txt Pages : 41 Date : 2022-01-16 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-vcard-09 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Thu Jan 20 06:13:06 2022 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 A31313A132D; Thu, 20 Jan 2022 06:12:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , brong@fastmailteam.com, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, rfc-editor@rfc-editor.org, superuser@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <164268797563.4903.13320597699351520220@ietfa.amsl.com> Date: Thu, 20 Jan 2022 06:12:55 -0800 Archived-At: Subject: [Jmap] Protocol Action: 'S/MIME signature verification extension to JMAP' to Proposed Standard (draft-ietf-jmap-smime-12.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: Thu, 20 Jan 2022 14:12:56 -0000 The IESG has approved the following document: - 'S/MIME signature verification extension to JMAP' (draft-ietf-jmap-smime-12.txt) as Proposed Standard This document is the product of the JSON Mail Access Protocol Working Group. The IESG contact persons are Murray Kucherawy and Francesca Palombini. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ Technical Summary This spec extends the JMAP Mail Protocol (RFC8621) with a way to obtain information about S/MIME signature verification status. Working Group Summary This document originally included both the verification and the creation of S/MIME signatures, but was split into two documents and this one is just the verification part. The main discussion was around cached validation status and being able to know if the server successfully validated the message in the past once a key has expired. There was also discussion about whether there was any point in describing what specifically caused validation to fail, or just a simple yes/no on validity. This document was discussed in multiple IETF sessions, as well as on the mailing list, and everybody was happy with the end result. Document Quality This spec is easy to implement for a server which already validates S/MIME. It can either store information or always calculate in real-time. It uses the standard JMAP extension mechanism to add new data items to the existing Email object, so will be familiar to anybody who has implemented JMAP. Personnel Document Shepherd - Bron Gondwana (EXTRA co-chair) Responsible Area Director - Murray Kucherawy