From nobody Mon Oct 4 06:50:39 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 6C7C93A05E2; Mon, 4 Oct 2021 06:50:09 -0700 (PDT) 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.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163335540929.14373.10980130509161063965@ietfa.amsl.com> Date: Mon, 04 Oct 2021 06:50:09 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-blob-01.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, 04 Oct 2021 13:50: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 : JMAP Blob management extension Author : Bron Gondwana Filename : draft-ietf-jmap-blob-01.txt Pages : 12 Date : 2021-10-04 Abstract: The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP PUT 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 datatypes. 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-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-blob-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 4 07:52:05 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 2A37C3A08BD; Mon, 4 Oct 2021 07:51:52 -0700 (PDT) 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.38.0 Auto-Submitted: auto-generated Precedence: bulk CC: brong@fastmailteam.com, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <163335911215.28215.10771700489986899206@ietfa.amsl.com> Date: Mon, 04 Oct 2021 07:51:52 -0700 Archived-At: Subject: [Jmap] Last Call: (S/MIME signature verification extension to JMAP) to Proposed Standard 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, 04 Oct 2021 14:52:00 -0000 The IESG has received a request from the JSON Mail Access Protocol WG (jmap) to consider the following document: - 'S/MIME signature verification extension to JMAP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-10-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an extension to JMAP for Mail (RFC 8621) for returning S/MIME signature verification status. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Oct 7 07:10:11 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 1A5BE3A08D7; Thu, 7 Oct 2021 07:09:48 -0700 (PDT) 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 CY4-2pP3cBGJ; Thu, 7 Oct 2021 07:09:42 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 F0A9F3A0846; Thu, 7 Oct 2021 07:09:40 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id g13so3750115uaj.3; Thu, 07 Oct 2021 07:09:40 -0700 (PDT) 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=Ots8LIEKC1PeYNs4ABL9in1nAJwyaRnE4aCEfuifr/g=; b=eNLC7fZnc+tY/Eu62KBDyGo315HWsDmLpTVzuVGQrkW4PZfJUDP/WgBn3RLNrgoJ8+ TV+eqCMD8C0n1FqcHm8UFNM+zc7ObOfFqrYdAFaQItaxDKYHsfJS3Bu4J3jVd/zXfY0B 6o6Zb7eWsIVBFXzZ+lMcxKibElecXqBR9pPT5TihYgfMk2Hdjc2Utp0C93axCMgkXTXX dXAmvonTSbEPdTSGECJcNZ5XSOWtdfqKUiCE7PvViFwSe5Znh76wRFyeffyz9oTQw+Fl gm1zmENYI1TgoT1SxET4ePCWvPZpyiBE/Or0RnbP6tcjbuq5r0I3Ipu2s//yHYytYRNg Pj+w== 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=Ots8LIEKC1PeYNs4ABL9in1nAJwyaRnE4aCEfuifr/g=; b=HFkpbRfloIKGB24dSyiGabqvbR5OY2MU5RhfZp9i/mWMiebfpJlVOFO086HinYO7dZ yPjekQ+q8a9trkL/iKD2FqUncUf7WjURzGcL73x20kwtLuu1na5+s6pk+8aaarYiKioZ C0mdT/+xtfYd1d4JH98l5yGbKVXx9mWLpyvWXhGDRRau2nQzBX5KOWkMymrMH3t8LDno pmDLWQ1I9KZZPlEc6r/97aQ46rdC/g2oW8vIYpNc75FgXF1srFPu+xKMuMPrsuiFOhJA /No1ADnC4hxACvZoiIJAIGeiROx5pGwRrTQlLEFNZbNQgLHazGi38U6TSh/VlcBpz1Rn NmHA== X-Gm-Message-State: AOAM531KHXg4Orm9OhH8+ZHsxMmyK9os0V8SZlzHA3xW/G07FYF+/rYe 2hTvLSNKmepzZrGQ+n4vYgHJt1w6z9z3CGHYtNqFRKYOCJpgLA== X-Google-Smtp-Source: ABdhPJwqh4B0i9L+bSqrO7TCpaupfl4xKqB0nl6tdvzEg16xgbZLvspcWDagZYLoOZs3q+0FHCsmRSl5q/yDMKUNJFw= X-Received: by 2002:ab0:5e9a:: with SMTP id y26mr4531843uag.87.1633615779453; Thu, 07 Oct 2021 07:09:39 -0700 (PDT) MIME-Version: 1.0 References: <163335911215.28215.10771700489986899206@ietfa.amsl.com> In-Reply-To: <163335911215.28215.10771700489986899206@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Thu, 7 Oct 2021 07:09:28 -0700 Message-ID: To: last-call@ietf.org Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org Content-Type: multipart/alternative; boundary="0000000000003bdff705cdc3d086" Archived-At: Subject: Re: [Jmap] Last Call: (S/MIME signature verification extension to JMAP) to Proposed Standard 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, 07 Oct 2021 14:09:54 -0000 --0000000000003bdff705cdc3d086 Content-Type: text/plain; charset="UTF-8" Apologies; this second Last Call was requested in error. After the telechat that's in progress I'll figure out how to dislodge it from that process error and get it moving forward. -MSK On Mon, Oct 4, 2021 at 7:52 AM The IESG wrote: > > The IESG has received a request from the JSON Mail Access Protocol WG > (jmap) > to consider the following document: - 'S/MIME signature verification > extension to JMAP' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-10-18. Exceptionally, comments > may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document specifies an extension to JMAP for Mail (RFC 8621) for > returning S/MIME signature verification status. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > --0000000000003bdff705cdc3d086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies; this second Last Call was requested=20 in error.=C2=A0 After the telechat that's in progress I'll figure o= ut how to=20 dislodge it from that process error and get it moving forward.
-MSK

On Mon, Oct 4, 2021 at 7:52 AM The IESG <iesg-secretary@ietf.org> wrote:<= br>

The IESG has received a request from the JSON Mail Access Protocol WG (jmap= )
to consider the following document: - 'S/MIME signature verification extension to JMAP'
=C2=A0 <draft-ietf-jmap-smime-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final=
comments on this action. Please send substantive comments to the
last-call@ietf.org<= /a> mailing lists by 2021-10-18. Exceptionally, comments may
be sent to iesg@ietf.org= instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-j= map-smime/



No IPR declarations have been submitted directly on this I-D.





--0000000000003bdff705cdc3d086-- From nobody Thu Oct 7 07:54:36 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 E5EF13A0838; Thu, 7 Oct 2021 07:54:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <163361846191.20653.8155866248617760108@ietfa.amsl.com> Date: Thu, 07 Oct 2021 07:54:21 -0700 Archived-At: Subject: [Jmap] Murray Kucherawy's Yes on draft-ietf-jmap-smime-09: (with COMMENT) 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, 07 Oct 2021 14:54:22 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-jmap-smime-09: Yes 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: ---------------------------------------------------------------------- Thank you to Kirsty Paine for her ARTART review. I suggest changing "spec" to "specification" or "document" in the Abstract. From nobody Fri Oct 8 05:31:23 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 21D953A16F2 for ; Fri, 8 Oct 2021 05:31:22 -0700 (PDT) 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, 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=XyqGzb/7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EB+gQKgh 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 XLQc45PJZShU for ; Fri, 8 Oct 2021 05:31:17 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C83B3A16EE for ; Fri, 8 Oct 2021 05:31:16 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 256DF5C00E2 for ; Fri, 8 Oct 2021 08:31:15 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 08 Oct 2021 08:31:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= message-id:date:mime-version:to:from:subject:content-type :content-transfer-encoding; s=fm1; bh=CgYsaJH8Jsbq4sDngdjNg/S0Q9 yrRH4i9rLP+jhBvSU=; b=XyqGzb/7Yj9+ty+DMOmL1t/g0vN+dy5Ptx/3kLsq/5 8KThP78yhD94omQLlGA4Zl033EU5s9g3KwAe6ohsz8JnEGM+nqTvN6aoaYq5b2rF ugJkZ7YzhW5JY4kareomKUmB3CBA4C7ilI4WY0NUWScGVXf0ebmtSyIOqbVWhHDf Me3IZE0sRUuyE5uYHUJHAI8WmXSkzLHu40lOsDl84M8vE4tLxhwgcbqvueuOopkl TobqT/Q28hXvEAQf4n+dSVskbgST2etVzQG3+qG5fzWmK1pSltwGZPQI60PMCkgd QCw86HqczQ8jcXvJhgq9a51+G7g5xmlyhPCTIjQukAOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=CgYsaJ H8Jsbq4sDngdjNg/S0Q9yrRH4i9rLP+jhBvSU=; b=EB+gQKghc2LTeXgcrRzHSE voluSh0tPaaEXW230HFeZdkn4oxpMhsccfm5xIkqHuPwF6qPyiT3EGNFIanhqyO9 Al3xDfrxq2jz/libUDQMlP/hRs/INUqJMnM+D99Iz6WlOVkNovBvbgJIKBljaMQE xnDjv9LkcEfcbMtRwROMiQnWEU8Fwh2CmSjOFSmzgS4w2Ej1go8NTGYTkB31weF0 ukQQb0bCi42sLHvuKqfY9GwoJmq8LGiHEhhlID/JNB0x3YoJNSbqX8lVa0+uFzMW 14HzYe5YLGio5KZQKgnte0WkbQuNSjUuOhVH+KVWOlr8qQeTM8xkqQj9T02/7dOA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddttddghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfvhffutgfgsehtjeertd dtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshht mhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpefhhfeffeetfeeiueetuefhleffhf ejhfefgefhleetgefggffhheegheeffefhteenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 8 Oct 2021 08:31:14 -0400 (EDT) Message-ID: <170e2573-48a4-d71d-3d05-37a0244dba41@fastmail.com> Date: Fri, 8 Oct 2021 08:31:14 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 To: jmap@ietf.org Content-Language: en-US From: Ken Murchison Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Jmap] draft-ietf-jmap-blob-01 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: Fri, 08 Oct 2021 12:31:22 -0000 I found a couple of nits/ typos: - Abstract: "HTTP PUT and GET" -> "HTTP POST and GET" - Sec 3: "base spec RFC8210" -> "base specification RFC8620" -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Fri Oct 8 05:46:43 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 B9BFA3A16FC for ; Fri, 8 Oct 2021 05:46:40 -0700 (PDT) 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=V494T67D; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TnbuJ8eN 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 hHnx_BOGtNxn for ; Fri, 8 Oct 2021 05:46:36 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2024B3A1654 for ; Fri, 8 Oct 2021 05:46:35 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 619045C00F9 for ; Fri, 8 Oct 2021 08:46:35 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Fri, 08 Oct 2021 08:46:35 -0400 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=fm3; bh=V7ZMIIY bkM5TUBUdyUBvsDMnAi88Hstf4xYsr7nukKg=; b=V494T67D+VvfDozMXvFvDYZ WWjzEeHxT7yPHwCZbsPB1MinJAjlabzt1+19z6A+F3ZRIGlyGips38w7wMkqsLVL dG/Gq72qPRDRJ0/7mVgu+f5Np5uQJBE+qot97UBd3CgzFOg7PcnAlPiPhrquCuxD zz/j9kZS4CoEGm7whsgtFRhat5GkkL573+lHWouehKf1KzXmIxs2XiwGYn22n7er hu/6lppcwDNjzvmEDLKTihEIMtmq4GO7f2QZYY4PZHcIw3XkwhQH1Md+iTlJ/K8B 5kA+Ddm8T8eXwTUYaSCA91OYnwuoQnDyIfxpBlJtDUAgDwPlJQbbar3XZxxgJiQ= = 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=V7ZMII YbkM5TUBUdyUBvsDMnAi88Hstf4xYsr7nukKg=; b=TnbuJ8eNj15ac8WSTZMcV8 L4x0S1V4fdPUrQFoCRJXBtbbXNA+I3/nXxY91766RDijJeXioOPV4yo1iNkkWBMR FP/4Z2Og+eA4RcwbG03p0w/hh5dpN5VpFaqdvZUS7DDdmdKbLoSJVTGUDEAghQvU TnzvOwt1DchYqy4PBtanljzfYPKdLuBxxuQCMRDHwK9IonGnvrBkFkH2AiB1OWpy PXY3vzRhS5Qa6HJF92lVwYD0lBkEaEJp8BXFqzoOveAspd5Cau+Pp8HvN6jM/ZRF eUajXMMuKVZHBCozW1iL9PHOmfKYLo73iegkL4ba0J1X7ijG78Y1pPEQAFX/a8nQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddttddgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffveefiefgje evteehheelgeetleetveeguedthfehgffhtdejhfdvhefhtdekgfenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4205BAC03AF; Fri, 8 Oct 2021 08:46:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1345-g8441cd7852-fm-20211006.001-g8441cd78 Mime-Version: 1.0 Message-Id: In-Reply-To: <170e2573-48a4-d71d-3d05-37a0244dba41@fastmail.com> References: <170e2573-48a4-d71d-3d05-37a0244dba41@fastmail.com> Date: Fri, 08 Oct 2021 23:46:15 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=8910e89456144cfcb174a3b05d453fd6 Archived-At: Subject: Re: [Jmap] draft-ietf-jmap-blob-01 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: Fri, 08 Oct 2021 12:46:41 -0000 --8910e89456144cfcb174a3b05d453fd6 Content-Type: text/plain Great, thanks - I'll get that updated. Cheers, Bron. On Fri, Oct 8, 2021, at 23:31, Ken Murchison wrote: > I found a couple of nits/ typos: > > - Abstract: "HTTP PUT and GET" -> "HTTP POST and GET" > > - Sec 3: "base spec RFC8210" -> "base specification RFC8620" > > > -- > Kenneth Murchison > Senior Software Developer > Fastmail US LLC > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --8910e89456144cfcb174a3b05d453fd6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Great, thanks - I'll get that updated.

Chee= rs,

Bron.

=
On Fri, Oct 8, 2021, at 23:31, Ken Murchison wrote:
=
I found a couple of nits/ typos:

- Abstract: "HT= TP PUT and GET" -> "HTTP POST and GET"

- Sec 3: "base = spec RFC8210" -> "base specification RFC8620"


-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

<= div style=3D"font-family:Arial;">_______________________________________= ________
Jmap mailing list


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

--8910e89456144cfcb174a3b05d453fd6-- From nobody Fri Oct 8 05:56:05 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 719CD3A1711 for ; Fri, 8 Oct 2021 05:56:02 -0700 (PDT) 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=yynqZpcR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ee9RS6xF 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 Jbj-NZzaH1ia for ; Fri, 8 Oct 2021 05:55:57 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523CA3A170D for ; Fri, 8 Oct 2021 05:55:57 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B25C15C009E for ; Fri, 8 Oct 2021 08:55:56 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Fri, 08 Oct 2021 08:55:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=7Q+q5aBDhL+luZjIUd76fzzx/ngge6UuFznMF1j trqY=; b=yynqZpcRxYIWWLZlsTrQAKJhFuXqCsYp4c/CUg2V+VISvPraWLw4TD5 T0OYi2zXEtgrfjoL7UKe0zGYgmy0yQ/2/fNduMaoc9DVJlTyxKv/rzldyVSD9RAW 32syHcJ9483FWb5Gy73HfD8ibhbpn26wwlURsu0DzfQNJtk0CMlQsFIBC6stfnGa ynhH4kLiHa11ufD9UF7TSV54z+ZZS+s6YbnopvHrObBpYzevbHvBxodGDo64Wsm3 a+HHxhQ0FOKmjzlIbJy+aRDZIcr5YRrAnByG7yn3br9Ba9agW0Mrd8TFFbmfnk8c OwoazIaME8SuoJa6Gf1H01dp7hZX5LA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=7Q+q5aBDhL+luZjIUd76fzzx/ngge 6UuFznMF1jtrqY=; b=ee9RS6xFZbanr91L5Ung+qJazrZBLKDZOHIb7l6V/3KUe Q+Q/ukE9lhf1P6dWEtJxRcnz02LDO3qgw+KnqmEntWMsvfqBH8LACFH8YKH1xe61 kfDxJQOM8UUPa5h4SXODqA2wdyK4Jss8RlxAqP8+pq5lHZ7GQe9H/62p0FM/A37D zaDoKpbZW16ckKXkSx+88petjv+fmIbu+F6a6ckR6+S8oYm+dAUEkrnlmycBHPCa 9pvB/lzzZgQJZcqEly69BZTjO2P5Xf69Lquoyq6sEZ8Q019yHFJJDkRJTG5bwh1O mtU43q7JrNwj16BIl8gdZdY4J8d5WzdPr3BwU1+Mg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddttddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefgvdeglefhteeige dtudefuedvffdtfeduueelhedviefgudfggedvjedvledtjeenucffohhmrghinhepghhi thhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 95A8FAC0380; Fri, 8 Oct 2021 08:55:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1345-g8441cd7852-fm-20211006.001-g8441cd78 Mime-Version: 1.0 Message-Id: <50b210f0-f3c7-41b5-a26d-e308eea91299@dogfood.fastmail.com> Date: Fri, 08 Oct 2021 23:55:35 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=7545cac62e044dbd90444b8f8b86fa2e Archived-At: Subject: [Jmap] Blob draft question: type vs datatype 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: Fri, 08 Oct 2021 12:56:03 -0000 --7545cac62e044dbd90444b8f8b86fa2e Content-Type: text/plain https://github.com/brong/draft-gondwana-jmap-blob/issues/1 I've partially renamed things from 'datatype' to 'type', but the problem is that "type" is also used for mimetype, which could cause some confusion. But also "types" is used in RFC8620 for PushSubscriptions. .... Suggestions, what would people prefer? I'm working with "datatype", "data type", "type", "typename" and "type name" as ways to describe it, and they all have pros and cons. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --7545cac62e044dbd90444b8f8b86fa2e Content-Type: text/html

I've partially renamed things from 'datatype' to 'type', but the problem is that "type" is also used for mimetype, which could cause some confusion.

But also "types" is used in RFC8620 for PushSubscriptions.

....

Suggestions, what would people prefer?  I'm working with "datatype", "data type", "type", "typename" and "type name" as ways to describe it, and they all have pros and cons.

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


--7545cac62e044dbd90444b8f8b86fa2e-- From nobody Fri Oct 8 06:43:28 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 481D63A045B; Fri, 8 Oct 2021 06:43:26 -0700 (PDT) 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.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163370060620.18777.14584478142298431039@ietfa.amsl.com> Date: Fri, 08 Oct 2021 06:43:26 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-blob-02.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: Fri, 08 Oct 2021 13:43:26 -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-02.txt Pages : 12 Date : 2021-10-08 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-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-blob-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 11 03:03:36 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 C6E003A07A2; Mon, 11 Oct 2021 03:03:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com, brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <163394659178.16379.4322542081082229915@ietfa.amsl.com> Date: Mon, 11 Oct 2021 03:03:11 -0700 Archived-At: Subject: [Jmap] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-jmap-smime-09=3A_=28with_COMMENT=29?= 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, 11 Oct 2021 10:03:12 -0000 Éric Vyncke 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: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Bron Gondwana for his shepherd's write-up about the WG consensus. I hope that this helps to improve the document, Regards, -éric -- Section 4.1 -- I cannot parse the sentence below, probably because of missing quotes or punctuation: smimeStatus: "String|null". null signifies that the message doesn't Suggest to replace with smimeStatus: "String|null". A smimeStatus value of "null" signifies that the message doesn't -- Section 6 -- Just wondering about the cache for 10 minutes only... The amount of information to be stored seems very little so the signature status should be kept until the trust anchors are modified. From nobody Mon Oct 11 03:49:13 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 47A693A0C58; Mon, 11 Oct 2021 03:48:28 -0700 (PDT) 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, NICE_REPLY_A=-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 (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 HkPp8RrCbrCI; Mon, 11 Oct 2021 03:48:24 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id BD7DC3A0C56; Mon, 11 Oct 2021 03:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1633949302; d=isode.com; s=june2016; i=@isode.com; bh=EBqRvhgQ3h4ZShY7C+eV8g8hMyRD+GezD6Di4rTIr5I=; 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=ExHrRGK3JF/tgr8HAB/mNA6FBeIywqJ4taldqrQ+rgf79T7S4shCDSpJC1b0HhTWjw3qN+ u9hPfD5pxuc+m/oP+XcuQBWpHOEeU5K+Y+IfRkekkYGytT6+t5apR5rtDTLtPyH/FmZK1f L2U8CyryStKu2dHQfXsluslqtdwjTWo=; Received: from [192.168.1.222] (host31-49-142-77.range31-49.btcentralplus.com [31.49.142.77]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 11 Oct 2021 11:48:21 +0100 To: =?UTF-8?Q?=c3=89ric_Vyncke?= , The IESG Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com References: <163394659178.16379.4322542081082229915@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <1b4bad6a-c1ad-80a3-10ac-301685a77ecd@isode.com> Date: Mon, 11 Oct 2021 11:48:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <163394659178.16379.4322542081082229915@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Jmap] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-jmap-smime-09=3A_=28with_COMMENT=29?= 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, 11 Oct 2021 10:48:29 -0000 Hi =C3=89ric, Thank you for your comments! On 11/10/2021 11:03, =C3=89ric Vyncke via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education). > > Special thanks to Bron Gondwana for his shepherd's write-up about the WG > consensus. > > I hope that this helps to improve the document, > > Regards, > > -=C3=A9ric > > -- Section 4.1 -- > > I cannot parse the sentence below, probably because of missing quotes or > punctuation: > smimeStatus: "String|null". null signifies that the message doesn= 't > Suggest to replace with > smimeStatus: "String|null". A smimeStatus value of "null" signifi= es > that the message doesn't Ok. > -- Section 6 -- > > Just wondering about the cache for 10 minutes only... The amount of inform= ation > to be stored seems very little so the signature status should be kept unti= l the > trust anchors are modified. It is more complicated than that. One of the underlying certificates=20 might get revoked (which is outside of control of the JMAP server), so=20 in general what you proposed wouldn't work. Picking this number is a=20 balance between JMAP server re-doing the work and the server picking up=20 external changes that might happen externally. Best Regards, Alexey From nobody Mon Oct 11 04:07:04 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 9B8C83A0D4B; Mon, 11 Oct 2021 04:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QW8kEFCy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0GimeO+Y 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 BJY64OEeoGoN; Mon, 11 Oct 2021 04:06:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795813A0D45; Mon, 11 Oct 2021 04:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2714; q=dns/txt; s=iport; t=1633950392; x=1635159992; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+9ynF2EcJjT1qMNoOrDe6pVSQJTSmy8VMpEUi7/Ucmo=; b=QW8kEFCyjZKS/8RW8yMMAJkFpW9aM3GyNmzURqlXdpDLGl/HREHVDmhO dVqlsaBydcmYZ5rG9KCD9OksvUpziCW8GathggoC3k/jslAC52ELPRSig XocmaAGFRB33EpRFDGkn7BO3TfC6Sk9BwdNgA57UorPnYtZz+UjqrPHwK A=; IronPort-PHdr: =?us-ascii?q?A9a23=3A6mcO3hXX7LlvSz5C5m6IQ4/X953V8K3gAWYlg?= =?us-ascii?q?6HPw5pPaaOv8tLpO0mMrflujVqcW4Ld5roEjufNqKnvVCQG5orJq3ENdpFAF?= =?us-ascii?q?npnwcUblgAtGoiJXEv8KvO5bjc9EMkEX1hgrDm3NEFPE5P4YFvf6nS58T8VH?= =?us-ascii?q?ED5Mgx4buT4E4LflYK5zee3rpbSeA5PwjG6ZOAaEQ=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AkUDyTq6FWOX+PR3N9cUFEwxRtLDFchMFZxGqf?= =?us-ascii?q?qrLsTDasY5as4F+vmIeD23SO66KYmH9f493bo3j/EMF65CGzd5jSQBp+Ss3Z?= =?us-ascii?q?n8b8sCt6fZ1gavT04J+FiBIJa5ex512huLocYZkExcwmj/3auK49CEljPnRL?= =?us-ascii?q?lbBILes1h5ZFFcMpBgJ0XqPq8Zh6mJZqYDR7zGl4LsekOWHULOR4AOYB0pPg?= =?us-ascii?q?061RLyDi9yp0N8QlgRWifmmJzYynVFNZH4UDfnZw3cV3uBp8uCGq+brlNlV/?= =?us-ascii?q?0vD9BsrT9iiiLu+LwsBQ6XZOk6FjX8+t6qK20cZ4HdtlPdgcqNBNy+7iB3R9?= =?us-ascii?q?zx14NhTpJq7SgoBNazXk+NbWB5de817Ff0bouOXeiHh7KR/yGWDKRMA2c5GB?= =?us-ascii?q?lsxO4Iw9O9sHWRH9PgEJTkIKBuEgoqewreyUsFti9gtas7xM+s3uHRp1XTSD?= =?us-ascii?q?f8nW4vrQqjW65lfxjhYrsxUFPjCIssUdTQqbhHJe1hUP1YSBbo/kfumwH7lf?= =?us-ascii?q?FVwqV+OqoI27nTdigtr39DFOd7YatGbA8BYmkCZpWXY12XiBR0XcteYzFK4H?= =?us-ascii?q?tiE7gPUtTnwVIRXH7qi+7s3xlaS3WcUThYRUDOGTTCCohbWc7pix4Y8qkLCd?= =?us-ascii?q?ZQPyXE=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AkOdW36O5UHlSUcBcT5f255DYdb4zR+YMi2?= =?us-ascii?q?TDiHoRdfUFSKKlfp6V88jzjSWE9wr4WBkb6Le90DHpewKeyXcH2/huAV7EZn?= =?us-ascii?q?ilhILIFvAj0WKG+V3d8kLFh5VgPMtbAs1D4ZjLfCRHZKXBkUyF+rQbsaO6Gc?= =?us-ascii?q?mT7I+0pRoAPGIaCZ2IrT0JdzpzeXcGIjWucKBJbKZ0kfA33gZIF05nCviTNz?= =?us-ascii?q?0gZazuttfLnJXpbVotHBg88jSDijuu9frTDwWY9g12aUIK/Z4StUz+1yDp7K?= =?us-ascii?q?SqtP+2jjXG0XXI0phQkNz9jvNeGc23jNQPIDmEsHfuWG0hYczFgNkGmpD21L?= =?us-ascii?q?8YqqiWn/7mBbUo15rlRBDtnfIq4Xi87N9h0Q6/9bbSuwqTnSWwfkNLNyMGv/?= =?us-ascii?q?MHTvMcgHBQ7e2VF8lwrjykXtNsfGH9dG6W3am6azh60kWzunYsiugVkjhWVp?= =?us-ascii?q?YfcqZYqcgF8FpSC4poJlO31GkLKpglMCjn3ocaTbpaVQGugkB/hNi3GngjFB?= =?us-ascii?q?aPRUYP/sSTzjhNhXh8i08V3tYWkHsM/I80D8As3ZWLDo140LVVCsMGZ6N0A+?= =?us-ascii?q?kMBcOxF2zWWBrJdGafO07uGq0LM2/E75T3/LI27ue3f4Fg9up8pL3RFFdD8W?= =?us-ascii?q?IicUPnDsODmJVN7xDWWW24GS/gz8lPjqIJ8YEUhICbeRFrbWpe0vdIj89vdv?= =?us-ascii?q?EzaszDca6+WcWTWFcGMbw5qDHDZw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAABJGmRh/5xdJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUUHAQELAYFQUQeBUTcxhEeDRwOEWWCICwOBKZlGgS6BJQN?= =?us-ascii?q?UCwEBAQ0BAUEEAQGEfgIXgjECJTQJDgECBAEBARIBAQUBAQECAQYEgREThWg?= =?us-ascii?q?NhkMBAQEDDgQREQwBASMUAQ8CAQgYAgImAgICMBUFCwIEAQ0FFgyCT4JWAy8?= =?us-ascii?q?BoEcBgToCih96gTGBAYIIAQEGBASFChiCNQmBECoBgwKEFYJUIoN9JxyBSUS?= =?us-ascii?q?BFSccgmc+hC0YF4MBN4Iui29lBEt5FH11A5FOg0OWRZIqCoMwnmwFLINqi2y?= =?us-ascii?q?XQYU9kGigUYR2AgQCBAUCDgEBBjWBLDuBWXAVZQGCPlEZD44gDBaDUIpedDg?= =?us-ascii?q?CBgEKAQEDCQGCOo8UKoE/XQEB?= X-IronPort-AV: E=Sophos;i="5.85,364,1624320000"; d="scan'208";a="852483165" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Oct 2021 11:06:23 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 19BB6Ni3019513 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 11 Oct 2021 11:06:23 GMT Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 11 Oct 2021 06:06:23 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 11 Oct 2021 07:06:22 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 11 Oct 2021 06:06:22 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XBQRjuu56tvUccnVhYIMcV1LCQbd0aB/+nhFQrDnFaXUn6i8X3l4ES4HBuJXtq1wz7T6VAFbTZw/60gDPI7InpQSqGRM6HLGBB5ETTbaR5OTZ0ZQVha8aUFHyoEesON6IHL+zPG6/r25GJUi2mNkh8BFU0YLUq4kYkutVE3PNJhMlO5A92xWVAQA8D3ncLi57RCH4rGRsf2W2kF0rPZLipWvkr1Jx9kEWIU47OApZ82My+M0GtMJU5/ubz5rc6zPX3Itw5ozbZ+3AKW9NsHUS+078myfLmRyU/sTgYfoXI/DBBaiF+Mra4bKyZmBN6nVevGzbxhtTm3nYslD7E2Ohg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+9ynF2EcJjT1qMNoOrDe6pVSQJTSmy8VMpEUi7/Ucmo=; b=c+SIfATCcvz8GvOFBghzhAEaDAPEXsJIwvrYWW1L6rKiBWvbr6g/5z0/ioCuGWS4M++eIE0UXwKCgkXETfA70atP2IGKWwIsZ3re0ltpPN+pV5WuII153V2Pg/EXYFZlrn93D2A+rL+wiMzN6FGQ1vxQKuOfgdxO9UAEC7pKjGQAhUc9okZqGMkZFcJGLr8qJ9+XevF1dvMT12QKI+ChVJs83sid3zNW8Skf0ZsqiCF44r5laGuLOOQbY/ny1q/h9TU7IZW4MEViTtF6st8FNKI6Zfql/CaBB2RTEla7sCWubRVQnlQ3OYStN+TYUxYL5cbBvwJRRZddKuWyBUph+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+9ynF2EcJjT1qMNoOrDe6pVSQJTSmy8VMpEUi7/Ucmo=; b=0GimeO+YOgmsfDlE10aImSN2RcsfoT2qdXIVTLwAUJN0rYlSlK4sze+AFSl/GN/qG5g6g/ULBnYKxltZHhtphPCYlLmk5XJ1kNofGNxywu6VWpkqFJ3X12pk1MbR2iuEMNnGTUqa66YYLUHWBD2tFLQDUjd8w6/k7igt5SWBbgs= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4887.namprd11.prod.outlook.com (2603:10b6:510:30::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Mon, 11 Oct 2021 11:06:21 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::fd55:3032:c8df:edad]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::fd55:3032:c8df:edad%3]) with mapi id 15.20.4587.026; Mon, 11 Oct 2021 11:06:21 +0000 From: "Eric Vyncke (evyncke)" To: Alexey Melnikov , The IESG CC: "draft-ietf-jmap-smime@ietf.org" , "jmap-chairs@ietf.org" , "jmap@ietf.org" , "brong@fastmailteam.com" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtam1h?= =?utf-8?Q?p-smime-09:_(with_COMMENT)?= Thread-Index: AQHXvodCUBL4SEBuskiBSKuobbcdR6vNne6AgAAmlAA= Date: Mon, 11 Oct 2021 11:06:21 +0000 Message-ID: References: <163394659178.16379.4322542081082229915@ietfa.amsl.com> <1b4bad6a-c1ad-80a3-10ac-301685a77ecd@isode.com> In-Reply-To: <1b4bad6a-c1ad-80a3-10ac-301685a77ecd@isode.com> Accept-Language: fr-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 authentication-results: isode.com; dkim=none (message not signed) header.d=none;isode.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 75147a9d-8989-4d61-5d4e-08d98ca72845 x-ms-traffictypediagnostic: PH0PR11MB4887: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PCUKet6MZb5PcK2JhytJMJxFc7vSrC8xDF/MZh+gknpz+CVCOEQZa7TyFxBZrrMhDeVrHpvTikZNq1Wd818wuoWr8aEX53V1uND62/jNeUaOl2q2GdxUuNOCbvUXvbHRdBYK+PsZ2YuttTOd4jfUhjO/QxnXI2YVJaSxpEGlxq1/+9zV0G99evSFIwB80ktQ/IpOrXTW5Ju7uezi3H/IewxzZds9H5KnlLvQBR1bE8ldRgAJJPoaPjMDdDQPPRcsQsqPR0VG9NacgxFYt7K0yXLl3e0Ds+IJ6qQMqzuLo576BIEPJffGP8hQpO2sDONpEK0h8gSqW67RssC+HmMvLYrJ8CJTgghqK69fgVET+K5pJTfz+z9iZH8PK01fq2t/SC57NepACJxCHKS0dsg+whoaxU+o7G/se2hzKrm0srJ48JeES0smjKGZwqxflHdJ7O2BM4T+2tjGhQfCS0Shgbz8002aVnSU5EfPitQCu/VuPlu+GzNsaESGCAWwAHmNxLjX4pG6g00750Hbre3dFh2xr32WPW2+r5Ij/A7OD5U+8h7OCOgH8tb5rZFvjYV8wRy6g/S0sG0wk1WCxtcZeCbLrubZVT0fk+HXzwu7U/MLAei6eJhPcvfd77KR6mKvRSBh7Rg3eXinvoDYDv2LeW8HjX1LiyO3D6B0vpnWILd6tGRQMOXj3pK7I1MLM+3MPSUEqZ8ibxuPySV/YwMjKr2b3Stdb8RcHDAyTTNZeq6Cr1xpwM4rMTWv5Fvtsxa9 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(5660300002)(91956017)(66476007)(86362001)(66446008)(33656002)(76116006)(64756008)(2616005)(66946007)(122000001)(6512007)(38100700002)(66556008)(54906003)(508600001)(4326008)(224303003)(110136005)(38070700005)(186003)(83380400001)(36756003)(316002)(6486002)(71200400001)(53546011)(8936002)(6506007)(2906002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dHlUOXZzbmltcDRyRkJ5dWJFS0Z2UDhPZGRyd2N2TjlsWVh2OEgvT2tadEhq?= =?utf-8?B?bk8yTlNEc2kycnVUNGdsM2xienlUam9VNUhuODU2ajdydUprRDQ1dndDYVRH?= =?utf-8?B?NGNZZExGenFGRXJGdWlIL0FqYjNqeWhhL2xCckFVanMwM3piUEx2RlJaNFBM?= =?utf-8?B?QjFIcCtYQUVMdW9ZcGFjOEtlUGNlK2tvVTcrekZPOGRmYk0vQ1JVK3F2UVor?= =?utf-8?B?NzI2V3BKcTc3cWlTSEVsdjdyMkdnbjdwZmJZdnllQ2ZwN2ttdGljVDg2SmR6?= =?utf-8?B?em90d2JMSy82TU1SbFhJSTlGR1FGbUU4M21qM2JhTDJqYm1NVVVkbWZCRm82?= =?utf-8?B?cHRwWmpVNmt1THhlcDVGK3ZMbWhKQUFpQkxDWElHem1tSCtKelRpRUZUTXFn?= =?utf-8?B?dUFsVDdjWDZOSExsZ282cU1PTTRZR2x0OGE1dW5nbWcwTGRmY0wyTStyeXdN?= =?utf-8?B?L2tVRkcvZVhFeXQ3U1ArbkZ2WWVTWklZU1JESFVGcERIZGNJalBBc0lUQmgx?= =?utf-8?B?OWRNQ2N2d0lBY0ZlOGtFeE92Q3RiYlR1OFhnYmxPdGM2bHh2SlhJM2RGdEp2?= =?utf-8?B?YVE2NmJ3RXNuY1o3Mm1NZXl6RU5BT01KcFg5dnlRK05mQUR3N3V3NEtoTEJT?= =?utf-8?B?b09QN0dCNkhNVTB5OGdSS2p3dEJNWmIzRVhWWnVlbXhuVEhPeFhjcHc3UWJU?= =?utf-8?B?TzE0bXppTU1ENUJORHBTYmdZTk1iY1Y3b0xJdkQvbG5ySG0rdFZTbGovT1VR?= =?utf-8?B?R3lPbDZhL3hHb3MxTXJjY2hoVFhkTTh5TjhVMGFWV3o2TXBOVkRhMy9sQVZy?= =?utf-8?B?SWI0Z2JDUXVZaUtMNnRwaUtuV0lDRFZKUmk5bzJFREFvWG5jdm50RHlkZnAy?= =?utf-8?B?OEJEb2grbS9TdkpXTm44S2VRSVpJVlZtMjAxMnpwREJvRlhwVXp0YlphMFBK?= =?utf-8?B?dXc2aHdNRi83aitkSlFYb1NNQWFkb1NJemlHNjZDd09RU2FnWENkUEJyVU1l?= =?utf-8?B?aWh0bDU2N2wwUXlvQysxOUVWRDQwWlZhQmpzZ2orWHVhOVR4TjNxZHJhUEhS?= =?utf-8?B?eVpHZWFSWG5DUjk1ZjA5SHBkSWtSVWh4RlRwQ0ZqMWxzalF3NE1oODE4c1Jn?= =?utf-8?B?T1c0RjQxRXUzbHJ6cVl4RURldERXNjQzbHkyVEpsQUkvS3hIWUFROHhRdTda?= =?utf-8?B?RGVPSkYwWVY4SWhFOHNRb1RCMmNiUkNlTm95eEhVTWZWb2htWDI0N2JuZ0hk?= =?utf-8?B?MFVoL3pxZFhsakwwcGc1Q2YzYk9Pb1lONlFPbC9JZ3drS3dsYlhVQmVzNDVm?= =?utf-8?B?YS9JMlV3ME5QdlVHMnpRT0JEVDVSeTluS1h3TG0yeDAzMzlTVXBPUC93TXM2?= =?utf-8?B?c09MWFBBdWNDOWtHMkVOUjAzWGRMaExmYUsyN1lpL3c5NEpZNWc0YjVuT3pI?= =?utf-8?B?MzIza3NkNE1EVEpXWWpJcDJLL2FYeTFZeXJteGVOT2p5b3lzdzY2b1V5UERt?= =?utf-8?B?Y3NRK28waytpQlFJcUplaEVSNDR1bXlMWWZVTFl4YURDTUJsdER5Q1plWk1s?= =?utf-8?B?NmRMTFBoV0ZwQ2JpWkhxbUc4OUdkaDA2TGZEeFFUdHM2NEMrZ2l1Q1E2MURP?= =?utf-8?B?d3puNmdINEhyODdWOSttem9McWh2NXR6aFVnM3djNHJHV3ViRTVjUzF1Y05P?= =?utf-8?B?aVVYY2ZOOXhjdU1CZ2tjZEdwVytwR2R3bjhwTGJ5NXhzd1c2K29IYTE2SE5I?= =?utf-8?B?aENLQi9nNEdmRUNOM2V4b1lBaWlxbzRPdHd3T0tFQ09TeHh2Z1VrRHRNU1JE?= =?utf-8?B?L1ZGSno1b24yekIrTGZGYXhNc2pibmhyOE16OWFIUjY2YUVmRW8xYkdvVTZp?= =?utf-8?B?d2FjemxMVTd3QmIwbEVObk8wOWswWDhjZTkzZzJpMGFtTWc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 75147a9d-8989-4d61-5d4e-08d98ca72845 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2021 11:06:21.1034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tB+5neOMySwKhso7H9vW3vpOKdSY+hIy47mI/Vrpvo+W7RD2ZmlXWObjWvUMnNda4k8wjtuQJLqlg+delfjIZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4887 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Jmap] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-jmap-smime-09=3A_=28with_COMMENT=29?= 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, 11 Oct 2021 11:06:39 -0000 VGhhbmsgeW91LCBBbGV4ZXksIGZvciB0aGUgcXVpY2sgcmVwbHkuDQoNCkFib3V0IHRoZSAybmQg Y29tbWVudCwgeW91IGFyZSByaWdodCBhcyBJIGRpZCBub3QgdGhpbmsgYWJvdXQgYSBjZXJ0aWZp Y2F0ZSBpbiB0aGUgbWlkZGxlIG9mIGEgY2VydCBjaGFpbi4NCg0KUmVnYXJkcw0KDQotw6lyaWMN Cg0K77u/T24gMTEvMTAvMjAyMSwgMTI6NDgsICJBbGV4ZXkgTWVsbmlrb3YiIDxhbGV4ZXkubWVs bmlrb3ZAaXNvZGUuY29tPiB3cm90ZToNCg0KICAgIEhpIMOJcmljLA0KDQogICAgVGhhbmsgeW91 IGZvciB5b3VyIGNvbW1lbnRzIQ0KDQogICAgT24gMTEvMTAvMjAyMSAxMTowMywgw4lyaWMgVnlu Y2tlIHZpYSBEYXRhdHJhY2tlciB3cm90ZToNCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IENP TU1FTlQ6DQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPg0KICAgID4gVGhhbmsgeW91IGZvciB0 aGUgd29yayBwdXQgaW50byB0aGlzIGRvY3VtZW50Lg0KICAgID4NCiAgICA+IFBsZWFzZSBmaW5k IGJlbG93IHNvbWUgbm9uLWJsb2NraW5nIENPTU1FTlQgcG9pbnRzIChidXQgcmVwbGllcyB3b3Vs ZCBiZQ0KICAgID4gYXBwcmVjaWF0ZWQgZXZlbiBpZiBvbmx5IGZvciBteSBvd24gZWR1Y2F0aW9u KS4NCiAgICA+DQogICAgPiBTcGVjaWFsIHRoYW5rcyB0byBCcm9uIEdvbmR3YW5hIGZvciBoaXMg c2hlcGhlcmQncyB3cml0ZS11cCAgYWJvdXQgdGhlIFdHDQogICAgPiBjb25zZW5zdXMuDQogICAg Pg0KICAgID4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyB0byBpbXByb3ZlIHRoZSBkb2N1bWVudCwN CiAgICA+DQogICAgPiBSZWdhcmRzLA0KICAgID4NCiAgICA+IC3DqXJpYw0KICAgID4NCiAgICA+ IC0tIFNlY3Rpb24gNC4xIC0tDQogICAgPg0KICAgID4gSSBjYW5ub3QgcGFyc2UgdGhlIHNlbnRl bmNlIGJlbG93LCBwcm9iYWJseSBiZWNhdXNlIG9mIG1pc3NpbmcgcXVvdGVzIG9yDQogICAgPiBw dW5jdHVhdGlvbjoNCiAgICA+ICAgICAgICAgIHNtaW1lU3RhdHVzOiAiU3RyaW5nfG51bGwiLiBu dWxsIHNpZ25pZmllcyB0aGF0IHRoZSBtZXNzYWdlIGRvZXNuJ3QNCiAgICA+IFN1Z2dlc3QgdG8g cmVwbGFjZSB3aXRoDQogICAgPiAgICAgICAgICBzbWltZVN0YXR1czogIlN0cmluZ3xudWxsIi4g QSBzbWltZVN0YXR1cyB2YWx1ZSBvZiAibnVsbCIgc2lnbmlmaWVzDQogICAgPiAgICAgICAgICB0 aGF0IHRoZSBtZXNzYWdlIGRvZXNuJ3QNCiAgICBPay4NCiAgICA+IC0tIFNlY3Rpb24gNiAtLQ0K ICAgID4NCiAgICA+IEp1c3Qgd29uZGVyaW5nIGFib3V0IHRoZSBjYWNoZSBmb3IgMTAgbWludXRl cyBvbmx5Li4uIFRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24NCiAgICA+IHRvIGJlIHN0b3JlZCBz ZWVtcyB2ZXJ5IGxpdHRsZSBzbyB0aGUgc2lnbmF0dXJlIHN0YXR1cyBzaG91bGQgYmUga2VwdCB1 bnRpbCB0aGUNCiAgICA+IHRydXN0IGFuY2hvcnMgYXJlIG1vZGlmaWVkLg0KDQogICAgSXQgaXMg bW9yZSBjb21wbGljYXRlZCB0aGFuIHRoYXQuIE9uZSBvZiB0aGUgdW5kZXJseWluZyBjZXJ0aWZp Y2F0ZXMgDQogICAgbWlnaHQgZ2V0IHJldm9rZWQgKHdoaWNoIGlzIG91dHNpZGUgb2YgY29udHJv bCBvZiB0aGUgSk1BUCBzZXJ2ZXIpLCBzbyANCiAgICBpbiBnZW5lcmFsIHdoYXQgeW91IHByb3Bv c2VkIHdvdWxkbid0IHdvcmsuIFBpY2tpbmcgdGhpcyBudW1iZXIgaXMgYSANCiAgICBiYWxhbmNl IGJldHdlZW4gSk1BUCBzZXJ2ZXIgcmUtZG9pbmcgdGhlIHdvcmsgYW5kIHRoZSBzZXJ2ZXIgcGlj a2luZyB1cCANCiAgICBleHRlcm5hbCBjaGFuZ2VzIHRoYXQgbWlnaHQgaGFwcGVuIGV4dGVybmFs bHkuDQoNCiAgICBCZXN0IFJlZ2FyZHMsDQoNCiAgICBBbGV4ZXkNCg0KDQo= From nobody Mon Oct 11 04:28:28 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 522873A0E45; Mon, 11 Oct 2021 04:28:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com, brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <163395169066.1176.11296212131462393643@ietfa.amsl.com> Date: Mon, 11 Oct 2021 04:28:11 -0700 Archived-At: Subject: [Jmap] Lars Eggert's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) 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, 11 Oct 2021 11:28:12 -0000 Lars Eggert 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: ---------------------------------------------------------------------- Section 6. , paragraph 3, comment: > Constant recalculation of S/MIME signature status can result in a > Denial-of-Service condition. For that reason, it is RECOMMENDED to > cache results of signature verification for 10 minutes. Agree with the motivation to cache, but 10 minutes seems pretty arbitrary. Could a sentence be added giving a bit of context? ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 4.1. , paragraph 13, nit: > ignature. (I.e., this property is non null only when the corresponding "smime > ^^^^^^^^ This expression is usually spelled with a hyphen. Section 4.1. , paragraph 13, nit: > Each string in the array is a human readable description (in the language sp > ^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 4.1. , paragraph 14, nit: > (See Section 3.8 of [RFC8620] in regards to how this is affected by the lan > ^^^^^^^^^^^^^ Use "in regard to", "with regard to", or more simply "regarding". Section 4.1. , paragraph 15, nit: > s response property to be set to a non null value, if an S/MIME signature exi > ^^^^^^^^ This expression is usually spelled with a hyphen. From nobody Mon Oct 11 04:28:48 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 B20EA3A0E32; Mon, 11 Oct 2021 04:28:39 -0700 (PDT) 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=eggert.org 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 s6pBtyifVj9x; Mon, 11 Oct 2021 04:28:34 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 428D13A0E52; Mon, 11 Oct 2021 04:28:34 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:a867:7af:b73f:3db4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 884B9600A84; Mon, 11 Oct 2021 14:28:25 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1633951705; bh=1qkR0T8jxySox6q+k5a5BTGmu2xalmBCwLUZBxojG7U=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=kXtm15Q7qXkEi7TgfsTCC/BojevAPV/SRZeucFiK7DJQHoPhoZ+CRDIpnbWGS1cvV bAN41KRUSXWlK7KQMNw1+Sn55KOovarLPqrPQPjNPNTUJw4RkE86dFF8oF+6kZdVAt sB1Ypt6G7k57ZcfD+msmB0LYpuw8A1Tdb7nkSTcI= From: Lars Eggert Message-Id: <74858DC6-7891-43C5-97FA-B6A978203E63@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_85597FB2-47A7-4F83-A9C2-193D0E26E9CD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 11 Oct 2021 14:28:24 +0300 In-Reply-To: <163099800356.27114.17325354179624408978@ietfa.amsl.com> Cc: gen-art@ietf.org, jmap@ietf.org, draft-ietf-jmap-smime.all@ietf.org, last-call@ietf.org To: Peter Yee References: <163099800356.27114.17325354179624408978@ietfa.amsl.com> X-MailScanner-ID: 884B9600A84.A235A X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Jmap] [Last-Call] Genart last call review of draft-ietf-jmap-smime-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, 11 Oct 2021 11:28:40 -0000 --Apple-Mail=_85597FB2-47A7-4F83-A9C2-193D0E26E9CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Peter, thank you for your review. I have entered a No Objection ballot = for this document. Lars > On 2021-9-7, at 10:00, Peter Yee via Datatracker = wrote: >=20 > Reviewer: Peter Yee > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-jmap-smime-07 > Reviewer: Peter Yee > Review Date: 2021-09-06 > IETF LC End Date: 2021-09-06 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This document provides a JMAP extension that allows the JMAP = server to > provide its thoughts on the verification of a messages S/MIME = signature. While > the details of the extension seem fine, I'm not convinced that the = rationale > for it and the consequences of trusting the server to perform the = verification > are well described. [Ready with issues] >=20 > Major issues: None >=20 > Minor issues: >=20 > Page 2, section 1: There really ought to be a description of why a = client would > want to do this and why it would trust the results. This is taking a = decision > on something that is normally an end-to-end property of a message and > delegating its verification to a server. Is signature verification so = onerous? >=20 > Page 4, smimeErrors, 3rd sentence: the error may also be in the = certificate > chain. >=20 > Page 5 and 6 examples: Put an introduction before each example so the = reader > knows that it is an example and what it intends to show. >=20 > Page 7, section 6: I think a stronger description of the implications = of doing > server-side verification is merited. The document is written as though = it is a > forgone conclusion that a client would want to do this without much = explanation. >=20 > Nits/editorial comments: >=20 > General: >=20 > The use of asterisks and underscores for emphasis or for offsetting = various > items is not explained. The usage is also inconsistent. I note that = RFC 8621 > does some of this as well, but I think it would be preferable to = abstain from > extravagant use of these characters unless their significance is = explained. > Sometimes items are marked with asterisks, other times with quotation = marks. I > find it all rather off-putting and could not find anything in the RFC = Editor's > Style Guide indicating a standardized meaning for the characters. >=20 > Do not put a colon after the title of each example (e.g., "Example = 1:") >=20 > Specific: >=20 > Page 2, section 1, 2nd paragraph: insert "the" before = "multipart/signed media" > and "application/pkcs7-mime". >=20 > Page 2, section 3, 1st sentence: change "the JMAP spec" to = "[RFC8621]". This > obviates the need to use underscores around the following "this". >=20 > Page 3, section 4, 1st paragraph, 1st sentence: insert "the" before = "Email/get". >=20 > Page 3, *smimeStatus*: insert "the" before the final '"smimeStatus"'. >=20 > Page 3, *smimeErrors*: insert "the" before the final '"smimeErrors"'. >=20 > Page 3, *smimeVerifiedAt*: insert "the" before the final = '"smimeVerifiedAt"'. >=20 > Page 3, *smimeStatusAtDelivery*, 1st sentence: insert "the" before the = final > '"smimeStatusAtDelivery"'. >=20 > Page 3, *smimeStatusAtDelivery*, 2nd sentence: insert "is" before = "effectively > ". Insert "the" before '"smimeStatus"'. Change "deliver" to = "delivery". >=20 > Page 3, smimeStatus, 2nd real sentence: change "This" to "Otherwise, = this". >=20 > Page 3, smimeStatus, 4th real sentence: change "Client" to "Clients". >=20 > Page 3, smimeStatus, unknown, 1st sentence: delete the comma after = "signed". >=20 > Page 3, smimeStatus, unknown, 2nd sentence: insert "an" before = "unknown". >=20 > Page 3, smimeStatus, signed, 2nd sentence: insert "a" before = "signature". >=20 > Page 3, smimeStatus, signed/verified: insert "the" before "sender = matches". > Append a comma after "field". >=20 > Page 4, 1st non-status paragraph, 1st sentence: delete the comma after > '"smimeStatus"'. Insert "is" before "calculated". >=20 > Page 4, 1st non-status paragraph, 2nd sentence: insert "the" before = "S/MIME". > Change "it helps to" to "to help". >=20 > Page 4, smimeErrors, 1st sentence: insert "the" before "S/MIME". >=20 > Page 4, smimeErrors, 2nd sentence: append a comma after "I.e.". >=20 > Page 4, smimeErrors, 3rd sentence: insert "the" before = "Content-Language ". >=20 > Page 4, smimeErrors, 6th sentence: insert "a" before "CRL". >=20 > Page 4, smimeVerifiedAt, 2nd sentence: insert "the" before "S/MIME". >=20 > Page 4, smimeVerifiedAt, 3rd sentence: insert "an" before "S/MIME". >=20 > Page 4, last paragraph, 1st sentence: change "it's" to "its". >=20 > Page 5, 1st paragraph: append a comma after "server". >=20 > Page 6, 1st paragraph after Example 2, 1st sentence: insert "the" = before > "Email/query". >=20 > Page 7, section 6, 1st paragraph, 1st sentence: change "Server side" = to > "Server-side". Insert "the" before "server". >=20 > Page 7, section 6, 2nd paragraph, 1st sentence: insert "a" before = "Denial". >=20 > Page 7, section 6, 2nd paragraph, 2nd sentence: append a comma after = "reason". >=20 >=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_85597FB2-47A7-4F83-A9C2-193D0E26E9CD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmFkH9gACgkQVLXDCb9w wVcw+xAAotlMooXBJSP+bUYu/D6O6LTL69T+I2rcnz+BwqwRndtagFts8SxGGtag LbKOzB348rIdgm7xQVvMaFKpfVit/TwltBxI3T99IabzXaUH1/fNoOpi9ty+hpFS VDs36c3XwhJP9jcIJQWCzeO3RtiFDbPNwVrY8t1rcXBNTR/9e+f2P0et8570CfmQ /A3L1sZXzw+ZC2qTayGU5FuCDs3LLRK0Glh/PUy3IFtM3kSqP94LyZ+ANoc7vQNW QL3mbuKJSMyL0JgQzvnjsWe6kvYKvHV3LQdoJwRMxnvVxGd3qLs3twwfklnMcSgF cvc9PgVutnFygU8yVSVwaJbNgbuqY+1eVVbHa/cqme+3ju4CMBso4scvX2F1CTYU WR33hLnbd1VDhb67wdAeszUdRAlq/4RRfbiWScqwhjXdmcjMeLa7ARu1JQn/Bv0K Nk1FPy2hD0OublKpZKd6hydMnhYd9ikmU6J9ZfXyh1v+4Yo9D8CLUW1h3AosTTF4 2uYixggDOwWBSNz6wqLu6uGb9ZNrBXxZk8H7CGnQEUDHHbGXqNhFHxKw6KpgZil0 gkvldmOFi1e2511g/8suheiVc0y/wCEetYni/kCf4rM8x4pzLQ5b6Ljum6UDCPh+ wslAfXKAha5Mo29Z6410WEThSkIpLZwjY0+mG670P71Y0rbUcAY= =3IO5 -----END PGP SIGNATURE----- --Apple-Mail=_85597FB2-47A7-4F83-A9C2-193D0E26E9CD-- From nobody Tue Oct 12 19:16:32 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 E25BE3A0B52 for ; Tue, 12 Oct 2021 19:16:29 -0700 (PDT) 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=tgVyv4nc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XjA5XxfN 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 p2Y0IKty4TcK for ; Tue, 12 Oct 2021 19:16:24 -0700 (PDT) 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 360E23A0B45 for ; Tue, 12 Oct 2021 19:16:24 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A6A043200E8E for ; Tue, 12 Oct 2021 22:16:23 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Tue, 12 Oct 2021 22:16:23 -0400 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=fm3; bh=LZJl+2e qn1agwoFsz/bXCOTEIPdywnvBSFgQ11yB19c=; b=tgVyv4ncqSOzt1Rv+f6WcXH e3C/k9ZYe6Qm0cMRzVpEisacGY5ou09q5U+fjaopv59ztyC5UFpSEPHkdzRmbPMD 7QVjIaELoPrVwhwaJegU11WLy5XD2gYuNtRm9rkmElcF4kwHtfbiAaMLIxSl4YaF 8T10VnxDRRtDntgalkS5qLPh+g5Ie3a9t8WIqricyFRddXxakeZsA1B3/Z8dwQRJ Z9CH2dBb9ETUo3nC1blXfPN+ZqjQTrlIFI6H333uuNWXemf1a6KCr6sRBG46hkS+ swnRA6IVB2qu8IsmBrchTLrit4KkPU5MUrNKvXgA0AgsmbxTOAoRNgNgNu14W+g= = 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=LZJl+2 eqn1agwoFsz/bXCOTEIPdywnvBSFgQ11yB19c=; b=XjA5XxfNUljax6CIGJv543 1m6V8ELgWLBiZzDnScb8GnU6xML3oj1F5m3RpjNJ7sHMNZjfJxc+uAdPvn5yWYsD hmHU7SZmuTXe3k2DGwmxTekLLw2BLkg0Ql3izqH2gC29Hy5LuZMDUgpucSFN9NJa IXmcffgfDcueYl8cCHYVGLaLuexLKYNJZIECE0ge6Ucx7op/f8oGSpBYnqItybbM mYryJE+YhdgPXGFp/AUAS/h/tNmm0cYLi8ufqmNf5lSYYeBvOjx2qCswtCAj1eBh IC6jbBmoxVJ05/Lfv/A4hQY2QB/8fS0RfHvLB96r5yTCy1FkM3SkRR4gr1FqbR+A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtledgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeehuefhudejtdeiveekvdfhfffgleeflefhfeekhefhkeel kefhfeeufeevffejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 04D0DAC0380; Tue, 12 Oct 2021 22:16:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1345-g8441cd7852-fm-20211006.001-g8441cd78 Mime-Version: 1.0 Message-Id: In-Reply-To: <50b210f0-f3c7-41b5-a26d-e308eea91299@dogfood.fastmail.com> References: <50b210f0-f3c7-41b5-a26d-e308eea91299@dogfood.fastmail.com> Date: Wed, 13 Oct 2021 13:16:22 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=7b71af7283174732b0a2b9e562f31623 Archived-At: Subject: Re: [Jmap] Blob draft question: type vs datatype 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, 13 Oct 2021 02:16:30 -0000 --7b71af7283174732b0a2b9e562f31623 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable I would lean towards `typeName` for this. =E2=80=94Neil --7b71af7283174732b0a2b9e562f31623 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
I wou= ld lean towards typeName for this.
<= /div>

=E2= =80=94Neil
--7b71af7283174732b0a2b9e562f31623-- From nobody Fri Oct 15 15:39:41 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 8E4D43A0DDD; Fri, 15 Oct 2021 15:33:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: jmap@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433723752.17026.8053909313819027649@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:33:57 -0700 Archived-At: Subject: [Jmap] jmap - Requested session has been scheduled for IETF 112 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: Fri, 15 Oct 2021 22:34:00 -0000 Dear Jim Fenton, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jmap Session 1 (2:00 requested) Tuesday, 9 November 2021, Session I 1200-1400 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/jmap.ics Request Information: --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Jim Fenton Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 20 Conflicts to Avoid: People who must be present: Alexey Melnikov Bron Gondwana Hans-Jorg Happel Jim Fenton Joris Baum Kenneth Murchison Mario Loffredo Michael Douglass Murray Kucherawy Neil Jenkins Rene Cordier Robert Stepanek Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 16 04:55:25 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 4D5503A1581; Sat, 16 Oct 2021 04:53:43 -0700 (PDT) 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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163438522318.13524.11641089830060231298@ietfa.amsl.com> Date: Sat, 16 Oct 2021 04:53:43 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-blob-03.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: Sat, 16 Oct 2021 11:53:45 -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-03.txt Pages : 14 Date : 2021-10-16 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-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-blob-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 16 04:56:42 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 BF87F3A158A; Sat, 16 Oct 2021 04:55:53 -0700 (PDT) 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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163438535367.8199.11334909617914649151@ietfa.amsl.com> Date: Sat, 16 Oct 2021 04:55:53 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-blob-04.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: Sat, 16 Oct 2021 11:55: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 : JMAP Blob management extension Author : Bron Gondwana Filename : draft-ietf-jmap-blob-04.txt Pages : 15 Date : 2021-10-16 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-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-blob-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 16 05:09:36 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 364FE3A15FB for ; Sat, 16 Oct 2021 05:09:34 -0700 (PDT) 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=ODDeWKZ+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hbQiI2Lm 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 e6NEo81RLXXN for ; Sat, 16 Oct 2021 05:09:28 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37993A15FA for ; Sat, 16 Oct 2021 05:09:28 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 202D13200E86 for ; Sat, 16 Oct 2021 08:09:24 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Sat, 16 Oct 2021 08:09:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=T3nTJd3qDTrrKZNjFZaPAvcf/OsLoaEr9zyXvIT VZbQ=; b=ODDeWKZ+l56V+SZXm9Dwzs/JmblpIJqpN7WzLjtVM9EuW5jh1fQP6vH JDBZ1EzGrnUn9E8TEwaE+fX+/aOyMJg7RsaivYPhzJIbWPQHRV9+RaHGHsjO61hy EEtRlpEZJ/DN6+Wz+0LIyE9kbrol6oyBmPJZICjzPLtZNdi1Kq//9snSMVEHqDTS cgeGkX6o6S/qbzMG5EKPWMjEBeIRKo7N6ntoCjryU0iE+70Y0n9KihIcn2i6GOYq tUAjyelTKG2r/5fPujogJz+Yo+W7oPf5rs4w84DLgBsVB+SrjSVN+wIzbRu5/e18 Zqljmp/ZtgxWaX4yeNUE8RWeCEnJeeA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=T3nTJd3qDTrrKZNjFZaPAvcf/OsLo aEr9zyXvITVZbQ=; b=hbQiI2LmakjIyRc8i7JYrKGhlWRhP3/yPlLLtGscgumwA i9fpPG1yHpLL4l/MGzQbZQP+CsTCaJ6Am9eFVXzEiC+kUKy9c3bB9/IILRQRYwc2 tG/y3RmN7XJ0YC+QuPZDLPCaoTBa4+ZYBDA/G0Fxzlaev6ueaj/0N1BtKUvqi2QV V+mjRCGA0XORaNrJcHd480DBr4A/hAmHH4UpKKT8EErdOYYqnsrDUcZ3vlTJBXcf zmafDK414uXc5pJDY3Ew5+byH6OG99/Q1kJhxhxvmFTtvaCzldPxQTU85D341QO/ yXjQNa/kbAzIzi3rgGbaP+9p4Ni25azOz5wlQJvSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdduiedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefgvdeglefhteeige dtudefuedvffdtfeduueelhedviefgudfggedvjedvledtjeenucffohhmrghinhepghhi thhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 858E1AC0380; Sat, 16 Oct 2021 08:09:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1345-g8441cd7852-fm-20211006.001-g8441cd78 Mime-Version: 1.0 Message-Id: <119ef5f3-ad8d-4423-b019-38454a5be2b6@dogfood.fastmail.com> Date: Sat, 16 Oct 2021 23:09:02 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=d3a10cc333c04d5087222f22bd7ec755 Archived-At: Subject: [Jmap] Blob draft updates - please have a look at -04 before the interim 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: Sat, 16 Oct 2021 12:09:35 -0000 --d3a10cc333c04d5087222f22bd7ec755 Content-Type: text/plain Sorry for the two versions in quick succession! I realised I hadn't put anything in security considerations about virus checking blobs created by `catenate` the same way you might check blobs injected via `upload`. * * *I've just posted draft-ietf-jmap-blob-04, which resolves a bunch of issues:* * https://github.com/brong/draft-gondwana-jmap-blob/issues/1 * using `typeNames` in the request and `matchedIds` in the response for lookup * https://github.com/brong/draft-gondwana-jmap-blob/issues/2 * if `data:asText` is requested and the selected octet range is not valid utf-8, then we add an `isEncodingProblem: true` property like in RFC8621. * also, if the selected range can't be entirely satisfied (length past the end of the blob) we set an` isTruncated: true` property in the response. * https://github.com/brong/draft-gondwana-jmap-blob/issues/3 * added a `maxCatenateItems` capability field (suggested minimum 64) * https://github.com/brong/draft-gondwana-jmap-blob/issues/4 * added Security Considerations around scanning the resulting blobs created by Blob/set the same way you would scan uploads. *Yet again, I'm asking for your reviews!* This is all implemented in the Cyrus IMAP server at https://github.com/cyrusimap/cyrus-imapd/pull/3685 - which I'm planning to rebase and neaten up once we're happy with this draft, and ready to do a working group last call. We'll talk about it at the interim meeting with CalConnect next week, and I'm probably going to ask Jim for a working group last call after that unless there are any changes that people still want! Cheers, Bron. P.S. ... and yes, I probably WILL come back after this with yet another document or two for server-side-coding and server-side-digests, but that's different enough not to merge into this one! -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --d3a10cc333c04d5087222f22bd7ec755 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Sorry for the two versions in quick succession!  I re= alised I hadn't put anything in security considerations about virus chec= king blobs created by `catenate` the same way you might check blobs inje= cted via `upload`.

I've just posted draft-ietf-= jmap-blob-04, which resolves a bunch of issues:
Yet again, I'm asking for your reviews!

This is all implemented in the Cyrus IMAP server at https://github.com/cyrusi= map/cyrus-imapd/pull/3685 - which I'm planning to rebase and neaten = up once we're happy with this draft, and ready to do a working group las= t call.

We'll talk about it at the interim meeting with Cal= Connect next week, and I'm probably going to ask Jim for a working group= last call after that unless there are any changes that people still wan= t!

Cheers,
Bron.


=
P.S. ... and yes, I probably WILL come= back after this with yet another document or two for server-side-coding= and server-side-digests, but that's different enough not to merge into = this one! 


--
  Bron Gond= wana, CEO, Fastmail Pty Ltd
  bro= ng@fastmailteam.com


--d3a10cc333c04d5087222f22bd7ec755-- From nobody Sat Oct 16 05:23:55 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 38AA23A05D0 for ; Sat, 16 Oct 2021 05:23:51 -0700 (PDT) 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=vYON5U6u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eCSozlEf 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 jo7quRawPRW7 for ; Sat, 16 Oct 2021 05:23:45 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0343A05A4 for ; Sat, 16 Oct 2021 05:23:45 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id C4F233200A39 for ; Sat, 16 Oct 2021 08:23:44 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Sat, 16 Oct 2021 08:23:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=X8iUax0pPUClq0tLP6xlMqWnY7sAWYLQKkjK/hr vBrU=; b=vYON5U6uIYcaacPOPZjOHLRs8aN2E7GjMXY3dap7sSlY8dLtWjhsfCy RdW0Xirn13fhJRZcUAD8nOuy2uyRBQ3kgP1g+PCLXAWknTKA11462SvIhHO7DSXM Py8XuBPTc1kDCzNS0Oz7NmVsWVI3KWwhQgZ+BR4QuFeJhpA2ymDhAdAanbWTEFcy zVzeegAv8fSUEMVs7JD1mLFDudQYJbPs85QnXoTdNj/Z01lxV4Zbr5J4lNTzDZB1 BBH3cXbrl79DJ5u6I0x72KuuAaiPemt1x+BygMwU/QmDh2PVpghDdfMTy2Ug80aw NuQhE9csJs8yEXkCzZFAbJmb3q7nIvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=X8iUax0pPUClq0tLP6xlMqWnY7sAW YLQKkjK/hrvBrU=; b=eCSozlEfkvZW8kRSBDA4iYtJ86p0DuovPf+r4265Gyqi7 qoKjl1lOFBggC4eAUg8iRljMpotOmrLFv8phr7SpQ5KDHUX+NPO5vIB1sUfTB+/C E/pLbSqUROQqEo2eXK58YUDdoQU2FWyG+ABe+XdrPNm55SZQLzm34eDPclmbbgsl I2QvLMRLuoupjpq1iABOzFokWpOsDRJIQzMj1bMt5R42wPJ8+q9VTiG4KIA5v/Ze 3lTtP9FNZUYR3xZ5uJQPemZxTyksKnPF9D0q1K/OGIIcck1jbsVbzcJkz7JeK4XJ eHID73xt2CZQOdBEpWIONh8EBI8peXJm6y/vJjcqw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdduiedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhjeehkeejkeehve eutdejteeihffffeduiedttdejhfelteevueehudeltdeuffenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 50CB8AC0380; Sat, 16 Oct 2021 08:23:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1345-g8441cd7852-fm-20211006.001-g8441cd78 Mime-Version: 1.0 Message-Id: <3e5b28a3-f588-4cfb-b1f2-2b645cbfb8d0@dogfood.fastmail.com> Date: Sat, 16 Oct 2021 23:23:21 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=906e842ae6f04c27a12582dd0d717e1d Archived-At: Subject: [Jmap] Interim meeting (shared with CALEXT and CalConnect) coming up this week 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: Sat, 16 Oct 2021 12:23:52 -0000 --906e842ae6f04c27a12582dd0d717e1d Content-Type: text/plain Hi JMAP group, We have an interim meeting coming up in conjunction with CalConnect this week. I expect we'll mainly be talking about JMAP Calendars and JSContact as they have the largest crossover with CalConnect, but if there's anything else you want on the agenda, let me know! We have a 90 minute slot for both CALEXT and JMAP, so there's about 45 minutes available for this working group. https://datatracker.ietf.org/meeting/interim-2021-jmap-02/session/jmap Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --906e842ae6f04c27a12582dd0d717e1d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi JMAP group,
=
We have an interim meeting c= oming up in conjunction with CalConnect this week.  I expect we'll = mainly be talking about JMAP Calendars and JSContact as they have the la= rgest crossover with CalConnect, but if there's anything else you want o= n the agenda, let me know!  We have a 90 minute slot for both CALEX= T and JMAP, so there's about 45 minutes available for this working group= .


Cheers,

Bro= n.

--
&n= bsp; Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com

=

--906e842ae6f04c27a12582dd0d717e1d-- From nobody Sun Oct 17 13:24:46 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 D36583A0B6E; Sun, 17 Oct 2021 13:23:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee via Datatracker To: Cc: draft-ietf-jmap-smime.all@ietf.org, jmap@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163450220275.25872.9347433969708699018@ietfa.amsl.com> Reply-To: Peter Yee Date: Sun, 17 Oct 2021 13:23:22 -0700 Archived-At: Subject: [Jmap] Genart telechat review of draft-ietf-jmap-smime-09 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: Sun, 17 Oct 2021 20:23:23 -0000 Reviewer: Peter Yee Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-jmap-smime-09 Reviewer: Peter Yee Review Date: 2021-10-17 IETF LC End Date: 2021-10-18 IESG Telechat date: 2021-10-21 Summary: This document provides a JMAP extension that allows the JMAP server to provide its thoughts on the verification of a message's S/MIME signature. My concerns over -07 have been addressed in the subsequent versions of the draft. [Ready with nits] Major issues: None Minor issues: None Nits/editorial comments: Page 2, section 1, 1st paragraph, 1st sentence: change "JSON based" to "JSON-based". Page 2, section 1, 2nd paragraph, 3rd sentence: change "client side" to "client-side". From nobody Sun Oct 17 23:35:43 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 868703A11DB; Sun, 17 Oct 2021 23:35:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com, brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <163453890907.1076.7397961358484844853@ietfa.amsl.com> Date: Sun, 17 Oct 2021 23:35:09 -0700 Archived-At: Subject: [Jmap] Erik Kline's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) 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, 18 Oct 2021 06:35:10 -0000 Erik Kline 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: ---------------------------------------------------------------------- Just some random questions that came to mind... [S4.2, question] * Is there any benefit to/reason to consider some boolean like "hasVerifiedAtDeliverySmime"? [S5, question] * In section 4.1, the values of smimeStatus are defined as ... Possible string values of the property are listed below. Servers MAY return other values not defined below, as defined in extensions to this document. If the intention is that documents that update this document are the the way to create new possible values, should this imply the establishment of a registry of these values? But perhaps this level of process is not desired. From nobody Mon Oct 18 07:21:25 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 8EAC93A148B; Mon, 18 Oct 2021 07:21:08 -0700 (PDT) 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, NICE_REPLY_A=-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 (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 LKieuMPIqHAK; Mon, 18 Oct 2021 07:21:00 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id A257E3A1441; Mon, 18 Oct 2021 07:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1634566859; d=isode.com; s=june2016; i=@isode.com; bh=Uf2zFCCLr+5fA9KpkBaphP+AMcFEgS5dw8+nxsQcd2k=; 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=Osmjvvv5ZcdOrldHL8VGsOAxZt1c02DUG1af6Gvq7vuCm/heE2VGy9KLdZ07TP5xqsYT3A ZGVCrvUNfKwDxsDJAN+vWQQUt1UWzzEfS0VTu5kXg4fk5jT7wHvgeyEMIFS5F48qfU8VmH EM8FrDL8BfcainaIq/bMAW3kv4DcSX0=; Received: from [192.168.1.222] (host5-81-100-13.range5-81.btcentralplus.com [5.81.100.13]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 18 Oct 2021 15:20:58 +0100 To: Erik Kline , The IESG Cc: jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com References: <163453890907.1076.7397961358484844853@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <9fd6316b-add5-0100-f975-2f0af605d20c@isode.com> Date: Mon, 18 Oct 2021 15:20:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <163453890907.1076.7397961358484844853@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Erik Kline'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: Mon, 18 Oct 2021 14:21:15 -0000 Hi Erik, Thank you for your comments. On 18/10/2021 07:35, Erik Kline via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Just some random questions that came to mind... > > [S4.2, question] > > * Is there any benefit to/reason to consider some boolean like > "hasVerifiedAtDeliverySmime"? Yes, it might be useful to know whether a message (or a group of messages) was valid (S/MIME signed/verified) at delivery time. > [S5, question] > > * In section 4.1, the values of smimeStatus are defined as > > ... Possible string values of the property are > listed below. Servers MAY return other values not defined below, as > defined in extensions to this document. > > If the intention is that documents that update this document are the > the way to create new possible values, should this imply the establishment > of a registry of these values? > > But perhaps this level of process is not desired. I suppose the document can create a registry. But I can only think of a couple of additions that can be added when S/MIME encryption is also used. I would probably leave this to a future document. Best Regards, Alexey From nobody Mon Oct 18 13:01: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 7A9213A08DA for ; Mon, 18 Oct 2021 13:01:32 -0700 (PDT) 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 (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 542cyNeI0JXb for ; Mon, 18 Oct 2021 13:01:28 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id CA5023A08DE for ; Mon, 18 Oct 2021 13:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1634587284; d=isode.com; s=june2016; i=@isode.com; bh=J0qrLcElv3LFZHuOl27KBGISMiCJEMRZukw2WapJKW0=; 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=gQ+Ala1j+7PYqNEaDMAbxv2x7gyxCf682nsal2J9K782EkXdAO0cX92TJFIMXXHbdDfGpc RSqHpzcfKUOCpI53ds+R6TAIJRllMzLEyCvynfiSddvoVkiQaFZTcj4W1r5gwIP5J+jqVb soPZQedlbBcqiYlYlONc5jSJq3Q/ZFQ=; Received: from [192.168.0.5] ((unknown) [94.3.228.58]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 18 Oct 2021 21:01:23 +0100 X-SMTP-Protocol-Errors: NORDNS To: Bron Gondwana , jmap@ietf.org References: <119ef5f3-ad8d-4423-b019-38454a5be2b6@dogfood.fastmail.com> From: Alexey Melnikov Message-ID: Date: Mon, 18 Oct 2021 21:01:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <119ef5f3-ad8d-4423-b019-38454a5be2b6@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A9E71B79ECA2FCC322802B11" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Blob draft updates - please have a look at -04 before the interim 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, 18 Oct 2021 20:01:33 -0000 --------------A9E71B79ECA2FCC322802B11 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Bron, On 16/10/2021 13:09, Bron Gondwana wrote: > Sorry for the two versions in quick succession!=C2=A0 I realised I hadn't= =20 > put anything in security considerations about virus checking blobs=20 > created by `catenate` the same way you might check blobs injected via=20 > `upload`. > * > * > *I've just posted draft-ietf-jmap-blob-04, which resolves a bunch of=20 > issues:* > > * https://github.com/brong/draft-gondwana-jmap-blob/issues/1 > > o using |typeNames| in the request and |matchedIds| in the > response for lookup > * https://github.com/brong/draft-gondwana-jmap-blob/issues/2 > > o if |data:asText| is requested and the selected octet range is > not valid utf-8, then we add an |isEncodingProblem: true| > property like in RFC8621. > o also, if the selected range can't be entirely satisfied > (length past the end of the blob) we set an|isTruncated: true| > property in the response. > * https://github.com/brong/draft-gondwana-jmap-blob/issues/3 > > o added a |maxCatenateItems| capability field (suggested minimum 64) > * https://github.com/brong/draft-gondwana-jmap-blob/issues/4 > > o added Security Considerations around scanning the resulting > blobs created by Blob/set the same way you would scan uploads. > > *Yet again, I'm asking for your reviews!* I've checked recent changes and they look reasonable to me. Best Regards, Alexey* * > > This is all implemented in the Cyrus IMAP server at=20 > https://github.com/cyrusimap/cyrus-imapd/pull/3685=20 > - which I'm=20 > planning to rebase and neaten up once we're happy with this draft, and=20 > ready to do a working group last call. > > We'll talk about it at the interim meeting with CalConnect next week,=20 > and I'm probably going to ask Jim for a working group last call after=20 > that unless there are any changes that people still want! > > Cheers, > > Bron. > > > P.S. ... and yes, I probably WILL come back after this with yet=20 > another document or two for server-side-coding and=20 > server-side-digests, but that's different enough not to merge into=20 > this one! > --------------A9E71B79ECA2FCC322802B11 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Bron,

On 16/10/2021 13:09, Bron Gondwana wrote:
Sorry for the two versions in quick succession!=C2=A0 I realised I hadn't put anything in security considerations about virus checking blobs created by `catenate` the same way you might check blobs injected via `upload`.

I've just posted draft-ietf-jmap-blob-04, which resolves a bunch of issues:
Yet again, I'm asking for your reviews!

I've checked recent changes and they look reasonable to me.

Best Regards,

Alexey


This is all implemented in the Cyrus IMAP server at https://github.com/cyrusimap/cyrus-imapd/= pull/3685 - which I'm planning to rebase and neaten up once we're happy with this draft, and ready to do a working group last call.

We'll talk about it at the interim meeting with CalConnect next week, and I'm probably going to ask Jim for a working group last call after that unless there are any changes that people still want!

Cheers,

Bron.


P.S. ... and yes, I probably WILL come back after this with yet another document or two for server-side-coding and server-side-digests, but that's different enough not to merge into this one!=C2=A0

--------------A9E71B79ECA2FCC322802B11-- From nobody Mon Oct 18 17:09:51 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 B4EBC3A083A; Mon, 18 Oct 2021 17:09:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com, brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <163460214370.19974.15716909300314956596@ietfa.amsl.com> Date: Mon, 18 Oct 2021 17:09:03 -0700 Archived-At: Subject: [Jmap] Roman Danyliw's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) 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, 19 Oct 2021 00:09:04 -0000 Roman Danyliw 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: ---------------------------------------------------------------------- ** Section 4.1. Recommend sticking to verification practices by citation when defining the semantics of “smimeStatus” OLD signed/verified: S/MIME signed message and the sender's signature was successfully verified, the sender matches the From header field, and the sender's certificate (and the certificate chain) is trusted for signing. signed/failed: S/MIME signed message, but the signature failed to verify. NEW signed/verified: S/MIME signed message and the sender's signature was successfully verified per the verification process in [RFC8551] and [RFC8550]. signed/failed: S/MIME signed message, but the signature failed to verify per the processes in [RFC8551] and [RFC8550]. ** Section 6. Recommend being more explicit with the trust model. OLD Use of server-side S/MIME signature verification JMAP extension requires the client to trust the server signature verification code and configuration to perform S/MIME signature verification. NEW Use of server-side S/MIME signature verification JMAP extension requires the client to trust the server signature verification code and configuration to perform S/MIME signature verification. A malicious or compromised server could return false verification status to a client. A successful verification could be conveyed to a client for a forged or altered message. A properly signed message could be signaled as having a failed signature verification or no signature at all. In the case of the latter attack, no new attack surface is presented with this extension above what malicious or compromised server could already do by stripping or tampering with the S/MIME information in the message. In the case of the former attack, client software capable of performing S/MIME signature verification could detect this attack. Local configuration of the client should determine if this client-side verification should occur. For clients without local verification capabilities, such an attack would be difficult to detect. From nobody Tue Oct 19 15:35:46 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 6D0FE3A0A6D; Tue, 19 Oct 2021 15:34:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com, brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <163468289442.773.9422623149409906055@ietfa.amsl.com> Date: Tue, 19 Oct 2021 15:34:54 -0700 Archived-At: Subject: [Jmap] Benjamin Kaduk's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) 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, 19 Oct 2021 22:34:55 -0000 Benjamin Kaduk 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: ---------------------------------------------------------------------- Are we asserting that the "smime" prefix for property names (and "hasSmime", etc.) relates only to S/MIME signing? How might S/MIME encryption be handled if support is added in the future? I see that the opsdir reviewer asked about whether this document should have an "Updates:" relationship with RFC 8621. I'm not sure I see a need for it, myself, but would be interested in hearing the stance of the authors/WG. Section 4.1 signed: S/MIME signed message, but the signature was not yet verified. Some servers might not attempt to verify a signature until a particular message is requested by the client. JMAP servers compliant with this document SHOULD return "signed/ verified" or "signed/failed" instead of this signature status. I'd suggest adding something like "SHOULD attempt verification and return", just to reiterate that servers don't get to arbitrarily claim verification/failure without doing the verification. smimeErrors: "String[]|null". null signifies that the message doesn't contain any signature or that there were no errors when verifying the S/MIME signature. (I.e., this property is non null only when the corresponding "smimeStatus" response property value is "signed/ failed".) [...] Would some hypothetical future smimeStatus type be compatible with a non-null smimeErrors? This phrasing seems to preclude such a possibility. This might result in the following response: [["Email/get", { "accountId": "abc", "state": "41234123231", I note that this "state" value is used in RFC 8621 when retriving a similar example message. As far as I recall this state value represents only the state of Email objects on the server overall (with some caveat about visibility to the user), and so it is not inherently inconsistent to use the same value across examples ... but it might be worth picking a new value anyway. The reuse of the message "id" for a message with a different "receivedAt" date, subject, etc., though, seems less defensible than reusing "state". Example 2: Retrieval of minimal information about a message, [...] ["Email/get", { "ids": [ "af123u123" ], "properties": [ "mailboxIds", "from", "subject", "date", "smimeStatus", "smimeErrors", "smimeVerifiedAt" ] }, "#1"] Is reusing the method call id allowed? Section 4.2 * *hasVerifiedSmime*: "Boolean". If "hasVerifiedSmime" has the value true, only messages with "smimeStatus" equal to "signed/ verified" match the condition. If "hasVerifiedSmime" has the value false, only messages with "smimeStatus" not equal to "signed/verified" (including the value null) match the condition. Might some future status value (say, "signed+encrypted/verified") also need to match as "verified S/MIME"? This phrasing seems to preclude such a possibility. Section 6 The immutability of smimeStatusAtDelivery might have unfortunate interactions with trust anchor changes (additions, mostly) on the server, since the state could be locked into invalid even if the current TA set would have verified it at the time of delivery. Use of server-side S/MIME signature verification JMAP extension requires the client to trust the server signature verification code and configuration to perform S/MIME signature verification. [...] I think the client also trusts the channel between client and server, as well as the server itself. This is perhaps implicit in trusting the server, especially when combined with the JMAP requirement for secure transport, but might still be worth reiterating, as a divergence from the purely local S/MIME verification mode that is the alternative to this document's mechanism. Furthermore, I think it is worth clearly stating that trusting the server in this way also expands the attack surface -- when this mechanism is used, the server can be attacked (undetectably by the client) and return bogus S/MIME verification state, whereas local verification would have returned correct results. So the client is not just trusting the code and configuration of the server, but also its operational practices. Roman's text looks like a reasonable way of covering the last two points. NITS Section 1 This extension is suitable for cases where reduction in network bandwidth and client side code complexity outweigh security concerns about trusting JMAP server to perform S/MIME signature verifications. [...] "the JMAP server". Section 6 Use of server-side S/MIME signature verification JMAP extension requires the client to trust the server signature verification code and configuration to perform S/MIME signature verification. [...] "the server-side [...] extension". From nobody Tue Oct 19 16:11: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 996863A058F; Tue, 19 Oct 2021 16:10:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com, brong@fastmailteam.com, menachemdodge1@gmail.com, opsdir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <163468502899.24369.8234838512678972724@ietfa.amsl.com> Date: Tue, 19 Oct 2021 16:10:29 -0700 Archived-At: Subject: [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 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 23:10:31 -0000 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. From nobody Tue Oct 19 22:02:52 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 48C8C3A09A7; Tue, 19 Oct 2021 22:02:22 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 In4ADzBdVKzP; Tue, 19 Oct 2021 22:02:17 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 835BB3A0966; Tue, 19 Oct 2021 22:02:17 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id i15so4449823uap.0; Tue, 19 Oct 2021 22:02:17 -0700 (PDT) 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=Giq37kHWmAFUon8/6dVPyERRadfOTEeL3ZynhzFQ/e0=; b=LPa+H6f/CK++cOxLSnPbrSqFUYDCRJXO1QLBQdY6FO+F64pjsx/a4DdH463DL6XMMD AV9M6rNsk44M2XHSnmW57nGGa9sN7EzN/d5l/FuUKzDkxu56XVYFl/RTWwdEFUIGmPGt SgYK8DUBBTTjPSIhrBZIatlQ2trpVo3Yk9RyWVWnaGB7cDl7X5ky0JVypkP8mKryLg1A rmBTBaRqvxx5WAaLQ5WUzNi6DdlOtwKTN9WTH6AeDtRipPzpeke93U66Ka/5IRoG0mrj J+dZhjGTu5ZWN0AN723V28g0VF79Am9ZYiPxRajO4nZQ7TPj2qGq/azgIGyty4Q9q/9I 57Cg== 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=Giq37kHWmAFUon8/6dVPyERRadfOTEeL3ZynhzFQ/e0=; b=hulFC8N6HZ1REvqN3fDsTghJ4tmMKzq0TvOGqtoDdMAIaPPMjURh5fHNSEPxPHM4sm 2rvLVh+c9o+YS+giqjBdmafB+IT33uXA7TTUPv5oLA8HF1VPUTZk3av0/QxEGOmocDcD eeK0hqEgDTnQbrq0he44Ubb6Ljab2hRPZTDJ+JOCnXVilRhwFwnsiNW8ZwwbWKk6uGOa fXVhwVOFfujnjupQo7+n8KS/5g9FHrrgPP0EckV9VK/sdNa/AoD+usIfzw6ccCDMFcyr bczLhpbRTgRAvqUVK0JdcsNjwoH2KcZfMOs0fdZY+ZLCF2A2kmCGf1l6i62LZaFHwy/E I5+w== X-Gm-Message-State: AOAM533f7MDnUhGADuvB635MtxSI60u9DQGj8SOtejf+/owfCcjceLz5 CLxiqGT72hNnRI67/A6bZG0ovJBhEI7jE2ab2WngB05o+w== X-Google-Smtp-Source: ABdhPJx9VPJ57h4JU1JEfsiA3OTT7udd1/1Taim0as1SfZDsISCVTetIUtYN2JxAOqJNvEo2kR+h9nT5Mnytq1YaUFs= X-Received: by 2002:ab0:7385:: with SMTP id l5mr5124965uap.49.1634706135384; Tue, 19 Oct 2021 22:02:15 -0700 (PDT) MIME-Version: 1.0 References: <163468502899.24369.8234838512678972724@ietfa.amsl.com> In-Reply-To: <163468502899.24369.8234838512678972724@ietfa.amsl.com> From: =?UTF-8?B?157XoNeX150g15PXldeT15In?= Date: Wed, 20 Oct 2021 08:02:03 +0300 Message-ID: To: Warren Kumari Cc: The IESG , draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com, opsdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000008306df05cec1ae16" 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, 20 Oct 2021 05:02:23 -0000 --0000000000008306df05cec1ae16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=AA noreply@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 heade= r > 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. > > > > --0000000000008306df05cec1ae16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I was not involved in any email discussions regarding my rev= iew.

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 fo= r
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.org/doc/draft-ietf-j= map-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 he= ader
should indicate "Updates: 8621"." (which Benjamin also refer= enced).

It is entirely possible that I completely missed any discussions, but I'= ;d be
interested in an answer if possible.



--0000000000008306df05cec1ae16-- From nobody Wed Oct 20 02:43:31 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 6B4EC3A095F; Wed, 20 Oct 2021 02:36:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com, brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <163472256651.12981.413656253938594590@ietfa.amsl.com> Date: Wed, 20 Oct 2021 02:36:07 -0700 Archived-At: Subject: [Jmap] Robert Wilton's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) 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, 20 Oct 2021 09:36:16 -0000 Robert Wilton 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: ---------------------------------------------------------------------- Hi, I have to confess that I don't know IMAP, and hence my question may have an obvious answer, but it is unclear to me whether a server supporting the smimeverify capability implies that it SHOULD also support checking the S/MIME signature at delivery time? If this is the case, should this be clarified, perhaps in section 3? I.e., section 3 states: Servers supporting _this_ specification MUST add a property called "urn:ietf:params:jmap:smimeverify" to the capabilities object. E.g., section 4.1 states: signed: S/MIME signed message, but the signature was not yet verified. Some servers might not attempt to verify a signature until a particular message is requested by the client. JMAP servers compliant with this document SHOULD return "signed/ verified" or "signed/failed" instead of this signature status. These two statements seem to imply that a server returning the smimeverify capability SHOULD also support checking the S/MIME signature at delivery because they SHOULD either return signed/verified or signed/failed for a request for smimeStatusAtDelivery, which at least implies that they have previously checked the signature when it was delivered. Is that was is intended? Thanks, Rob From nobody Wed Oct 20 03:03:04 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 761943A1005; Wed, 20 Oct 2021 03:03:02 -0700 (PDT) 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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163472418238.17653.9171539723871181528@ietfa.amsl.com> Date: Wed, 20 Oct 2021 03:03:02 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-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, 20 Oct 2021 10:03:03 -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-08.txt Pages : 25 Date : 2021-10-20 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-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 20 03:08:16 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 99B873A094E; Wed, 20 Oct 2021 03:07:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: "The IESG" Cc: draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, brong@fastmailteam.com, brong@fastmailteam.com, kirsty.p@ncsc.gov.uk X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Francesca Palombini Message-ID: <163472447159.26572.6026957953687413364@ietfa.amsl.com> Date: Wed, 20 Oct 2021 03:07:51 -0700 Archived-At: Subject: [Jmap] Francesca Palombini's No Objection on draft-ietf-jmap-smime-09: (with COMMENT) 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, 20 Oct 2021 10:07:52 -0000 Francesca Palombini 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: ---------------------------------------------------------------------- Thank you for the work on this document. Many thanks to Kirsty Paine for the ART ART review, and thank you Alexey for addressing Kirsty's comments. I have one non-DISCUSS question to which I'd really like an answer nonetheless. Given the following text: [RFC8551] and [RFC8550]. Possible string values of the property are listed below. Servers MAY return other values not defined below, as defined in extensions to this document. Would it make sense to define an IANA registry for the allowed values, to guarantee interoperability of implementations? Francesca From nobody Wed Oct 20 04:43:31 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 BF9003A115E; Wed, 20 Oct 2021 04:42:58 -0700 (PDT) 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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163473017866.27637.5382191321018918506@ietfa.amsl.com> Date: Wed, 20 Oct 2021 04:42:58 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-vcard-07.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, 20 Oct 2021 11:43:02 -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-07.txt Pages : 41 Date : 2021-10-20 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-vcard-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 20 10:52:09 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 BFE9A3A0B2E; Wed, 20 Oct 2021 10:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 HpFeCLy5L4LR; Wed, 20 Oct 2021 10:51:57 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20044.outbound.protection.outlook.com [40.107.2.44]) (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 D420A3A0883; Wed, 20 Oct 2021 10:51:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kowfRzkbGf13W4XHvTfY573YVtNk5e3+1TvGA66uri6xMpAFsgKvJHi52RJXP8pF7HknE9ZUzHvIYKtvsFOo5Be0mTQGdEfnWtbwQBw3r+uI1WxtMlcnN/jmBDivcIvw/FIPyShw68Zturm7MOTeqc9d03SLaunvi+kMmoYOPQLZP3CdaCFa+Cm8k2BZNLfWHumXWNkCx893JbSq4mKitD/fWFe+twyVI8+ZvvmfDqQTZgnjRm5AJONRSILWHF+RI7Z/kCeQTR2KXlFbGz7uASqwEMDbuFFcFonnsb9gaAKWITMy+1AixhHuooioFQ9WdnqMEx5LbYduzpIRy2Q20Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2pH5Ct/PdPRdcROXZATxh0UqaK97QKxJC2f4u0+sFYI=; b=OnA6Jq9JA8BJ9+Q7YbOoXpjWX2QvsfAwWyqNcl/48hoeQBrMnV7k6xslBU/hyrWvS93cTJC5bLz5BCKdqfnD6vD16qBCgWcUiIBYLPiBc9Ix0IzeNOspxyYXumZxZyZmBDLb8TCUUiVC8yMzhNJHvS9AzGUdInCpq5BylJqEv1+oArnlUX1vSYFlvo8UHRok9d5nHxTdRafGVox232aIxoOy41tI3VFl01UaXbCknM1u8OsUQN/6FIQbh/H/FGnPvUuLbZi4zaQoCedAbdy0dGJGI5M7ZM3DLrMYJOAo3r61WhR9EtIv+jnCoOTQza9LgnyQvVZJXvNhojJMbrCOxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2pH5Ct/PdPRdcROXZATxh0UqaK97QKxJC2f4u0+sFYI=; b=SQA6URjwzXjAmGWFND76X73PIXKn6iCa+n67YlloKo3AJ07Hv59tV46ZKW94xU0Reni0ZYc2wBjskohunFugrvbmMbN14AA60oh5BdhBhMyGleX7sFStcCX6YpPkGAg6/VcvqH+vUPlBu7Gf7Dc6veAzObhfoufXwB0LZX8BO9Y= Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB3035.eurprd07.prod.outlook.com (2603:10a6:3:4d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.13; Wed, 20 Oct 2021 17:51:53 +0000 Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::80e5:ba60:5203:f9a5]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::80e5:ba60:5203:f9a5%6]) with mapi id 15.20.4628.013; Wed, 20 Oct 2021 17:51:52 +0000 From: Francesca Palombini To: Alexey Melnikov , Kirsty Paine , "art@ietf.org" CC: "jmap@ietf.org" , "draft-ietf-jmap-smime.all@ietf.org" , "last-call@ietf.org" Thread-Topic: [Jmap] Artart last call review of draft-ietf-jmap-smime-08 Thread-Index: AQHXr9Mf/PknPG73ZUekm3Zdm/iqRau81SGAgB+BUhE= Date: Wed, 20 Oct 2021 17:51:52 +0000 Message-ID: References: <163232991808.32122.9195451729619651354@ietfa.amsl.com> <003af00e-d7e4-1f50-9a7a-3d312f700df2@isode.com> In-Reply-To: <003af00e-d7e4-1f50-9a7a-3d312f700df2@isode.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4c77b412-74f6-4a19-9834-08d993f24ccb x-ms-traffictypediagnostic: HE1PR0701MB3035: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9PPYY3w/iEesst+e+EmrtTpdmQ7j72V0TOO7KuFCZletI7Q4cpOJIC/kKLrvhzXJDU9GrCq2wajrv7+owD2tcHxITTny/6XFuMFooQtXvSlq2j/W1yZsxhAzNj0J8ljG8Z76RmoZYceglUhrOjNnX4+etkaJYVQeujIkaYAHiojHUg5JknbM/2Ys39H0Gh/DaS8yfMFR4jlTU0cj/e73d9zB7nNFWLfzCBpj4hmVe2WFmqRXt3MAmeCQZpLsHR1Ob4GVnZZOF9ac7U1RmsyQPZhZeDlnWi6MmdAIAFNQbyPYAH9PbNJ8ApM/0GumV0QrSWSHCwfctnHCYsRWPrS917TwVFxMizOszC2yMu5B68Twlc10stfxB2AIJ2WUm5zNcMJRsZCypXl9/3wzUahBoewKxLYJHorK0upRtxU6s7kmrBydh3DmB0r+aAGsSUxF7IVOKUpJuPKkZrXzwOKr6t5QNQfHgoZ5/O12hI/yYatWbb0rfAs2fHzb4qOSUlF/Cn4dA3kwVFhNwuxQ12iRhDcPT78QVPu0OXP3CHhkrqEQBeUzE5+RQ/xNsQo/93xoWoE3S3Q8KNFit3N+u1dWDn3726cHHHazWeBhJ7QZ70olOw1RedVSim1bB0ju2lVO2XECWQ2EhTtVyhiZ9nh76LlyY1vtOJbgGm9ZVgPOGCaNSavmcM1yd1SuU+2OlBrqJ9OihudaAeNjDBU8zWDfSw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(82960400001)(38100700002)(316002)(6506007)(33656002)(83380400001)(2906002)(53546011)(4326008)(110136005)(66476007)(66556008)(122000001)(54906003)(52536014)(7696005)(38070700005)(66946007)(64756008)(66446008)(71200400001)(5660300002)(76116006)(9686003)(44832011)(8936002)(86362001)(55016002)(186003)(8676002)(508600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?IUw7QP49HfyCC0uVlpnU6NmuSz2FZcsAyYaFy6gQUPdErRi5UgzLpVnl?= =?Windows-1252?Q?M1yVxzymJ8g8eVfgihrIKUn+nY0eLpdBn5e6e1rP7Uyii651ltJwJRZb?= =?Windows-1252?Q?MwFP8KhxOE2YsDPWMA39lYXuCl5NmJNRKJS7KUIoWJezVPBM5t442qPF?= =?Windows-1252?Q?LeAVcT4q0wBnyEgiQq03TbbZLEACAw0ueSJ9F25/fozDAU4PsAqd/q6U?= =?Windows-1252?Q?iTKsn6gnicSse71MMCfCdPtQ6owcAZgqzu76efVg1oTqaXzA7KoYA5yp?= =?Windows-1252?Q?fRDO9USbf7p5IpycYUUz7TkIlj8SeiZmIIGNHVqWDHCd37ehx5hbImEh?= =?Windows-1252?Q?8FEAAHbKN58KGQNBzl/4qHnHPAZjJHGg5fTVX6cveRoKl7PRWSc7elV6?= =?Windows-1252?Q?48F4EDIDJu0cbxkxZc01TBLB5vsuWMhssm5nwqVi3UHOiusK0gka0HCL?= =?Windows-1252?Q?06JtuJ6TyWo/KKqTEkNzgkDoeYQ9HUgFZw9nErsQ9P5QxaWBKgi4BgOr?= =?Windows-1252?Q?o71pA15JQ82okjT9gen6GTSEFNehapVToKOMymBR6c78AFb44GtfDDh8?= =?Windows-1252?Q?6wkILT2ENXgeR8mIZYpJh8RKGVOEVzzbeiPCoel63LsQPVSVMSZBzYUr?= =?Windows-1252?Q?gpKXYJNziiMynO7pODt0xebT88bZ/ngU0Z81+OcZDHItavoZ1kkoKyIX?= =?Windows-1252?Q?62MDQ0v53JaS9FBvsBPhr4Dfxl7blyev3SvewYGfDg4MNtHYABHgKIwh?= =?Windows-1252?Q?fKtZzY/LHcSHjiO3DqQrarEa2ZYHPJeMTpNcrLKliuoeJqGOc+f9OHOF?= =?Windows-1252?Q?SMelhnBzDaYM7coMF08rNhue4fB5guu37C9faf0smXP40mWB9d77EpYy?= =?Windows-1252?Q?x6hdMLhHeXiQBLNX2X7Y6GYs7WuhhCdGT0oOfFj1L8C/kOtDRsnCSD4B?= =?Windows-1252?Q?mcYFB9UEZtXJIdWBOka4fsYjIrJqXyr+Eo2fRmv7Zuj61n9PwM7zwerN?= =?Windows-1252?Q?y+aiHyE/iQvkNpY8gO/NHh/sAz2jEcQ9GVnK0CazMoGJVPW7TjBPMpUv?= =?Windows-1252?Q?oBeEt5H2jlm4+7TNXJ1YuJQbIKBQIqw0aTOZ31eQvsuvUSykYf4UZWwH?= =?Windows-1252?Q?Ld9wNpAKD6xzRtMjSqyOt7Hh87ZKax56PCyjTpNr9UHYQHs9SkKieAE0?= =?Windows-1252?Q?dy+hV1+JgfkOFSrmp83HSY9mV8dhj20ZeV/cbMn4ey5Z3ImALi/1IscV?= =?Windows-1252?Q?lHj4kMAXZV55hcly6bjMgUc1KDRvjo5aVb12eKeX5cSqYIGCkelUQ68s?= =?Windows-1252?Q?gd0xu0ztln2KDXLKqJ052vqrHxA1fgUSuKGIWuIWKraLEQhcoB68yfiX?= =?Windows-1252?Q?t2DCjUye1uDf2roRNAeUL9Ih+VKyYnRitMFnVe9qoSB/VZnB6NFvjyYO?= =?Windows-1252?Q?ri1h/yHrLw+qZ+k1nCOc0HoOgm2ySZy2eKKhYewSeNDfi89lbQSRuPO7?= =?Windows-1252?Q?oihGqjuQK//pJGUWoxm+mvu39JN/ONDHdqD+ATazKhrC9m7PQa6KUY/d?= =?Windows-1252?Q?a+Gy4RImpdJF5use+Oc7KloV8kLOENQOvQIgdimxkWeHankCfGjRv+1x?= =?Windows-1252?Q?iEb0ngcR/5rqViJdhhPfDjdlkdoOapP5NWsBgdFvtHoKzgjkxJYZhYXT?= =?Windows-1252?Q?iGNXYqHIYOk=3D?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB4217ADDAF90A9355868DA58398BE9HE1PR07MB4217eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c77b412-74f6-4a19-9834-08d993f24ccb X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2021 17:51:52.8416 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: francesca.palombini@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3035 Archived-At: Subject: Re: [Jmap] Artart last call review of draft-ietf-jmap-smime-08 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, 20 Oct 2021 17:52:03 -0000 --_000_HE1PR07MB4217ADDAF90A9355868DA58398BE9HE1PR07MB4217eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you very much Kirsty for the review! And thanks Alexey for addressing= Kirsty=92s comments. Francesca From: Alexey Melnikov Date: Thursday, 30 September 2021 at 18:44 To: Kirsty Paine , art@ietf.org Cc: jmap@ietf.org , draft-ietf-jmap-smime.all@ietf.org , last-call@ietf.org Subject: Re: [Jmap] Artart last call review of draft-ietf-jmap-smime-08 Hi Kirsty, Thank you for your review. On 22/09/2021 17:58, Kirsty Paine via Datatracker wrote: > Reviewer: Kirsty Paine > Review result: Ready with Issues > > I'm the assigned reviewer for the ART area. Apologies for the delay in my > review - I was on holiday. > > In summary, I think the draft could do with being clearer in a few places= and > having a more logical ordering in Section 4. That said, most of my commen= ts are > nits or common ART review issues, so I think the draft is essentially Rea= dy. > > Abstract > =95 it could be worth including the RFC reference to the protocol b= eing > extended here, or expanding the acronym "JMAP". S/MIME is probably well-k= nown > enough by now though :) I changed "JMAP" to "JMAP for Mail (RFC 8621)". > Introduction > =95 RFC8621 specifies "JMAP for email", JMAP is specified by RFC862= 0. So > should this be "JMAP for Email [RFC8621]" or "JMAP [RFC8620]" rather than= "JMAP > [RFC8620]" as it currently is? Sure. I used "JMAP for Mail [RFC8621]", to match the title of RFC 8621. > =95 The first sentence in the second > paragraph in the introduction could benefit from more specific references= too. > As an example, you could rephrase like "when the multipart/signed media t= ype is > used [RFC1847], the client is not required to download=85 and when the > application/pkcs7-mime media type is used [RFC8551 Sec. 3.2]" Added, thanks. > =95 Missing > words: "assumes that *the/a* JMAP client trusts *the/a* JMAP server=85" Fixed, thanks. > =95 > I'm not sure that "this JMAP extension assumes" makes much sense =96 is i= t really > the extension that assumes this trust relationship? Perhaps more accurate= ly, > the use of the extension implies the client trusts the server's configura= tion > and code=85 Or that when this extension is in use, the threat model must = assume > that the client trusts the server's configuration and signature verificat= ion > code. Yes, good point. > Section 2: > =95 I see this document follows the conventions in Section 1.1 of R= FC8621. > However, if there are particular meanings for words and asterisks later i= n the > document, it might be helpful to reference Section 1.1 at the point of us= e too, > so that the specific normative meaning isn't lost on those unfamiliar wit= h the > editorial conventions (e.g. for "server-set" in Section 4). Ok, I will review. > Section 3: > =95 It might be worth highlighting where exactly in RFC8620 one can= find > details about the capabilities object, since it's a 90-page RFC and it's = not a > section header. The capabilities object and Session object referenced are > defined in Section 2 of RFC8620. Ok. > =95 Is this a hidden requirement: "The > value of this property is an empty object"? For example, you could reword= to > say "the value of the urn:ietf:params:jmap:smimeverify property MUST be a= n > empty object" or "must be set to" or similar. It is the same thing without using RFC 2119 language. > Section 4: > =95 In the second sentence of Section 4, "This document" refers to = the > current document you're writing in, not RFC8621, if I understand correctl= y. Try > to make that clearer :) Yes. Any suggestions how to make this clearer? I've seen "this document" used frequently in RFCs. > =95 There's no sentence introducing the unknown, > signed, signed/verified and signed/failed messages, and they don't form a > bullet point list as you have above, so I found this difficult to parse. They should be a bullet list. This might be a rendering issue. They are introduced by "Possible string values of the property are listed below." > It could be a good idea to include something like "The smimeStatus value = can only > be one of the following four messages". This is actually not true, as there is a sentence saying "Servers MAY return other values not defined below". In particular my implementation also emits "encrypted+signed/verified". > This would help readability, and it > might be worth adding a colon after these messages or indenting more, bec= ause > it's not very clear, e.g. "unknown: S/MIME message" read to me as "unkn= own > S/MIME message=85" Good point, added. > =95 For unknown, you use the present tense "is" but for > the other smimeStatus responses, you use "was". I would suggest making it= the > same for them all. Changed. > =95 You probably don't need to say "compliant with this > document", just say "JMAP servers SHOULD=85" =95 Structurally for S= ection 4, > it might be helpful to have sub-headings for the four different property = values > and then group all the text about it in one place. And then another secti= on for > the FilterCondition object too perhaps. Ok, I will try to improve this. > =95 I find it odd that the bullet > points are in a different order to the text that follows, e.g. the bullet= s are > smimeStatus, smimeErrors, smimeVerifiedAt, smimeStatusAtDelivery; the tex= t > orders it smimeStatus, smimeStatusAtDelivery, smimeErrors, smimeVerifiedA= t --_000_HE1PR07MB4217ADDAF90A9355868DA58398BE9HE1PR07MB4217eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thank you= very much Kirsty for the review! And thanks Alexey for addressing Kirsty= =92s comments.

&nbs= p;

Francesca=

&nbs= p;

From: Alexey Melnikov <alexey.melnikov@isod= e.com>
Date: Thursday, 30 September 2021 at 18:44
To: Kirsty Paine <kirsty.p@ncsc.gov.uk>, art@ietf.org <art@= ietf.org>
Cc: jmap@ietf.org <jmap@ietf.org>, draft-ietf-jmap-smime.all@i= etf.org <draft-ietf-jmap-smime.all@ietf.org>, last-call@ietf.org <= last-call@ietf.org>
Subject: Re: [Jmap] Artart last call review of draft-ietf-jmap-smime= -08

Hi Kirsty,

Thank you for your review.

On 22/09/2021 17:58, Kirsty Paine via Datatracker wrote:
> Reviewer: Kirsty Paine
> Review result: Ready with Issues
>
> I'm the assigned reviewer for the ART area. Apologies for the delay in= my
> review - I was on holiday.
>
> In summary, I think the draft could do with being clearer in a few pla= ces and
> having a more logical ordering in Section 4. That said, most of my com= ments are
> nits or common ART review issues, so I think the draft is essentially = Ready.
>
> Abstract
> =95       it could be worth including th= e RFC reference to the protocol being
> extended here, or expanding the acronym "JMAP". S/MIME is pr= obably well-known
> enough by now though :)
I changed "JMAP" to "JMAP for Mail (RFC 8621)".
> Introduction
> =95       RFC8621 specifies "JMAP f= or email", JMAP is specified by RFC8620. So
> should this be "JMAP for Email [RFC8621]" or "JMAP [RFC= 8620]" rather than "JMAP
> [RFC8620]" as it currently is?
Sure. I used "JMAP for Mail [RFC8621]", to match the title of RFC= 8621.
>   =95       The first sentence= in the second
> paragraph in the introduction could benefit from more specific referen= ces too.
> As an example, you could rephrase like "when the multipart/signed= media type is
> used [RFC1847], the client is not required to download=85 and when the=
> application/pkcs7-mime media type is used [RFC8551 Sec. 3.2]"
Added, thanks.
> =95       Missing
> words: "assumes that *the/a* JMAP client trusts *the/a* JMAP serv= er=85"
Fixed, thanks.
> =95
> I'm not sure that "this JMAP extension assumes" makes much s= ense =96 is it really
> the extension that assumes this trust relationship? Perhaps more accur= ately,
> the use of the extension implies the client trusts the server's config= uration
> and code=85 Or that when this extension is in use, the threat model mu= st assume
> that the client trusts the server's configuration and signature verifi= cation
> code.
Yes, good point.
> Section 2:
> =95       I see this document follows th= e conventions in Section 1.1 of RFC8621.
> However, if there are particular meanings for words and asterisks late= r in the
> document, it might be helpful to reference Section 1.1 at the point of= use too,
> so that the specific normative meaning isn't lost on those unfamiliar = with the
> editorial conventions (e.g. for "server-set" in Section 4).<= br> Ok, I will review.
> Section 3:
> =95       It might be worth highlighting= where exactly in RFC8620 one can find
> details about the capabilities object, since it's a 90-page RFC and it= 's not a
> section header. The capabilities object and Session object referenced = are
> defined in Section 2 of RFC8620.
Ok.
> =95       Is this a hidden requirement: = "The
> value of this property is an empty object"? For example, you coul= d reword to
> say "the value of the urn:ietf:params:jmap:smimeverify property M= UST be an
> empty object" or "must be set to" or similar.
It is the same thing without using RFC 2119 language.
> Section 4:
> =95       In the second sentence of Sect= ion 4, "This document" refers to the
> current document you're writing in, not RFC8621, if I understand corre= ctly. Try
> to make that clearer :)
Yes. Any suggestions how to make this clearer? I've seen "this documen= t"
used frequently in RFCs.
>   =95       There's no sentenc= e introducing the unknown,
> signed, signed/verified and signed/failed messages, and they don't for= m a
> bullet point list as you have above, so I found this difficult to pars= e.

They should be a bullet list. This might be a rendering issue.

They are introduced by "Possible string values of = the property are
listed below."

> It could be a good idea to include something like "The smimeStatu= s value can only
> be one of the following four messages".
This is actually not true, as there is a sentence saying
"Servers MAY return other values not def= ined below". In particular my
implementation also emits "encrypted+signed/verified".
> This would help readability, and it
> might be worth adding a colon after these messages or indenting more, = because
> it's not very clear, e.g. "unknown:   S/MIME message&qu= ot; read to me as "unknown
> S/MIME message=85"
Good point, added.
> =95       For unknown, you use the prese= nt tense "is" but for
> the other smimeStatus responses, you use "was". I would sugg= est making it the
> same for them all.
Changed.
> =95       You probably don't need to say= "compliant with this
> document", just say "JMAP servers SHOULD=85" =95 &= nbsp;     Structurally for Section 4,
> it might be helpful to have sub-headings for the four different proper= ty values
> and then group all the text about it in one place. And then another se= ction for
> the FilterCondition object too perhaps.
Ok, I will try to improve this.
> =95       I find it odd that the bullet<= br> > points are in a different order to the text that follows, e.g. the bul= lets are
> smimeStatus, smimeErrors, smimeVerifiedAt, smimeStatusAtDelivery; the = text
> orders it smimeStatus, smimeStatusAtDelivery, smimeErrors, smimeVerifi= edAt

--_000_HE1PR07MB4217ADDAF90A9355868DA58398BE9HE1PR07MB4217eurp_-- From nobody Wed Oct 20 11:31:38 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 8A9083A0D7D; Wed, 20 Oct 2021 11:31:13 -0700 (PDT) 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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163475467322.20491.6732014764674154930@ietfa.amsl.com> Date: Wed, 20 Oct 2021 11:31:13 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-tasks-01.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, 20 Oct 2021 18:31:22 -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 for Tasks Authors : Joris Baum Hans-Joerg Filename : draft-ietf-jmap-tasks-01.txt Pages : 19 Date : 2021-10-20 Abstract: This document specifies a data model for synchronizing task data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-tasks/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-tasks-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-tasks-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 20 23:20:09 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 BA1F93A0CDB; Wed, 20 Oct 2021 23:19:25 -0700 (PDT) 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=tOlf50qX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O+l4QyBL 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 RYNWJ5Azs5xk; Wed, 20 Oct 2021 23:19:18 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B843A0CDF; Wed, 20 Oct 2021 23:19:17 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ED0F15C018A; Thu, 21 Oct 2021 02:19:16 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Thu, 21 Oct 2021 02:19:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=DWhs5J37HgI7IJSLyxj1q7QNaV9QfeIMXJsXNjX AewM=; b=tOlf50qX/DeFXJmpoWsKyNYlP4mTTdc+9adu9YdMKanw1oX0BPg/viU IgoM1OeCbDOV5eR6IFMBtT+FtqsglAfF8EwiMl6vvZ/rz/CFGZWORn/fUI43HKWS +JHbVOTR9G7/VVmMHYzo77yTkyn/ueMSLkVQaYvejuwpJjdvS8l4sOudsLqbGY6B 2enIDHw52s19xOsuGjAmzFwBfOvBpw8JPPY0tsbpVwjXrq0pVGlH/5SdZR68Xu8t 4JCH9Q8SVfFOI7trZeb7kvJZdRQAQTmUgaqKbGAQrNYrMn/afPVtVJE2l+UWbBFD HqNAg0gidVdYxilBq0gTPBnw/ZPZa6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=DWhs5J37HgI7IJSLyxj1q7QNaV9Qf eIMXJsXNjXAewM=; b=O+l4QyBLjQ+2dkuOqAjh+DMX5TpHgMhXqy4zH1TMYR7fr 5UK7aWTrWRLiaqx/XRYwg0dFdmnhqtdF1M6ptR623LkV0DC6vSteKF+rF4R9GKFy gS2eme/4BO84JfLRbNYZrm4PVLoto60osd+5dFNmMRKVDt8zfwzbjpEDG3sQYDUn QH/YAyfId/NNnllQDcOHn8pBneUBK0myrOZa7TvGZaFTlBX4sJFfgUfGM31fdaQu K04vNjJZ2faVQb80KVvFuxezaJrt36v7Qusdt2hd1QW4HG7osWYjC7SU6Txo6Pta WPc+JpEWN/sJSWiFOR2wr720ftUPg0qp66eaWLmyw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvhedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedtjeelueeigeejgf dugfefgfehkeeihfdtteelueehgeejffellefhgefgudffieenucffohhmrghinhepiiho ohhmrdhushdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BA43BAC03DB; Thu, 21 Oct 2021 02:19:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e Mime-Version: 1.0 Message-Id: <1091b2a3-bdfe-494e-ab29-94b4e6d3ea61@dogfood.fastmail.com> Date: Thu, 21 Oct 2021 17:18:56 +1100 From: "Bron Gondwana" To: calsify@ietf.org, jmap@ietf.org Content-Type: multipart/alternative; boundary=5f6e6faf69ee437fa218a8770f2afa84 Archived-At: Subject: [Jmap] Interim session starting soon 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, 21 Oct 2021 06:19:26 -0000 --5f6e6faf69ee437fa218a8770f2afa84 Content-Type: text/plain Hi all, Here's the details for today's meeting, which is starting in about 40 minutes from when I send this email: CALEXT/JMAP Interim at CalConnect (Thursday 21 October 0300 Eastern) https://us02web.zoom.us/j/85389704050?pwd=TUt0UHROWGZwWk45Q29Pb0pab0l2dz09 Meeting ID: 853 8970 4050 Passcode: 889430 (I have had reports of the zoom client crashing in Chrome, but working in Safari on Mac - if you don't have the full meetings client - so try another browser if you have issues) Notes will be taken in the same document for both CALEXT and JMAP (to avoid duplication): https://notes.ietf.org/notes-ietf-interim-2021-calext-02-calext Current plan is about 45 min for CALEXT first, then another 45 min for JMAP - but all is subject to agenda bashing. See you there! Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --5f6e6faf69ee437fa218a8770f2afa84 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,

Here's the details for today's meet= ing, which is starting in about 40 minutes from when I send this email:<= br>

CALEXT/JMAP Interim at CalConnect (Thursday 21 October 0300 Eastern)
https://us02we= b.zoom.us/j/85389704050?pwd=3DTUt0UHROWGZwWk45Q29Pb0pab0l2dz09
Meeting ID: 853 8970 4050
Passcode: 889430

(I have= had reports of the zoom client crashing in Chrome, but working in Safar= i on Mac - if you don't have the full meetings client - so try another b= rowser if you have issues)
Notes will be taken in the sam= e document for both CALEXT and JMAP (to avoid duplication):




Bron.


--5f6e6faf69ee437fa218a8770f2afa84-- From nobody Thu Oct 21 06:55:57 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 3418C3A16B5; Thu, 21 Oct 2021 06:55:17 -0700 (PDT) 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, NICE_REPLY_A=-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 (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 wUF01EPn3PBQ; Thu, 21 Oct 2021 06:55:11 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id B24B63A16B3; Thu, 21 Oct 2021 06:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1634824505; d=isode.com; s=june2016; i=@isode.com; bh=qx3OVXLp4Ks2+Im0GTgd/zQIf4kIKNLXmxmWwlCgYyI=; 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=FAIeLQigxOxEMsUK23OI9vumgW2O0HxJRSLMu3hcXp78eOB3WpQ0F2Llik8q5NWm9Oxq2R oLxsTxjCuJxx23UzAy6sZSbDFiPUeHsW8NEnsmjEX6i1z5Gfu9+doEc9hn5CEwAO7Hh6yF uhIkubtAtGp2D4E7E2u2DSU+0TLJRNQ=; Received: from [172.27.249.49] (connect.isode.net [172.20.0.43]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 21 Oct 2021 14:55:05 +0100 To: Francesca Palombini , The IESG Cc: jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, kirsty.p@ncsc.gov.uk, brong@fastmailteam.com References: <163472447159.26572.6026957953687413364@ietfa.amsl.com> From: Alexey Melnikov Message-ID: Date: Thu, 21 Oct 2021 14:55:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <163472447159.26572.6026957953687413364@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Francesca Palombini'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: Thu, 21 Oct 2021 13:55:18 -0000 Hi Francesca, Thank you for your comments. On 20/10/2021 11:07, Francesca Palombini via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work on this document. Many thanks to Kirsty Paine for the > ART ART review, and thank you Alexey for addressing Kirsty's comments. > > I have one non-DISCUSS question to which I'd really like an answer nonetheless. > Given the following text: > > [RFC8551] and [RFC8550]. Possible string values of the property are > listed below. Servers MAY return other values not defined below, as > defined in extensions to this document. > > Would it make sense to define an IANA registry for the allowed values, to > guarantee interoperability of implementations? Ok, the only thing missing from the list of choices in this document (IMHO) is encrypted+signed/verified and encrypted+signed/failed, because this document doesn't cover automatic decryption. (These are hopefully will be documented in a followup document.) I am fine with creating an IANA registry, if people prefer. Best Regards, Alexey From nobody Thu Oct 21 06:59:40 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 19C143A16C8; Thu, 21 Oct 2021 06:59:32 -0700 (PDT) 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 (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 Pg-rWhVEM4Xg; Thu, 21 Oct 2021 06:59:26 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A102D3A085D; Thu, 21 Oct 2021 06:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1634824765; d=isode.com; s=june2016; i=@isode.com; bh=+5y/PlOB6HmdC2LLEgTgePgeoh/D2JeNElU8v+RIlz4=; 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=QVun0fYR+wMbvq53Uo9e0PnkS6ZckiAfjQPnf4Vrv1+fkjzdTN3OUA+XK30eYNnpjKbYGR 56TEoPx1CITBIMv6DUy+PL8y6sN14FYNfzCM4DP6XvEWBjJqJpgUhoCrSiIJSN7ffvc2xe jFBNzhuabHwBPApANyzMYzXnDxgpH1E=; Received: from [172.27.249.49] (connect.isode.net [172.20.0.43]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 21 Oct 2021 14:59:25 +0100 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> From: Alexey Melnikov Message-ID: <2bdf9246-e450-194b-36ac-e5c6f6216325@isode.com> Date: Thu, 21 Oct 2021 14:59:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------27633D79096A11DB1DEC547F" Content-Language: en-GB 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: Thu, 21 Oct 2021 13:59:32 -0000 --------------27633D79096A11DB1DEC547F Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Menachem/Warren, My apologies, I don't think I've seen the OpsDir review, so I will reply=20 to it separately. In regards to lack of "Updates: 8621": as this defines a JMAP extension=20 that doesn't modify the base JMAP protocol (other than extending it), it=20 is not customary to include "Updates: 8621". Or to rephrase: a reader of=20 RFC 8621 doesn't need to know about existence of this document unless=20 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' wrot= e: > 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. > --------------27633D79096A11DB1DEC547F Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

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 via Datatrac= ker=E2=80=AC=E2=80=8F <=E2=80=AAnorepl= y@ietf.org=E2=80=AC=E2=80=8F>:=E2=80=AC
War= ren 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 ht= tps://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:
ht= tps://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.
--------------27633D79096A11DB1DEC547F-- From nobody Thu Oct 21 07:14:17 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 54E733A1735; Thu, 21 Oct 2021 07:14:07 -0700 (PDT) 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, NICE_REPLY_A=-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 (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 JMPpYU2af-Qk; Thu, 21 Oct 2021 07:14:02 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A27FD3A1744; Thu, 21 Oct 2021 07:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1634825640; d=isode.com; s=june2016; i=@isode.com; bh=vHkOgiT7T/xbkqhOzacnP59251r7v8bqkU47Ebm+z0s=; 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=VsSh9BNlMFdw3Dy039KNsDbdhn3e7gRLK8/kC6xwVcxfu1RoWu8jm33lGUPpOQfilqcj94 qZp1ZhVFd1a1A3T9I4DP1RemGzIoCGnidq3CXFPm7vZKIUTwTLGjecD8BQENipO+tnUgWV X7Vnp0RO6s+r0vZAxvp5jiUc1DBodAA=; Received: from [172.27.249.49] (connect.isode.net [172.20.0.43]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 21 Oct 2021 15:14:00 +0100 From: Alexey Melnikov To: Robert Wilton , The IESG Cc: jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com References: <163472256651.12981.413656253938594590@ietfa.amsl.com> Message-ID: Date: Thu, 21 Oct 2021 15:13:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <163472256651.12981.413656253938594590@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Robert Wilton'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: Thu, 21 Oct 2021 14:14:11 -0000 Hi Robert, On 20/10/2021 10:36, Robert Wilton via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > I have to confess that I don't know IMAP, and hence my question may have an > obvious answer, but it is unclear to me whether a server supporting the > smimeverify capability implies that it SHOULD also support checking the S/MIME > signature at delivery time? If this is the case, should this be clarified, > perhaps in section 3? The intent was to require support of all attributes specified in the draft. > I.e., section 3 states: > Servers supporting > _this_ specification MUST add a property called > "urn:ietf:params:jmap:smimeverify" to the capabilities object. > > E.g., section 4.1 states: > > signed: S/MIME signed message, but the signature was not yet > verified. Some servers might not attempt to verify a signature > until a particular message is requested by the client. JMAP > servers compliant with this document SHOULD return "signed/ > verified" or "signed/failed" instead of this signature status. > > These two statements seem to imply that a server returning the smimeverify > capability SHOULD also support checking the S/MIME signature at delivery > because they SHOULD either return signed/verified or signed/failed for a > request for smimeStatusAtDelivery, which at least implies that they have > previously checked the signature when it was delivered. Is that was is > intended? I think you are saying that bare "signed" will never be returned if the server also supports smimeStatusAtDelivery. Good question, let me think about it and I will come back to you. Best Regards, Alexey From nobody Thu Oct 21 07:17:16 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 295AD3A170F; Thu, 21 Oct 2021 07:17:03 -0700 (PDT) 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, NICE_REPLY_A=-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 (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 LthwxxNIeJhq; Thu, 21 Oct 2021 07:16:57 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id DD9C23A16FF; Thu, 21 Oct 2021 07:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1634825810; d=isode.com; s=june2016; i=@isode.com; bh=xryCCA72hc9MUS12nreJshfr7osRevbN6KnZTUEJ+v4=; 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=TYpuxcxqmzqYhDvcFCvzTISRUF3yZ3YbJwPRAT5KnMoWRiRt0jGOG1/wm5wV4LK4jkATKe CBpIMCxUUnfIO4FD7pY20ueV40sJtF+0xeY3sJDB5mP3jr04zjA2p5hOxO1bMZQAvK52sr DKMh02Qtc11T/HDpiRehRjWrgxAP0vM=; Received: from [172.27.249.49] (connect.isode.net [172.20.0.43]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 21 Oct 2021 15:16:50 +0100 To: Roman Danyliw , The IESG Cc: jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com References: <163460214370.19974.15716909300314956596@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <002266b6-50e4-846b-e325-86721eea8769@isode.com> Date: Thu, 21 Oct 2021 15:16:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <163460214370.19974.15716909300314956596@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Roman Danyliw'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: Thu, 21 Oct 2021 14:17:04 -0000 Hi Roman, On 19/10/2021 01:09, Roman Danyliw via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** Section 4.1. Recommend sticking to verification practices by citation= when > defining the semantics of =E2=80=9CsmimeStatus=E2=80=9D > > OLD > signed/verified: S/MIME signed message and the sender's signature > was successfully verified, the sender matches the From header > field, and the sender's certificate (and the certificate chain) is > trusted for signing. > > signed/failed: S/MIME signed message, but the signature failed to > verify. > > NEW > signed/verified: S/MIME signed message and the sender's signature was > successfully verified per the verification process in [RFC8551] and [RFC85= 50]. > > signed/failed: S/MIME signed message, but the signature failed to ve= rify > per the processes in [RFC8551] and [RFC8550]. [RFC8551] and [RFC8550] are already listed earlier on when smimeStatus=20 is described in more general terms, so implementing your suggestion=20 becomes less urgent. Let me think a bit more about the best way of=20 updating the draft to reflect this comment. > ** Section 6. Recommend being more explicit with the trust model. > > OLD > Use of server-side S/MIME signature verification JMAP extension requires t= he > client to trust the server signature verification code and configuration t= o > perform S/MIME signature verification. > > NEW > Use of server-side S/MIME signature verification JMAP extension requires t= he > client to trust the server signature verification code and configuration t= o > perform S/MIME signature verification. A malicious or compromised server = could > return false verification status to a client. A successful verification c= ould > be conveyed to a client for a forged or altered message. A properly signe= d > message could be signaled as having a failed signature verification or no > signature at all. In the case of the latter attack, no new attack surface= is > presented with this extension above what malicious or compromised server c= ould > already do by stripping or tampering with the S/MIME information in the > message. In the case of the former attack, client software capable of > performing S/MIME signature verification could detect this attack. Local > configuration of the client should determine if this client-side verificat= ion > should occur. For clients without local verification capabilities, such a= n > attack would be difficult to detect. Sounds good to me. Added to my copy of -10. Thank you, Alexey From nobody Thu Oct 21 07:45:46 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 3B5A53A1785 for ; Thu, 21 Oct 2021 07:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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] 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 52SS675fc9TM for ; Thu, 21 Oct 2021 07:45:23 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 2D80C3A1781 for ; Thu, 21 Oct 2021 07:45:23 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id e10so1704723uab.3 for ; Thu, 21 Oct 2021 07:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=pxlNraflQ92wCBU3dsQwJHlD8zaHShnyVITA3dHRg0o=; b=WUZV0xMb0MbMxLGzbPxQRx7WdDjLcQGiTa8YXDSBLzqdO0YOUQx9nwd18KCz8dyX2J WuQtbMgALssZsCzKJ3UQAC5a+d9dA9fCWQQ8//mvPr2BxFSdwfipt67QUyf/14sAO8Rl uAmLzNGFxT+GcEtsnmRhpu0tyiZlWAhmnlabd9B3fsG0kYTQIMZNoyn8g+JV4Udtebdr I2dR7nVpB4OUc2pXRWwWmfwahg4dVZLtPVye9BEmQ+1fBPkF0mqZF72n3VbvHDFpcLV/ imA4UvUQ7cyBumKV2+qkC6X1b7Ej5btej2gugZyEMeaigBNQlfBkbPEjrkoXS6G7cOkH 9CzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pxlNraflQ92wCBU3dsQwJHlD8zaHShnyVITA3dHRg0o=; b=SoqIwtmHgNlsQWmvgqgRL+5ezhCgP/6MS5D+aQ1DpP8eNpk174cKnBv+icaAug44WG HBiAcSCy9clZbOf8p8lQ0ZACU9jZbSeSTy9svmLQdQlLB9bAR+2oZgS8KSbTiFzeqsW6 UdIIwqrGl/aammUJcDAGVWsWZDKdKWuEpNu8qz7RPtIqYFWVeM24uTaT3ii61sbcrBuT IBMDn7WmqN87KRWdADen9rWPn0QXtz0ST09hYswtFG00k8rhsgsAGXaxTjnW/I3aytJV 7w9Uu1m3MQFPts1LTuIAw4BWnykuQMM6svrrprUlXy7FrOzxwP+6V+hU4+xp6ivXBa4D uogw== X-Gm-Message-State: AOAM5325l2FmvCEnSdAbrUquV1vFAa3RntMSy1eHLGa8GzmJ+gvGP6+v ei8KoZivT8e9U+3mYPZmfzi3/x1wSCZu8oNWqUIEwWHf9XQBNQ== X-Google-Smtp-Source: ABdhPJyEm7ZMD1LyBGTxy3zOya0YzMciznHW6gT5avf0BQK2k6SPZiV3kqqiO1h6J144z6fMml3lcsmM0xN1hIc4uT0= X-Received: by 2002:a67:d38e:: with SMTP id b14mr6357026vsj.34.1634827519351; Thu, 21 Oct 2021 07:45:19 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Thu, 21 Oct 2021 07:45:08 -0700 Message-ID: To: jmap@ietf.org Content-Type: multipart/alternative; boundary="0000000000008f603705ceddf142" Archived-At: Subject: [Jmap] draft-ietf-jmap-smime reference to RFC 5257 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, 21 Oct 2021 14:45:34 -0000 --0000000000008f603705ceddf142 Content-Type: text/plain; charset="UTF-8" Hi, me again, The IESG just evaluated draft-ietf-jmap-smime and the topic of its downref to RFC 5257 came up. There's nothing wrong with the downref, we just discussed the process in this particular case because there was prior talk that this RFC should be upgraded to the standards track. I seem to recall the vibe about this when I first asked about it was "Yes, we should do this, but not at this time." Accordingly, the IESG will be adding it to the downref registry. Just checking: Does JMAP plan to take up that work at some point, or is the sentiment more like "This is ripe for the standards track, and someone should do this someday, but not us"? Perhaps it's more aligned with EXTRA's charter? -MSK --0000000000008f603705ceddf142 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, me again,

The IESG just = evaluated draft-ietf-jmap-smime and the topic of its downref to RFC 5257 ca= me up.=C2=A0 There's nothing wrong with the downref, we just discussed = the process in this particular case because there was prior talk that this = RFC should be upgraded to the standards track.=C2=A0 I seem to recall the v= ibe about this when I first asked about it was "Yes, we should do this= , but not at this time."=C2=A0 Accordingly, the IESG will be adding it= to the downref registry.

Just checking: Does JMAP= plan to take up that work at some point, or is the sentiment more like &qu= ot;This is ripe for the standards track, and someone should do this someday= , but not us"?

Perhaps it's more aligned = with EXTRA's charter?

-MSK
--0000000000008f603705ceddf142-- From nobody Thu Oct 21 09:42:50 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 232083A0691 for ; Thu, 21 Oct 2021 09:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 q5-07X58OQA4 for ; Thu, 21 Oct 2021 09:41:58 -0700 (PDT) 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 8F2733A0646 for ; Thu, 21 Oct 2021 09:41:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id C8C0DA162 for ; Thu, 21 Oct 2021 18:41:51 +0200 (CEST) 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 6JRXSq5VvbeW for ; Thu, 21 Oct 2021 18:41:27 +0200 (CEST) Received: from [192.168.10.154] (b2b-109-90-161-242.unitymedia.biz [109.90.161.242]) (Authenticated sender: happel@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 1716CA06C for ; Thu, 21 Oct 2021 18:41:27 +0200 (CEST) To: jmap@ietf.org From: Hans-Joerg Happel Message-ID: Date: Thu, 21 Oct 2021 18:41:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Jmap] [Jmap for Sieve] Binary/blob vs. Inline 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, 21 Oct 2021 16:42:15 -0000 Hi, as in today's JMAP WG call, and in prior threads on this list, there is some design decision to take on which minimal API calls are required to read/write a Sieve script. The currently proposed procedure is non-atomic: READ SCRIPT: R1) obtain script "metadata" (including blobId) R2) obtain actual script using blobId WRITE SCRIPT: W1) upload actual script as blob (obtaining blobId) W2) set script "metadata" using SieveScript/set method We see two issues with this approach: 1) It is not atomic, which may cause orphans to exist; resp. will require clients (or server) to do cleanup tasks (e.g., removing blob if second write call fails) 2) The whole approach seems to *assume the existence of a (global) blob store*, which *might not hold in general* Point (2) has different implications for read and write: ========================= READ ========================= Assuming a JMAP backend might be heterogeneous (no single blob store; e.g: JMAP API encapsulating an email server and a separate Sieve server), the backend implementation might not "know" in step (R2) if a given blobId relates to an email attachment (to be obtained from mail store) or to a Sieve rule (to be obtained from rule store). There might be two workarounds here: * Encoding which blob store to look up in the blobId (e.g. using prefix: "sieve-123-123-123") * Managing email + Sieve backend as different JMAP accounts; each with a logically separate blob store (as recommend by Neil in today's call) => So, this seems manageable ========================= WRITE ========================= When agreeing that JMAP for Sieve should be capable to wrap arbitrary existing Sieve systems (which may persist its scripts in files, LDAP, Db etc.), one might encounter backends which do not have a blob storage available. Let's just assume, the underlying Sieve storage is some database (with a fixed schema), which requires a single INSERT for script name + content and that would otherwise fail with an integrity constraint error. In this situation, the current write process, as described above, would require the server-side JMAP for Sieve implementation to: * Accept blob object written by client and *store temporarily* (e.g., write on disk?) * Once the client calls "SieveScript/set", look up the blob file, read, merge + write to database => We'd argue that this process is both complex to implement plus it's not particularly elegant to create a need for storing a temporary file. It would therefore be good if it is possible to (alternatively?) submit the script inline in the "SieveScript/set" command instead of a blobid. Best, Hans-Joerg ps.: A more general question of the "write blob first" approach is (beyond just uploading Sieve scripts) in how far quotas are respected. If blob storage can be used for all types of data, but quota (both total and max-element-size) may differ for email attachments, Sieve scripts or files - how is the initial blob storage supposed to "know" which quota to check against? => This seems to be addressed by a separate quota for unreferenced blobs, which includes size and item count [1]. This seems not entirely elegant, if clients can upload large chunks of data based on a high "blob quota", but only learn from a subsequent command, that the server won't accept the previously uploaded file due to further type-specific quotas. Such things could e.g., cause trouble for a brute-force migration client, which concurrently uploads large emails or files, and which (due to imperfect implementation) keeps submitting data into the blob store, even if email or files are actually already overquota. Probably not a very strong concern, but one might alternatively think about a way in which users signal their later usage intent (e.g. "email attachment") at blob upload time, so that the server can reject early? [1] https://jmap.io/spec-core.html#binary-data- "The server SHOULD use a separate quota for unreferenced blobs to the account’s usual quota." -- audriga GmbH Durlacher Allee 47 76131 Karlsruhe Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 support@audriga.com https://www.audriga.com Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142 From nobody Thu Oct 21 16:31:42 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 4F3A13A0E7B for ; Thu, 21 Oct 2021 16:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=w5f6Z7Td; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mXeh12wa 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 Sb9GzYTxZgtE for ; Thu, 21 Oct 2021 16:31:35 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9253A0E7A for ; Thu, 21 Oct 2021 16:31:34 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9C98B3201126 for ; Thu, 21 Oct 2021 19:31:33 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Thu, 21 Oct 2021 19:31:33 -0400 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=RZ5U4Gs Ys2chMOR8vLDnqljiEAfRE+HIJO3hCB4oFLE=; b=w5f6Z7Td/iB/fBa1YjNG0Dl AqVg2bLn5kberngROHVS4jr+uhQ/ou/HcuPc15e+J4iNS+7Zc5yGx456IidqDZV3 y2wzsmr9IJWFCFMheGdOYS+3VD/ZEnzwjXa+hzKF5zIdMzbkJM3DiIWR8RXwzeLJ kC5GiZ5BDeI8kcyp1qOIRDMGc0A/SSvKA9erqPn4yxX8es6gsEws0G7OEvKercn7 U/q0FqtJZQ931IPtbXV1tji5CUDxHsPJstBLS50VMnzFcB7Iu9TPLSgQfLuPyKbG MifTJezOCxsUMRjsejFFeHdXuoV2kFSIOpIkfTbdES+rxi5FMEF3/7cs/P8o5CQ= = 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=RZ5U4G sYs2chMOR8vLDnqljiEAfRE+HIJO3hCB4oFLE=; b=mXeh12waeanElUuLBDxAlQ gXdrnR3sSlToaueK7IesKLFttA9pI5sLgTJCmdISmIbDx4mWHG/aJXfybs03RMIm 4PPePmvnEMYKmmTvfkNk4LAQ3GeUNk1fF4K9TpJgNlBqE/A1j4aN2jehIVTJZVTP EenF0K5qIb8f3FP1BogW+Qz/1fo3ple5FotscJKhDbpPVOtMCprR4Q+XBySyy4qn van19yINpGKr3YPvdAWIuRcROs/oreCTwSX+34F4jlCWJI7SF2JgqKyaktZYqOOr TlReLz2Nu60eokNSnO6Jb7Pds6VkQNM5OLYEWiEUTtDVlKFhSKPi5va9mfBRLwHA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvjedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvudeuieehgf dvheeuueejjeeuudfgiefgveetfeelteeffffgtdejjefgueduvdenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0B247AC03DB; Thu, 21 Oct 2021 19:31:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1369-gd055fb5e7c-fm-20211018.002-gd055fb5e Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 22 Oct 2021 10:31:12 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=40838143b53b479299c745b86da4f176 Archived-At: Subject: Re: [Jmap] draft-ietf-jmap-smime reference to RFC 5257 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, 21 Oct 2021 23:31:41 -0000 --40838143b53b479299c745b86da4f176 Content-Type: text/plain On Fri, Oct 22, 2021, at 01:45, Murray S. Kucherawy wrote: > Hi, me again, > > The IESG just evaluated draft-ietf-jmap-smime and the topic of its downref to RFC 5257 came up. There's nothing wrong with the downref, we just discussed the process in this particular case because there was prior talk that this RFC should be upgraded to the standards track. I seem to recall the vibe about this when I first asked about it was "Yes, we should do this, but not at this time." Accordingly, the IESG will be adding it to the downref registry. > > Just checking: Does JMAP plan to take up that work at some point, or is the sentiment more like "This is ripe for the standards track, and someone should do this someday, but not us"? > > Perhaps it's more aligned with EXTRA's charter? Yes, I'd say that EXTRA is the place to do the work. I'd be particularly interested in having feedback from servers that don't implement it about why they haven't, if we were to do more than just bless the exact existing design as non-experimental. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --40838143b53b479299c745b86da4f176 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Oct 22, 2021, at 01:45, Murray S. Kucherawy wrote:=
Hi, me again,

The IESG just evaluate= d draft-ietf-jmap-smime and the topic of its downref to RFC 5257 came up= .  There's nothing wrong with the downref, we just discussed the pr= ocess in this particular case because there was prior talk that this RFC= should be upgraded to the standards track.  I seem to recall the v= ibe about this when I first asked about it was "Yes, we should do this, = but not at this time."  Accordingly, the IESG will be adding it to = the downref registry.

Just checking: Does J= MAP plan to take up that work at some point, or is the sentiment more li= ke "This is ripe for the standards track, and someone should do this som= eday, but not us"?

Perhaps it's more aligne= d with EXTRA's charter?

Yes, I'd say t= hat EXTRA is the place to do the work.  I'd be particularly interes= ted in having feedback from servers that don't implement it about why th= ey haven't, if we were to do more than just bless the exact existing des= ign as non-experimental.

=
Bron.

--
  Bron Gondwana, CEO, Fast= mail Pty Ltd
  brong@fastmailteam= .com


--40838143b53b479299c745b86da4f176-- From nobody Fri Oct 22 02:58:23 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 26B243A07AA for ; Fri, 22 Oct 2021 02:58:19 -0700 (PDT) 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 (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 dcMRiK4Q1xdu for ; Fri, 22 Oct 2021 02:58:14 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 189183A07B2 for ; Fri, 22 Oct 2021 02:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1634896692; d=isode.com; s=june2016; i=@isode.com; bh=QGynNPQB+8NVeoiqsdQms7GAApKmYXRuHuQxy92CAaI=; 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=unHuhF3PdPMDH8Vk1gn0cK10iNGZzrv5hXsuKOzcQmfRPjIN42mcggo0HhiF/PB2v3TtGf xSxfoXJzUgOxmc94vAM3TjG+xAc0pS0PpbZFXsvEmVAQB5l/DvGA6UHou4tVmUC7I66Roz /5xgki10xYQjFHCAc2MyzGm47eI78PY=; Received: from [192.168.1.222] (host5-81-100-13.range5-81.btcentralplus.com [5.81.100.13]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 22 Oct 2021 10:58:12 +0100 To: Bron Gondwana , jmap@ietf.org References: From: Alexey Melnikov Message-ID: Date: Fri, 22 Oct 2021 10:58:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A88738E48D450D4CBCEC9DE7" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] draft-ietf-jmap-smime reference to RFC 5257 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: Fri, 22 Oct 2021 09:58:20 -0000 --------------A88738E48D450D4CBCEC9DE7 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable On 22/10/2021 00:31, Bron Gondwana wrote: > On Fri, Oct 22, 2021, at 01:45, Murray S. Kucherawy wrote: >> Hi, me again, >> >> The IESG just evaluated draft-ietf-jmap-smime and the topic of its=20 >> downref to RFC 5257 came up.=C2=A0 There's nothing wrong with the downref= ,=20 >> we just discussed the process in this particular case because there=20 >> was prior talk that this RFC should be upgraded to the standards=20 >> track.=C2=A0 I seem to recall the vibe about this when I first asked abou= t=20 >> it was "Yes, we should do this, but not at this time." Accordingly,=20 >> the IESG will be adding it to the downref registry. >> >> Just checking: Does JMAP plan to take up that work at some point, or=20 >> is the sentiment more like "This is ripe for the standards track, and=20 >> someone should do this someday, but not us"? >> >> Perhaps it's more aligned with EXTRA's charter? > > Yes, I'd say that EXTRA is the place to do the work. Agreed. > I'd be particularly interested in having feedback from servers that=20 > don't implement it about why they haven't, if we were to do more than=20 > just bless the exact existing design as non-experimental. Implementation complexity and the need to have some kind of database was=20 a concern for me when I looked at implementing this. I suppose if there=20 are clients that really need this, I can be swayed. Best Regards, Alexey --------------A88738E48D450D4CBCEC9DE7 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 22/10/2021 00:31, Bron Gondwana wrote:

On Fri, Oct 22, 2021, at 01:45, Murray S. Kucherawy wrote:
Hi, me again,

The IESG just evaluated draft-ietf-jmap-smime and the topic of its downref to RFC 5257 came up.=C2=A0 There's nothing wrong with the downref, we just discussed the process in this particular case because there was prior talk that this RFC should be upgraded to the standards track.=C2=A0 I seem to recall the vibe about this when I first asked about it was "Yes, we should do this, but not at this time."=C2=A0 Accordingly, the IESG will be adding it to the downref registry.

Just checking: Does JMAP plan to take up that work at some point, or is the sentiment more like "This is ripe for the standards track, and someone should do this someday, but not us"?

Perhaps it's more aligned with EXTRA's charter?

Yes, I'd say that EXTRA is the place to do the work.
Agreed.
I'd be particularly interested in having feedback from servers that don't implement it about why they haven't, if we were to do more than just bless the exact existing design as non-experimental.

Implementation complexity and the need to have some kind of database was a concern for me when I looked at implementing this. I suppose if there are clients that really need this, I can be swayed.

Best Regards,

Alexey

--------------A88738E48D450D4CBCEC9DE7-- From nobody Fri Oct 22 09:23:48 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 1A2CE3A0FD3; Fri, 22 Oct 2021 09:23:14 -0700 (PDT) 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, NICE_REPLY_A=-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 (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 Rb0VJmU3rTxy; Fri, 22 Oct 2021 09:23:09 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 64F373A10EF; Fri, 22 Oct 2021 09:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1634919787; d=isode.com; s=june2016; i=@isode.com; bh=jPV8glWDvIT4m4TgKEchAXlh+L7rnvIYVoAqci4s8AE=; 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=YHeOBk66DpUfdhoI8f7NeGeWFKsAA7MELr1zwh1mFZ/AuaP1MRyfwPffDoIslVSmj/uaNW cXDXNMIugDgKZv3ICagw71OD6U0vfvLaDHUr/U+3b/buj3z51dxrcpfjYMNhuUaYC+zHH4 uwUDDXuKnPpAPxjmdUCsrQsmbuIPPH4=; Received: from [192.168.1.222] (host5-81-100-13.range5-81.btcentralplus.com [5.81.100.13]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 22 Oct 2021 17:23:07 +0100 From: Alexey Melnikov To: Benjamin Kaduk , The IESG Cc: jmap@ietf.org, draft-ietf-jmap-smime@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com References: <163468289442.773.9422623149409906055@ietfa.amsl.com> Message-ID: Date: Fri, 22 Oct 2021 17:23:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <163468289442.773.9422623149409906055@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Benjamin Kaduk'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: Fri, 22 Oct 2021 16:23:15 -0000 Hi Ben, Thank you for your throught comments. On 19/10/2021 23:34, Benjamin Kaduk via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Are we asserting that the "smime" prefix for property names (and > "hasSmime", etc.) relates only to S/MIME signing? How might S/MIME > encryption be handled if support is added in the future? My implementation actually does automatic decryption as well, so this should work for signed and encrypted messages. But you are right that the document doesn't make it very clear that this is an extension point. > I see that the opsdir reviewer asked about whether this document should > have an "Updates:" relationship with RFC 8621. I'm not sure I see a > need for it, myself, but would be interested in hearing the stance of > the authors/WG. > > Section 4.1 > > signed: S/MIME signed message, but the signature was not yet > verified. Some servers might not attempt to verify a signature > until a particular message is requested by the client. JMAP > servers compliant with this document SHOULD return "signed/ > verified" or "signed/failed" instead of this signature status. > > I'd suggest adding something like "SHOULD attempt verification and > return", just to reiterate that servers don't get to arbitrarily claim > verification/failure without doing the verification. Added, thank you. > smimeErrors: "String[]|null". null signifies that the message doesn't > contain any signature or that there were no errors when verifying the > S/MIME signature. (I.e., this property is non null only when the > corresponding "smimeStatus" response property value is "signed/ > failed".) [...] > > Would some hypothetical future smimeStatus type be compatible with a > non-null smimeErrors? This phrasing seems to preclude such a > possibility. Good point. I clarified that future extensions can extend this list. In my implementation I have a separate smimeWarnings, but it is not included in this draft. > This might result in the following response: > > [["Email/get", { > "accountId": "abc", > "state": "41234123231", > > I note that this "state" value is used in RFC 8621 when retriving a > similar example message. As far as I recall this state value represents > only the state of Email objects on the server overall (with some caveat > about visibility to the user), and so it is not inherently inconsistent > to use the same value across examples ... but it might be worth picking > a new value anyway. > > The reuse of the message "id" for a message with a different > "receivedAt" date, subject, etc., though, seems less defensible than > reusing "state". Ok, I've modified id/state in examples. > Example 2: Retrieval of minimal information about a message, > [...] > ["Email/get", { > "ids": [ "af123u123" ], > "properties": [ "mailboxIds", "from", "subject", "date", > "smimeStatus", "smimeErrors", "smimeVerifiedAt" ] > }, "#1"] > > Is reusing the method call id allowed? Are you referencing "#1"? > Section 4.2 > > * *hasVerifiedSmime*: "Boolean". If "hasVerifiedSmime" has the > value true, only messages with "smimeStatus" equal to "signed/ > verified" match the condition. If "hasVerifiedSmime" has the > value false, only messages with "smimeStatus" not equal to > "signed/verified" (including the value null) match the condition. > > Might some future status value (say, "signed+encrypted/verified") also > need to match as "verified S/MIME"? This phrasing seems to preclude > such a possibility. I tried to clarify this by adding a section on smimeStatus extensibility, plus some text here. Best Regards, Alexey From nobody Fri Oct 22 09:28:51 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 AA1073A0045; Fri, 22 Oct 2021 09:28:49 -0700 (PDT) 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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163492012959.5465.15094150404564426766@ietfa.amsl.com> Date: Fri, 22 Oct 2021 09:28:49 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-smime-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: Fri, 22 Oct 2021 16:28:50 -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-10.txt Pages : 10 Date : 2021-10-22 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-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 03:26:49 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 0E85A3A0774; Mon, 25 Oct 2021 03:26:44 -0700 (PDT) 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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163515760400.3278.12879232854870114992@ietfa.amsl.com> Date: Mon, 25 Oct 2021 03:26:44 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-tasks-02.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, 25 Oct 2021 10:26:44 -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 for Tasks Authors : Joris Baum Hans-Joerg Filename : draft-ietf-jmap-tasks-02.txt Pages : 18 Date : 2021-10-25 Abstract: This document specifies a data model for synchronizing task data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-tasks/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-tasks-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-tasks-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 21:43:19 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 A259D3A0DD9 for ; Mon, 25 Oct 2021 21:43:17 -0700 (PDT) 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=BewIASq4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TccHO0oN 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 oZvVbvkEdtg0 for ; Mon, 25 Oct 2021 21:43:12 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A6B3A0DD6 for ; Mon, 25 Oct 2021 21:43:12 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C620D5C0383 for ; Tue, 26 Oct 2021 00:43:10 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Tue, 26 Oct 2021 00:43:10 -0400 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=zdGYYFE 9Tv0xZd2cz6UFvh0oC49zfY4unv9ZnO6Bogc=; b=BewIASq4geO/yHv9Hm9d7JO uhb6pGgpSq6ZlkTd08HhI48q9pb+cnBUXiTcDFk1Tmxqpij5Z8Qv7g5FJ//lpNzb Nl5SS4PD5qT9dw6Ilns5/MREjtFFV9KzU26DUNcdWJajuw14F/73XK06OIRG9KXV uFjMzLQbFpl51FMEUk7YJt3JLlCRaS/RL8+ZZiUcSXDV0/z+m4ggG11OCJgvTIoV 59gAZoWDcE3qqh/Bc5SkCr1yN/gb/+Il5kRObeplY/kaj+3dfiqDcPh441+2JjY2 Kf/IvOLiYMxKWWxXy9MIeHKUO52mD82f7fbcqoruJsEUZ2FS6JX090vCcMZ+2yQ= = 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=zdGYYF E9Tv0xZd2cz6UFvh0oC49zfY4unv9ZnO6Bogc=; b=TccHO0oNIEpPN7+ST7X5Gb v0WZMzlv4JjdSxxoGxYGfp8Pey1Qm0rHZlN3XoePTNbLreGxCH0GayUIHUeWJACn 7ygrr/EgjkUP/CKOi5qEjvFoCRYS6tzNMWbCWDwgKEXUCCCpKH0bSEzHVHnii8kB Av6t8dJUd/0fPA1YGab4C/Ln8K8fxJClwaqN7FSrOr6BIr2lfcfw53ysdKuDMhht Y4kRkEjmV0lDQ8uNIjV0aFvwGqyy4zE7ibqdsGwPQm4PwZOzINQ+G2DAlvklWqKR mFG5obKyOTNxiVxgdgkHVZC3QpFb3htFuT+ZeGpU3d9Ozx7IgrFq9sWu80Ysiunw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefiedgjeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeehuefhudejtdeiveekvdfhfffgleeflefhfeekhefhkeel kefhfeeufeevffejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 92600AC03DB; Tue, 26 Oct 2021 00:43:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1399-ga34296eb8f-fm-20211021.002-ga34296eb Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 26 Oct 2021 15:43:09 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=99d3bbf915b147c1a8dc71c67e6f8ddf Archived-At: Subject: Re: [Jmap] [Jmap for Sieve] Binary/blob vs. Inline 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, 26 Oct 2021 04:43:18 -0000 --99d3bbf915b147c1a8dc71c67e6f8ddf Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, 22 Oct 2021, at 03:41, Hans-Joerg Happel wrote: > =3D> We'd argue that this process is both complex to implement plus it= 's=20 > not particularly elegant to create a need for storing a temporary file= .=20 Depends how you look at it; it *is* elegant to have a single consistent = method for referencing binary data. I think the answer here if you are t= rying to add support on a legacy system where this is difficult is to ma= ke the Sieve its own account. Then when you upload a blob to that accoun= t you know it can only be a sieve script, which should allow you to do s= omething reasonable. > It would therefore be good if it is possible to (alternatively?) submi= t=20 > the script inline in the "SieveScript/set" command instead of a blobid. Using Bron's blob extension you can create a blob in-band and then backr= eference it from the SieveScript/set command. But I wouldn't want to say= that was the only way you could do it; that breaks the consistency of t= he blob handling. > ps.: A more general question of the "write blob first" approach is=20 > (beyond just uploading Sieve scripts) in how far quotas are respected.=20 > If blob storage can be used for all types of data, but quota (both tot= al=20 > and max-element-size) may differ for email attachments, Sieve scripts = or=20 > files - how is the initial blob storage supposed to "know" which quota=20 > to check against? You just want a quota somewhat larger than the largest single file the u= ser would be permitted to upload for any of these contexts.=20 =E2=80=94Neil. --99d3bbf915b147c1a8dc71c67e6f8ddf Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, 22 Oct = 2021, at 03:41, Hans-Joerg Happel wrote:
=3D> We'd argue that this process is bo= th complex to implement plus it's 
not particularly e= legant to create a need for storing a temporary file. 

Depends how you look at it; it is e= legant to have a single consistent method for referencing binary data. I= think the answer here if you are trying to add support on a legacy syst= em where this is difficult is to make the Sieve its own account. Then wh= en you upload a blob to that account you know it can only be a sieve scr= ipt, which should allow you to do something reasonable.
It would the= refore be good if it is possible to (alternatively?) submit 
the script inline in the "SieveScript/set" command instead of a = blobid.

Using Bron's blob exte= nsion you can create a blob in-band and then backreference it from the S= ieveScript/set command. But I wouldn't want to say that was the only way= you could do it; that breaks the consistency of the blob handling.
<= /div>

= ps.: A more general question of the "write blob first" approach is =
(beyond just uploading Sieve scripts) in how far quotas a= re respected. 
If blob storage can be used for all ty= pes of data, but quota (both total 
and max-element-s= ize) may differ for email attachments, Sieve scripts or 
<= div>files - how is the initial blob storage supposed to "know" which quo= ta 
to check against?

=
You just want a quota somewhat larger than the largest single= file the user would be permitted to upload for any of these contexts. <= br>

=E2=80=94Neil.
--99d3bbf915b147c1a8dc71c67e6f8ddf-- From nobody Thu Oct 28 08:45:06 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 351783A0BFD; Thu, 28 Oct 2021 08:45:00 -0700 (PDT) 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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <163543590014.19884.13558809691207297118@ietfa.amsl.com> Date: Thu, 28 Oct 2021 08:45:00 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-blob-05.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, 28 Oct 2021 15:45:00 -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-05.txt Pages : 17 Date : 2021-10-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-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-blob-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 29 03:06:33 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 7CDCE3A1039 for ; Fri, 29 Oct 2021 03:06:32 -0700 (PDT) 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=JwyCCAX5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Yf3q9Uql 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 B_ZRyatQO6Ao for ; Fri, 29 Oct 2021 03:06:27 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2E73A1038 for ; Fri, 29 Oct 2021 03:06:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4D2085C006D for ; Fri, 29 Oct 2021 06:06:26 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Fri, 29 Oct 2021 06:06:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=dieWgLH4sL9D+c+RiXHIyLKCB2U53+ltClVm3oe koeI=; b=JwyCCAX5rBAF1riLQz10X8qiSImriHpJn5kR5jh599jOH7JmgzQHV7K UbcnSL7bTDxE2IuMPp/QCkiCgZL0rcjjy5J/ccajpw0YzXBobzu9SES92k3vulZi vKWFIx0DvROB159oXSoz9Abu4Hmpdvg39BH5X9RxO73yn13wa5lRNGCA/RKu6Arl Q14dylkbrdOhOXlciBM+LfhMdixKQngSWSFyFZtPhscOXSKHAy50i1IWP3sNn3aA WcctmCQSk/kvnFEait8gekapnYYN0vC6HbfVXHixLsK2lZ1YPTKx1mWdG+18S2U5 ckdV0luvmcbkD/JaWrPo00Js40QqGdg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=dieWgLH4sL9D+c+RiXHIyLKCB2U53 +ltClVm3oekoeI=; b=Yf3q9UqlH6VYk1kizwJWb1/0R16wG5Ef4CWbp4TGpxVp9 MRBbDK11ECF9NRVa/X+izA5haDk5VkjoC28dEAodUBerkVm439N5lpJlmtLEGkBq Z2wF0POi23Vt91oOQI1j62GP2JisnzGYVc8uAlTC8Xs19EnvWvM0C+pOhijYzbtZ yFquDvY03ZRwfwvLsmsLA7EGcFGFszIv+YnP6D7MN04UJAWbxdw2Oz/sgBuX9JIw Qxd2bFmUNsuDyiAgMqkcAkRiWvD1lkDc9SJqLN59xOVvQC6sEO2AMXe5U7/BFPsf 47guy3wFd8aZk1q94EW+8tYdxPQ08uokTVVv3IdkA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdeghedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhjeehkeejkeehve eutdejteeihffffeduiedttdejhfelteevueehudeltdeuffenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 223ECAC0DD1; Fri, 29 Oct 2021 06:06:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1399-ga34296eb8f-fm-20211021.002-ga34296eb Mime-Version: 1.0 Message-Id: Date: Fri, 29 Oct 2021 21:04:23 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=f5bf1fadf62b48d3b94ed32f15d0aa73 Archived-At: Subject: [Jmap] Blob draft updated 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: Fri, 29 Oct 2021 10:06:33 -0000 --f5bf1fadf62b48d3b94ed32f15d0aa73 Content-Type: text/plain Hi all, Thanks to Murray for getting the -05 draft uploaded for me during the embargo period, because I managed to miss uploading it by a few hours during the DDoS madness that Fastmail suffered last week. The latest version fixes the missing bits and pieces. I'd love a review or two before IETF112 - particularly on the topic of "are the examples good/useful/sufficient"? https://datatracker.ietf.org/doc/draft-ietf-jmap-blob/ Thanks, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --f5bf1fadf62b48d3b94ed32f15d0aa73 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,
Thanks to Murray for getting t= he -05 draft uploaded for me during the embargo period, because I manage= d to miss uploading it by a few hours during the DDoS madness that Fastm= ail suffered last week.

<= /div>
The latest version fixes the miss= ing bits and pieces.  I'd love a review or two before IETF112 - par= ticularly on the topic of "are the examples good/useful/sufficient"?
=

<= div style=3D"font-family:Arial;">
Thanks,

Bron.

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


--f5bf1fadf62b48d3b94ed32f15d0aa73--