From nobody Tue Dec 1 02:37:17 2020 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 55E653A10CC for ; Tue, 1 Dec 2020 02:37:15 -0800 (PST) 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, 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 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 wmVUo5uFc5Hg for ; Tue, 1 Dec 2020 02:37:13 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639783A03EC for ; Tue, 1 Dec 2020 02:37:12 -0800 (PST) Received: from [10.75.246.26] (reverse.completel.net [92.103.166.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id 458B03F3C2 for ; Tue, 1 Dec 2020 11:37:08 +0100 (CET) To: jmap@ietf.org References: <8df9abc8-4c5d-47da-9966-b9646561e286@dogfood.fastmail.com> X-LINAGORA-Copy-Delivery-Done: 1 From: =?UTF-8?Q?Rapha=c3=abl_Ouazana?= Message-ID: <17a0c929-66bc-71f8-54bd-cbf4faa8181e@linagora.com> Date: Tue, 1 Dec 2020 11:37:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8df9abc8-4c5d-47da-9966-b9646561e286@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------1F5C16088F4952037120AB85" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Question: Mandate core capability on each API call? 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, 01 Dec 2020 10:37:15 -0000 This is a multi-part message in MIME format. --------------1F5C16088F4952037120AB85 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello, What about: The server MUST only follow the specifications that are opted into and behave as though it does not implement anything else when processing a request. Raphaël. Le 01/12/2020 à 05:18, Neil Jenkins a écrit : > Hi Benoit, > > Good question! I thought we had specified this, but I can't see it in > the final draft. I don't see any particular downside to making it > optional, but perhaps someone else has an argument as to why it should > be mandatory? Whatever we decide, it is probably worth an erratum for > the benefit of future implementors. > > Neil. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --------------1F5C16088F4952037120AB85 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,

What about:

The server MUST only follow the specifications that are opted into and behave as though it does not implement anything else when processing a request.

Raphaël.

Le 01/12/2020 à 05:18, Neil Jenkins a écrit :
Hi Benoit,

Good question! I thought we had specified this, but I can't see it in the final draft. I don't see any particular downside to making it optional, but perhaps someone else has an argument as to why it should be mandatory? Whatever we decide, it is probably worth an erratum for the benefit of future implementors.

Neil.

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--------------1F5C16088F4952037120AB85-- From nobody Thu Dec 3 21:19:41 2020 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 554E53A0B26 for ; Thu, 3 Dec 2020 21:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=CEtkXj+f; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eQBrGtiB 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 fZHvD2OyeQ3g for ; Thu, 3 Dec 2020 21:19:37 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 123EE3A0ACB for ; Thu, 3 Dec 2020 21:19:36 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 32FE65C01E9 for ; Fri, 4 Dec 2020 00:19:36 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Fri, 04 Dec 2020 00:19:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=AbQrXw9 6QjpB5ELPMYqF/hhs1sE1x+XHcwcrszmp5sw=; b=CEtkXj+fd7db0SOo8MNT4Hm ugIPU9rbsBSOF+aVio6g0Q9Abm3Upp+Fx6tx/BAzmIxahr1xxGb9L86/TBGtzOxp QFznjm7GN64MUAsanCr6upjDmJVuOr63Hs93nPzTITyluxuJSObmnyMXUErWUxk4 ddwELHnJY4kdrIbIxUjoY3+7NYYnI2Ouzctnt4riUtQ7VnB+Xcd53d+T2cyb0Qn/ JlGVWNCa9raYYDSLwbsyHyVSEQ25B4RMaYxVfBV5PxDVk7SGmaCjWLqOKGZGbrsI n0MUoJKaO3V3nrf0pI6sTQGRv6DvmzdXUH9wECEuxrax7JlxB836yehcbwZb7Pw= = 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=AbQrXw 96QjpB5ELPMYqF/hhs1sE1x+XHcwcrszmp5sw=; b=eQBrGtiB5+Mod9/LGEjyXH 6mwkZDpC/p589wFUrcPRzOSjnNaURxfiTYQ52KJ0W7J/kA57wBFfTJdRhEQczutw PaJlpT0fB+vqTsdQ9nuuz6+b8ebILhvl1pUmtdcbQCa6LecWlbGrcxqojJk7hNPw ww4YYY+DyFbINgR4U0LD0BlJjhlICY3RyvkrfEWcdK5dG+dgO0gKJBsSWOALII/E aQnTGE5Qfyz0AI6SpLxTRTaBlzY+Xhkszmi5THaYI4b8EGrwjCBQT6DiJD1wKY3o 1YtjYD9kx0WcTRe0h0nRa0daIdSZ20wWsP+KEkVA/DcOEmjlH2reksaSIkvB8wOQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeijedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeehuefhudejtdeiveekvdfhfffgleeflefhfeekhefhkeel kefhfeeufeevffejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9063D180093; Fri, 4 Dec 2020 00:19:35 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <722e4258-1b8a-4b43-9a1a-2b8b910484b9@beta.fastmail.com> In-Reply-To: <17a0c929-66bc-71f8-54bd-cbf4faa8181e@linagora.com> References: <8df9abc8-4c5d-47da-9966-b9646561e286@dogfood.fastmail.com> <17a0c929-66bc-71f8-54bd-cbf4faa8181e@linagora.com> Date: Fri, 04 Dec 2020 16:19:35 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=4c3934027cc44468a3ff39d588a55c09 Archived-At: Subject: Re: [Jmap] Question: Mandate core capability on each API call? 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, 04 Dec 2020 05:19:38 -0000 --4c3934027cc44468a3ff39d588a55c09 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 1 Dec 2020, at 21:37, Rapha=C3=ABl Ouazana wrote: > What about: > The server MUST only follow the specifications that are opted into and= behave as though it does not implement anything else when processing a = request.=20 Sure, this applies to anything other than the core spec. But if you are = obeying this text, you are already implementing RFC8620 so it would be a= bit of a circular argument to imply that this means you must include th= e core capability in the using array in order to support 8620! Neil. --4c3934027cc44468a3ff39d588a55c09 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, 1 = Dec 2020, at 21:37, Rapha=C3=ABl Ouazana wrote:

What about:

The server MUST= only follow the specifications that are opted into and behave as though it does not implement anything else when= processing a request.


Sur= e, this applies to anything other than the core spec. But if you are obe= ying this text, you are already implementing RFC8620 so it would be a bi= t of a circular argument to imply that this means you must include the c= ore capability in the using array in order to support 8620!

Neil.
--4c3934027cc44468a3ff39d588a55c09-- From nobody Fri Dec 4 05:08:22 2020 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 258423A0C8E for ; Fri, 4 Dec 2020 05:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Ix5cqSvOXrMf for ; Fri, 4 Dec 2020 05:08:18 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6313A0C88 for ; Fri, 4 Dec 2020 05:08:17 -0800 (PST) Received: from [192.168.0.37] (91-168-246-100.subs.proxad.net [91.168.246.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id 3712D3FE64 for ; Fri, 4 Dec 2020 14:08:14 +0100 (CET) To: jmap@ietf.org References: <8df9abc8-4c5d-47da-9966-b9646561e286@dogfood.fastmail.com> <17a0c929-66bc-71f8-54bd-cbf4faa8181e@linagora.com> <722e4258-1b8a-4b43-9a1a-2b8b910484b9@beta.fastmail.com> X-LINAGORA-Copy-Delivery-Done: 1 From: =?UTF-8?Q?Rapha=c3=abl_Ouazana?= Message-ID: <6252ac04-caf9-6c32-eb29-8f075851dffc@linagora.com> Date: Fri, 4 Dec 2020 14:08:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <722e4258-1b8a-4b43-9a1a-2b8b910484b9@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------31BC74F98D78A5C9421E5772" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Question: Mandate core capability on each API call? 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, 04 Dec 2020 13:08:20 -0000 This is a multi-part message in MIME format. --------------31BC74F98D78A5C9421E5772 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 04/12/2020 à 06:19, Neil Jenkins a écrit : > On Tue, 1 Dec 2020, at 21:37, Raphaël Ouazana wrote: >> >> What about: >> >> The server MUST only follow the specifications that are opted into >> and behave as though it does not implement anything else when >> processing a request. >> > > Sure, this applies to anything other than the core spec. But if you > are obeying this text, you are already implementing RFC8620 so it > would be a bit of a circular argument to imply that this means you > must include the core capability in the using array in order to > support 8620! For now yes but this is also "for compatibility with future versions of JMAP". If a future client wants to communicate with a future server, it would have to use "urn:ietf:params:jmapv2:core" and would be fine to not have "urn:ietf:params:jmap:core" taken by default, no? Raphaël. --------------31BC74F98D78A5C9421E5772 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


Le 04/12/2020 à 06:19, Neil Jenkins a écrit :
On Tue, 1 Dec 2020, at 21:37, Raphaël Ouazana wrote:

What about:

The server MUST only follow the specifications that are opted into and behave as though it does not implement anything else when processing a request.


Sure, this applies to anything other than the core spec. But if you are obeying this text, you are already implementing RFC8620 so it would be a bit of a circular argument to imply that this means you must include the core capability in the using array in order to support 8620!


For now yes but this is also "for compatibility with future versions of JMAP". If a future client wants to communicate with a future server, it would have to use "urn:ietf:params:jmapv2:core" and would be fine to not have "urn:ietf:params:jmap:core" taken by default, no?

Raphaël.

--------------31BC74F98D78A5C9421E5772-- From nobody Mon Dec 7 16:54:28 2020 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 E6AEA3A0D35 for ; Mon, 7 Dec 2020 16:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=nIoSVvtx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hI47mchU 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 mpVIg2Pov3XJ for ; Mon, 7 Dec 2020 16:54:26 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA023A0D32 for ; Mon, 7 Dec 2020 16:54:26 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 5CF867BE for ; Mon, 7 Dec 2020 19:54:24 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Mon, 07 Dec 2020 19:54:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=Nj98qgr IChBASx5vBWHEYl/1lT7V6WlRXSx0qvhbAy0=; b=nIoSVvtxDVwJB2yK9qWR1OP erpYVCca61P3Cdju/PCmlYB3Agvx5qpJs2Y2fFP/J0zx7ha0d5vRrTSXI7iFWNVQ 9nLbC0lKlX3A4UDIEoHm6YERjIec03rruH9A1DfxgO0B2P5wFy5akWHMipWbrwHP VKscLvs/w9Avpdwm5uAw1TCGeNIscFpzInEKqDcmnQ4Y+rXka9SSmh1vY1ZgKl9M 3lyZOURPnAaxDbjE99dBRvfQjOJikF7YDuo3msiDirvDvnNRVy5hLuvu3rzP4jHH 1TJINsoFoyni4tK4M05Ak6zkv9GCEM82Di1cHRLaa5oVppIPMTBuiXH5MP7z4MA= = 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=Nj98qg rIChBASx5vBWHEYl/1lT7V6WlRXSx0qvhbAy0=; b=hI47mchUU9ef0GlXkeHWYJ xlG40D0M3RfgdR0ccu9DoHNj73w0wWksp0jrb1CDjCOei7xyBKNcwDx8qc+mi+Lz y3AFhLkFQ8dNw51/DQ6YGZtqscsiojXND0NapTDp/Llq9ksWBQsxK0XiQXudx4Z9 lZx7i068XqoRw1geZGeRv1ysLK4UtfZlNDB20dGzbOFrdi2e844si8SwbyY0eYtY 1t2xx4MwQAWOwyB1GKpWvG1D774suWbw/nPNH29HM0whAQtYrC6+z82TVWkq/myE ivpkEg0LFPXSjU2zXBmD4U++PvdFXptFXAT8+Hx4wXc/QhP0ijdT0mdH8LMeORUg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejhedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeejuddttdeuieffuefgjeeuuefhhfeiteehheefjeefteev ffduieeiudehgfdtteenucffohhmrghinhepihgvthhfrdhorhhgpdhgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehn vghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 74EA3180093; Mon, 7 Dec 2020 19:54:23 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <82ad0634-847c-4cd3-be8c-e1a6dbba9da5@beta.fastmail.com> In-Reply-To: <6252ac04-caf9-6c32-eb29-8f075851dffc@linagora.com> References: <8df9abc8-4c5d-47da-9966-b9646561e286@dogfood.fastmail.com> <17a0c929-66bc-71f8-54bd-cbf4faa8181e@linagora.com> <722e4258-1b8a-4b43-9a1a-2b8b910484b9@beta.fastmail.com> <6252ac04-caf9-6c32-eb29-8f075851dffc@linagora.com> Date: Tue, 08 Dec 2020 11:54:13 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=b6b17bcaa09d472db8877e5abd31490f Archived-At: Subject: Re: [Jmap] Question: Mandate core capability on each API call? 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, 08 Dec 2020 00:54:28 -0000 --b6b17bcaa09d472db8877e5abd31490f Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable OK, I've found our previous discussion of this and it looks like the c= onclusion then was to require it to be explicit, because it's cleaner if= we need to replace it with core2 in the future, rather than have it be = "implicit core unless coreX is specified". So probably we should do an errata just to clarify that it's mandatory t= o include `"urn:ietf:params:jmap:core"` in the `using` param, and Rapha=C3= =ABl you might want to file a bug with lttrs ? Cheers, Neil. --b6b17bcaa09d472db8877e5abd31490f Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
OK, I've f= ound our previous discussion of this and it looks like t= he conclusion then was to require it to be explicit, because it's cleane= r if we need to replace it with core2 in the future, rather than have it= be "implicit core unless coreX is specified".

<= div>So probably we should do an errata just to clarify that it's mandato= ry to include "urn:ietf:params:jmap:core" in th= e using param, and Rapha=C3=ABl you might want = to file a bug with lttrs?

Cheers,
Neil.
--b6b17bcaa09d472db8877e5abd31490f-- From nobody Thu Dec 10 10:23:05 2020 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 D27CE3A1182; Thu, 10 Dec 2020 10:23:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <160762458381.16256.8179451495609469528@ietfa.amsl.com> Date: Thu, 10 Dec 2020 10:23:03 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-16.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, 10 Dec 2020 18:23:04 -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 : Handling Message Disposition Notification with JMAP Author : Raphaël Ouazana Filename : draft-ietf-jmap-mdn-16.txt Pages : 13 Date : 2020-12-10 Abstract: This document specifies a data model for handling Message Disposition Notifications (MDNs, RFC 8098) in the JSON Meta Application Protocol (JMAP, RFCs 8620 and 8621). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mdn-16 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mdn-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 10 10:24:32 2020 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 4B0923A1184; Thu, 10 Dec 2020 10:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 4xiSHzBR4Uvs; Thu, 10 Dec 2020 10:24:25 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797C03A118B; Thu, 10 Dec 2020 10:24:20 -0800 (PST) Received: from [192.168.0.37] (unknown [91.168.246.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id BE26E484AC; Thu, 10 Dec 2020 19:24:17 +0100 (CET) To: Roman Danyliw , The IESG Cc: jmap@ietf.org, brong@fastmailteam.com, draft-ietf-jmap-mdn@ietf.org, jmap-chairs@ietf.org References: <160195663247.26202.9916738287258170843@ietfa.amsl.com> X-LINAGORA-Copy-Delivery-Done: 1 From: =?UTF-8?Q?Rapha=c3=abl_Ouazana?= Message-ID: <5aa5e288-0c15-5000-fecc-87d569dc4050@linagora.com> Date: Thu, 10 Dec 2020 19:23:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <160195663247.26202.9916738287258170843@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] Roman Danyliw's No Objection on draft-ietf-jmap-mdn-15: (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, 10 Dec 2020 18:24:27 -0000 > ** Section 2. Per “This property MUST NOT be null for "MDN/send", but may be > null in the response from the "MDN/parse" method”, should a normative MAY be > used here instead (or would that conflict with RFC8098) Fixed. > ** Section 2. The guidance to reference RFC8098 for further details is > helpful. In addition to the guidance on case sensitivity, I would have also > would have benefit from a bit of prose on how to convert the fields names > between this document and RFC8098. In other cases this is only String types, so the conversion seems very straightforward to me: just use the same value. But maybe I'm missing something? From nobody Thu Dec 10 10:24:35 2020 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 9C7873A1185; Thu, 10 Dec 2020 10:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 XseQFjj3tEhC; Thu, 10 Dec 2020 10:24:24 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AAB3A1195; Thu, 10 Dec 2020 10:24:15 -0800 (PST) Received: from [192.168.0.37] (unknown [91.168.246.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id 02BB1484B0; Thu, 10 Dec 2020 19:23:56 +0100 (CET) To: Benjamin Kaduk , The IESG Cc: jmap@ietf.org, brong@fastmailteam.com, draft-ietf-jmap-mdn@ietf.org, jmap-chairs@ietf.org References: <160193187289.4946.17482930539468511819@ietfa.amsl.com> X-LINAGORA-Copy-Delivery-Done: 1 From: =?UTF-8?Q?Rapha=c3=abl_Ouazana?= Message-ID: <3490c237-bb9e-62df-9282-413ba44a1084@linagora.com> Date: Thu, 10 Dec 2020 19:23:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <160193187289.4946.17482930539468511819@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and 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, 10 Dec 2020 18:24:27 -0000 Le 05/10/2020 à 23:04, Benjamin Kaduk via Datatracker a écrit : > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This should be quite easy to resolve; I'm just not sure yet which > direction the resolution will be. > Discussed on the list, this should has been fixed in the last draft. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Section 1 > > A client can have to deal with MDNs in different ways: > > (editorial) "have to deal with" seems like it can be read as implying > obligation to do so (even though the majuscule "MUST" is not used); it > seems like this is just attempting to enumerate the cases in which an > MDN might be encountered or need to be interacted with. Replaced by "come across". Not being native English speaker, the distinction is subtle for me, I hope it's better. > > 2. When sending an email message, an MDN can be requested. This > must be done with the help of a header, and is already specified > by [RFC8098] and can already be handled by [RFC8621] this way. > > (nit?) "header" or "header field"? (We get this a lot for HTTP and I've > forgotten if SMTP uses the same rule...) Fixed > > 3. When receiving an MDN, the MDN could be related to an existing > sent message. This is already covered by [RFC8621] in the > EmailSubmission object. [...] > > (The "DeliveryStatus" member, in particular, right?) The "mdnBlobIds" member is enough explicit for me to not have to write it. > Section 1.3 > > The value of this "urn:ietf:params:jmap:mdn" property is an empty > object in the account's "accountCapabilities" property. > > I presume it's also an empty object in the server's "capabilities" > property as well (and we should probably say so). Fixed. > Section 2 > > It's a little interesting to me that RFC 8261 did not define or mention > specific access to the User-Agent string but we need to have a specific > reportingUA here. I do recognize that it's (an optional) part of the > RFC 8098 ABNF, and that RFC 8098 mentions the relevant security > considerations already. Perhaps a subtle nudge in this section that the > "null" option may have better privacy properties would be appropriate. > (We may also revisit whether/what to include in the examples for > reportingUA.) Added. > o finalRecipient: "String|null" Recipient for which the MDN is being > issued. if set, it overrides the value that would be calculated > by the server from the Identity. > > Could we get a couple more words to support the definite article? (I am > not sure which Identity is "the" Identity just from this context; it is > only later on that we discover that there is an identityId in the > MDN/send arguments.) Added. > > o extensionFields: "String[String]|null" Object where keys are > extension-field names and values are extension-field values. > > I used process of elimination to conclude that these are RFC 8098 > extension-field ABNF names/values; I don't know if there's a good way to > hint the reader of that fact. I tried to add a hint. > > o actionMode: "String" This MUST be one of the following strings: > "manual-action" / "automatic-action" > > o sendingMode: "String" This MUST be one of the following strings: > "mdn-sent-manually" / "mdn-sent-automatically" > > I recognize that this is entirely the responsibility of RFC 8098 and not > this document, but is it valid to combine "automatic-action" with > "mdn-sent-manually"? I am not 100% I understand the semantics. Yes it is explained in RFC 8098 : "manual-action [...] (This might include the case when the user has manually configured her MUA to automatically respond to valid MDN requests.)" > Section 2.1 > > The latter because of the implicit call > to Email/set and the use of Identities, described below. [...] > > nit: does this sentence have a verb? Fixed. > > The following already registered SetError would mean: > > nit: these are the SetError types, right? Fixed. > Section 3.x > > It might be helpful to use a different creation ID for the different > classes of example (though not required by the protocol). Fixed. > Section 3.1 > > "extension": { > "X-EXTENSION-EXAMPLE": "example.com" > } > > nit(?): somehow I thought X- extensions were generally thought to not be > needed/useful anymore. Fixed. > Section 5 > > In order to enforce trust regarding the relation between the user > sending an email message and the identity of this user, the server > SHOULD validate in conformance to the provided Identity that the user > is permitted to use the finalRecipient value and return a > forbiddenFrom error if not. > > "enforce" and "SHOULD" are not words I usually see in combination. Fixed, I meant reinforce. From nobody Thu Dec 10 10:31:02 2020 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 B820F3A1195; Thu, 10 Dec 2020 10:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Hy7MQsyqWRc1; Thu, 10 Dec 2020 10:31:00 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B359B3A118B; Thu, 10 Dec 2020 10:30:59 -0800 (PST) Received: from [192.168.0.37] (91-168-246-100.subs.proxad.net [91.168.246.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id 89059484AC; Thu, 10 Dec 2020 19:24:32 +0100 (CET) To: Barry Leiba , Murray Kucherawy Cc: jmap-chairs@ietf.org, IETF JMAP Mailing List , draft-ietf-jmap-mdn@ietf.org, The IESG , Bron Gondwana References: <160139528034.2924.9672441697416964848@ietfa.amsl.com> X-LINAGORA-Copy-Delivery-Done: 1 From: =?UTF-8?Q?Rapha=c3=abl_Ouazana?= Message-ID: <117b0ab7-577c-1798-5e9c-bea7497e1f50@linagora.com> Date: Thu, 10 Dec 2020 19:24:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] Murray Kucherawy's No Objection on draft-ietf-jmap-mdn-15: (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, 10 Dec 2020 18:31:02 -0000 > I agree that we should simply spell out "identifier", and I strongly > encourage that change. As told, I prefer to keep "id" because RFC8620 and RF8621 use almost only this term. From nobody Thu Dec 10 10:31:08 2020 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 EEF293A118B; Thu, 10 Dec 2020 10:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 qyFB2-yFyupl; Thu, 10 Dec 2020 10:31:00 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCB03A1190; Thu, 10 Dec 2020 10:30:59 -0800 (PST) Received: from [192.168.0.37] (91-168-246-100.subs.proxad.net [91.168.246.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id CC141484B0; Thu, 10 Dec 2020 19:24:37 +0100 (CET) To: Murray Kucherawy , The IESG Cc: jmap@ietf.org, Bron Gondwana , draft-ietf-jmap-mdn@ietf.org, jmap-chairs@ietf.org References: <160139528034.2924.9672441697416964848@ietfa.amsl.com> X-LINAGORA-Copy-Delivery-Done: 1 From: =?UTF-8?Q?Rapha=c3=abl_Ouazana?= Message-ID: <69d3b12b-fef6-52a2-7420-9dc344e1a5b5@linagora.com> Date: Thu, 10 Dec 2020 19:24:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <160139528034.2924.9672441697416964848@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] Murray Kucherawy's No Objection on draft-ietf-jmap-mdn-15: (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, 10 Dec 2020 18:31:02 -0000 > There are several places in the document where "header" should be changed to > "header field". Done > > In Section 2.1, I think this could be a bit clearer: > > OLD: > > The following already registered SetError would mean: > > NEW: > > In this context, the existing SetError values defined in [reference] are > interpreted as follows: Done > > In Sections 2.1 and 2.2: > > This is totally a personal nit, and you're free to ignore me, but since I keep > tripping on it I'll mention it: In various places, "id" is used as a word > rather than an initialism, as in "The id of the account to use." I keep > reading this as the English term from psychoanalysis rather than a truncation > of "identifier". I'd probably be happier if the full word was used. Also, in > the first bullet of Section 2, it's capitalized as "Id"; we should probably be > consistent. "id" is used everywhere in the RFC8620 and RFC8621 so I prefer to keep it for consistency. I have replaced some "Id" which should mean the Id data type by "id" where appropriate. > > In Section 3: > > a) s/guaranty/guarantee/ (multiple instances) Not fixing it, as it has the old meaning and it's taken from an example of RFC8098. > > b) There's an extension in Section 3.1 starting with "X-" that should probably > be revisited given BCP 178. Fixed; From nobody Thu Dec 10 10:41:11 2020 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 235123A11AB; Thu, 10 Dec 2020 10:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 8D8fUMg53uRG; Thu, 10 Dec 2020 10:41:00 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91D53A11A8; Thu, 10 Dec 2020 10:40:59 -0800 (PST) Received: from [192.168.0.37] (91-168-246-100.subs.proxad.net [91.168.246.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id 20497484B3; Thu, 10 Dec 2020 19:24:44 +0100 (CET) To: =?UTF-8?Q?=c3=89ric_Vyncke?= , The IESG Cc: jmap@ietf.org, brong@fastmailteam.com, draft-ietf-jmap-mdn@ietf.org, jmap-chairs@ietf.org References: <160138761394.8744.17976022504395989638@ietfa.amsl.com> X-LINAGORA-Copy-Delivery-Done: 1 From: =?UTF-8?Q?Rapha=c3=abl_Ouazana?= Message-ID: <5c52342d-d2fa-e8ec-bae9-b4b89f96659c@linagora.com> Date: Thu, 10 Dec 2020 19:24:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <160138761394.8744.17976022504395989638@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-jmap-mdn-15=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: Thu, 10 Dec 2020 18:41:06 -0000 -- Section 2 -- > While I can guess what is meant by "foreign (non-Internet) message", a more > formal description would probably be welcome. I'm not sure it makes sense to explain this further, as it is a concept directly taken from RFC8098. > > -- Section 2.1 -- > Wondering whether the values in this section are case sensitive? Section 2 > clearly specifies that the fields must be lowercase. Is it useful to specify > whether case is important in this section? I think this is already explained in RFC8620. Basically fields are case-sensitive in JMAP (that differs from RFC8098, hence the explanation at the end of Section 2.). From nobody Mon Dec 14 03:43:43 2020 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 352613A1013; Mon, 14 Dec 2020 03:43:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <160794621916.22485.14871652701763463146@ietfa.amsl.com> Date: Mon, 14 Dec 2020 03:43:39 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-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: Mon, 14 Dec 2020 11:43:40 -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-03.txt Pages : 17 Date : 2020-12-14 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-jscontact-03 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 14 22:01:20 2020 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 09C163A0A9C for ; Mon, 14 Dec 2020 22:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[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=TFzIgVrj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FT1nceK8 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 a87WMZXk9M3I for ; Mon, 14 Dec 2020 22:01:16 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7993A0A97 for ; Mon, 14 Dec 2020 22:01:16 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id D38EBB17 for ; Tue, 15 Dec 2020 01:01:15 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Tue, 15 Dec 2020 01:01:15 -0500 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=bbRwcMxMjK1XciSthpC3ozoDq50A1DAzrFPCKHe vCV0=; b=TFzIgVrj28OkMK5Ji2069gUVAVy2zFaVCvjMrnV3MtuU8voqcyAhqBi VcWsYvZqqi0xU/az3MR2Hgr/9LEmuvUYIsWTAhHelI5sa0N1Xd6WIHbfEFk++QEa 1QgyXgBXlYHfhOxyAnJPvgQ7mLdYh3I4FPn3kAfp7vZmiVimkHql6XTHAPwQs87Y s7QN+8wDCEiyIP9pUL44BiNDOdmbnEkhmdFZJASB8Timzy44Y5JOC7L2eiC3rGoo zkgEz4T+EYItTrPTHeef54cT/S7htXFCxHArEvzeiaN+zDAzUsAFtdOBwuAsSZwM Xy6it7mIQi4EnPtmyt1xRBR+51ZP1rw== 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=bbRwcMxMjK1XciSthpC3ozoDq50A1 DAzrFPCKHevCV0=; b=FT1nceK8bAt74tiPNM5ny0DdMMJAfuKZh5pLqCE+qXNgQ y+KbKvbp608mXNKpIcN85qM7k4PiUnVjeEgU8CBSJYH1YCsMABzobKoB3g0vAicA E581Q6S0AyQ3tP5yhZ/M/7iuVyaP/IfCGMDSuQBS2L6fgjWLQkqVUZQRbqMkN8xr Iw3PDFTRcbH2C4+MlTGSY27+A74g8qcVbT6pfxZzGBLif/l3l74Nupdv3WPnnjjl pi+1untkFgxCHE/pGESbH471E1rNwUdVyWDigbNZr9ZoSNAVvMsZzZ+XqUs1fPMW eXTWzsTlGV42idpo8bP2ZZTNa+jHHaLRmxtVBVEaQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekledgleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghilhcu lfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenuc ggtffrrghtthgvrhhnpedtveevtdeuuedufeeuueegvdeiveevudelleekgefflefgteev leevudeludetveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BDABD1803E5; Tue, 15 Dec 2020 01:01:14 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> Date: Tue, 15 Dec 2020 17:01:13 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=73fc86e4dd5c4a448c4f08dbbb3597cc Archived-At: Subject: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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, 15 Dec 2020 06:01:19 -0000 --73fc86e4dd5c4a448c4f08dbbb3597cc Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, The JMAP Calendars draft-in-progress currently defines the CalendarPrinc= ipal and CalendarShareNotification data types under a separate capabilit= y. Looking at it, I have come to the conclusion that we should go a step= further: drop "Calendar" from the names and split them out into their o= wn spec. These are really generic sharing primitives that could then be = referenced by the other specs =E2=80=94 e.g. calendars, tasks, mail shar= ing =E2=80=94 to define how you share data of types between entities wit= hin a system in a consistent way. Please reply with any comments, questions, objections, or agreement with= the proposal and I will write up a draft splitting out these data types= to propose for acceptance. Cheers, Neil. --73fc86e4dd5c4a448c4f08dbbb3597cc Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all,

The JMAP Calendars draft-in-progress currently def= ines the CalendarPrincipal and CalendarShareNotification data types unde= r a separate capability. Looking at it, I have come to the conclusion th= at we should go a step further: drop "Calendar" from the names and split= them out into their own spec. These are really generic sharing primitiv= es that could then be referenced by the other specs =E2=80=94 e.g. calen= dars, tasks, mail sharing =E2=80=94 to define how you share data of type= s between entities within a system in a consistent way.
Please reply with any comments, questions, objections, or a= greement with the proposal and I will write up a draft splitting out the= se data types to propose for acceptance.

Ch= eers,
Neil.
--73fc86e4dd5c4a448c4f08dbbb3597cc-- From nobody Tue Dec 15 00:22:07 2020 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 B54663A0E98 for ; Tue, 15 Dec 2020 00:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 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 k0JFT8W1yvYd for ; Tue, 15 Dec 2020 00:22:01 -0800 (PST) Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B925B3A0E44 for ; Tue, 15 Dec 2020 00:22:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id D14A4A1E6 for ; Tue, 15 Dec 2020 09:21:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.audriga.com Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6n9ImCfA9xn for ; Tue, 15 Dec 2020 09:21:37 +0100 (CET) Received: from [192.168.0.94] (HSI-KBW-46-223-162-22.hsi.kabel-badenwuerttemberg.de [46.223.162.22]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id D84E6A1E5 for ; Tue, 15 Dec 2020 09:21:37 +0100 (CET) To: jmap@ietf.org References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> From: Joris Baum Message-ID: Date: Tue, 15 Dec 2020 09:21:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------A03436E4569ADECEBCA9E7D8" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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, 15 Dec 2020 08:22:06 -0000 This is a multi-part message in MIME format. --------------A03436E4569ADECEBCA9E7D8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Neil, sounds like a good idea. From what I can see one would currently need to = reuse the CalendarPrincipal and CalendarShareNotification for specs that = are somehow similar to JMAP for Calendars. I would have done it like=20 that in JMAP for Tasks (and probably also Notes). Since CalDAV also=20 defines tasks and notes and the JMAP spec relates to CalDAV, reusing=20 sharing primitives prefixed by "Calendar" would probably only be=20 semi-weird :P. I like dropping the "Calendar" prefix, because it would=20 make it clearer that they are generic sharing primitives and not=20 specific to calendars. There may be similar issues with other primitives or methods that are=20 defined in JMAP for Calendars. I am currently planning on keeping JMAP=20 for Tasks as close as possible to JMAP for Calendars (similar to how=20 CalDAV does it). The simplest way that I can see, would be to redefine a = nearly identical primitive like CalendarEventNotification called=20 TaskNotification. I also do not expect most of the method calls to=20 deviate all too much from what is defined in JMAP for Calendars. This is = why I am planning on simply referencing the methods from JMAP for=20 Calendars instead of copy+pasting the definition into JMAP for Tasks=20 (and probably Notes as well). Maybe there is a better way that I am=20 currently not seeing, or we could move even more into a "generic" spec? Regards, Joris On 15.12.20 07:01, Neil Jenkins wrote: > Hi all, > > The JMAP Calendars draft-in-progress currently defines the=20 > CalendarPrincipal and CalendarShareNotification data types under a=20 > separate capability. Looking at it, I have come to the conclusion that = > we should go a step further: drop "Calendar" from the names and split=20 > them out into their own spec. These are really generic sharing=20 > primitives that could then be referenced by the other specs =E2=80=94 e= =2Eg.=20 > calendars, tasks, mail sharing =E2=80=94 to define how you share data o= f types=20 > between entities within a system in a consistent way. > > Please reply with any comments, questions, objections, or agreement=20 > with the proposal and I will write up a draft splitting out these data = > types to propose for acceptance. > > Cheers, > Neil. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --=20 Joris Baum Tel: +49 721 170293 16 Fax: +49 721 170293 179 http://www.audriga.com | http://www.twitter.com/audriga -------------------------------------------------------------------------= - audriga GmbH | Durlacher Allee 47 | 76131 Karlsruhe Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034 Gesch=C3=A4ftsf=C3=BChrer: Dr. Frank Dengler, Dr.-Ing. Hans-J=C3=B6rg Hap= pel -------------------------------------------------------------------------= - --------------A03436E4569ADECEBCA9E7D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Neil,

sounds like a good idea. From what I can see one would currently need to reuse the CalendarPrincipal and CalendarShareNotification for specs that are somehow similar to JMAP for Calendars. I would have done it like that in JMAP for Tasks (and probably also Notes). Since CalDAV also defines tasks and notes and the JMAP spec relates to CalDAV, reusing sharing primitives prefixed by "Calendar" would probably only be semi-weird :P. I like dropping the "Calendar" prefix, because it would make it clearer that they are generic sharing primitives and not specific to calendars.

There may be similar issues with other primitives or methods that are defined in JMAP for Calendars. I am currently planning on keeping JMAP for Tasks as close as possible to JMAP for Calendars (similar to how CalDAV does it). The simplest way that I can see, would be to redefine a nearly identical primitive like CalendarEventNotification called TaskNotification. I also do not expect most of the method calls to deviate all too much from what is defined in JMAP for Calendars. This is why I am planning on simply referencing the methods from JMAP for Calendars instead of copy+pasting the definition into JMAP for Tasks (and probably Notes as well). Maybe there is a better way that I am currently not seeing, or we could move even more into a "generic" spec?

Regards,

Joris


On 15.12.20 07:01, Neil Jenkins wrote:
Hi all,

The JMAP Calendars draft-in-progress currently defines the CalendarPrincipal and CalendarShareNotification data types under a separate capability. Looking at it, I have come to the conclusion that we should go a step further: drop "Calendar" from the names and split them out into their own spec. These are really generic sharing primitives that could then be referenced by the other specs — e.g. calendars, tasks, mail sharing — to define how you share data of types between entities within a system in a consistent way.

Please reply with any comments, questions, objections, or agreement with the proposal and I will write up a draft splitting out these data types to propose for acceptance.

Cheers,
Neil.

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
-- 
Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

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

--------------------------------------------------------------------------
audriga GmbH | Durlacher Allee 47 | 76131 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------
--------------A03436E4569ADECEBCA9E7D8-- From nobody Tue Dec 15 09:28:13 2020 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 1A88D3A1275 for ; Tue, 15 Dec 2020 09:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGp_HlKiEsmm for ; Tue, 15 Dec 2020 09:28:08 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626313A1274 for ; Tue, 15 Dec 2020 09:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=esaB9gPYiRODVlMACa1/4tr0OlUmcXyBJ/ujow3rxYk=; b=cVj7norqqf5I888Uq3fQfUMjTK FahjE4K6BzVxsCVCXRIptxBmfWSd4IVbEa4CXwMVAGlc5/x6tHFTHsnxa0Aoq7xVThXD1syv7nTYP Z8KvrzpPYPdCv+MvtEyAjlfgf3qBWoT136T56NxBDf0XashThhBASTCyrw4YV1daIc3o=; Received: from [2601:647:4400:1261:b4c6:391:b787:7e04] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kpE7J-0003EN-Dy; Tue, 15 Dec 2020 09:28:06 -0800 From: "Jim Fenton" To: "Neil Jenkins" Cc: "IETF JMAP Mailing List" Date: Tue, 15 Dec 2020 09:28:04 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <6F004CB0-62ED-46B3-A06E-D3A6B608B92B@bluepopcorn.net> In-Reply-To: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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, 15 Dec 2020 17:28:13 -0000 On 14 Dec 2020, at 22:01, Neil Jenkins wrote: > Hi all, > > The JMAP Calendars draft-in-progress currently defines the > CalendarPrincipal and CalendarShareNotification data types under a > separate capability. Looking at it, I have come to the conclusion that > we should go a step further: drop "Calendar" from the names and split > them out into their own spec. These are really generic sharing > primitives that could then be referenced by the other specs — e.g. > calendars, tasks, mail sharing — to define how you share data of > types between entities within a system in a consistent way. > > Please reply with any comments, questions, objections, or agreement > with the proposal and I will write up a draft splitting out these data > types to propose for acceptance. I definitely think that would be useful. For example, my wife and I would like to have a shared contact list. -Jim From nobody Tue Dec 15 09:29:39 2020 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 DA4E63A1278 for ; Tue, 15 Dec 2020 09:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=WSQlk6OP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cew10mvi 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 oOquaN4Nw0PL for ; Tue, 15 Dec 2020 09:29:36 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8659E3A1275 for ; Tue, 15 Dec 2020 09:29:36 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8DFA05C00CF for ; Tue, 15 Dec 2020 12:29:35 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 15 Dec 2020 12:29:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=G1wXTxSA8sRvGy6WO0U7BlJHeTa U8wQO5qkO9OAJykQ=; b=WSQlk6OPs54JNzl7jZhYx2jPxfXHg9xrtM2Un+UKC9w 20DZj9OQPAfL+FZO9UJl461ddrKt2PTG4EpqIxjP3UDMLj08J+ZYobtCYKra8nkC vk2mj1hwkWmGdILnPHSc2ZbEcdZoYTlsVfF8L45wpZ6l8qT7Hk9Q8UthBIGObaEw OajHOG7PfEKa1+CGXInLtzZ9aYnQPfxCMbGN7YLxZUUl0ESHNk96U0KZp/mhhgNs KsFoyKA1TjEGk6LGhwrpg9hj6QYdnMGgfSZBsdGhfv4US+fyjVLZu0CrMkeNwomY bZ3Qljjxs9XTFTJaRvJmKkLLg0lTO4FOecjgcUAS6AQ== 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=G1wXTx SA8sRvGy6WO0U7BlJHeTaU8wQO5qkO9OAJykQ=; b=cew10mviKlmi+doAbrDvGy 0BQszl7EuAj+DE27n9zD171VSVj0I+uG/qx3biVsVDBdbAUHtKAQ6VoDp3NtQ1ds TuHHryOgwP+vv6waCToT380dPD57dTR/BG/s9sg5HYVvr+3b4IswRRFtIe3jTFtQ aF0PQv4TZrQaTknW6lrU1NQedP9tWhX8gvcS5BYF6M9CXk8y9COKdY+mdQgHEuFl EhvuT5iGERiThy1G8VSHxTcFrqMcjzw1XznoNuRRa7fKSRsHhKelnLscHElH7GUF XHe/UC5gaIER8uP2vxMRaG12yH8AJcoIjGOsxxXywBuhpnPSsAuXWRni1KMZ8I9w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeltddguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtd erredtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeekheevhfduleeufeduhfelle fffeeigeeguddvveekiefhvdeujeeffeejtdegfeenucfkphepjeegrdejjedrkeehrddv hedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh hurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 2009A24005C for ; Tue, 15 Dec 2020 12:29:35 -0500 (EST) To: jmap@ietf.org References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> From: Ken Murchison Message-ID: <1eaf6b07-bf9b-e363-d5a0-b326a7f11f9f@fastmail.com> Date: Tue, 15 Dec 2020 12:29:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------BB5934B7378E4157816EEF20" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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, 15 Dec 2020 17:29:38 -0000 This is a multi-part message in MIME format. --------------BB5934B7378E4157816EEF20 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/15/20 1:01 AM, Neil Jenkins wrote: > Hi all, > > The JMAP Calendars draft-in-progress currently defines the > CalendarPrincipal and CalendarShareNotification data types under a > separate capability. Looking at it, I have come to the conclusion that > we should go a step further: drop "Calendar" from the names and split > them out into their own spec. These are really generic sharing > primitives that could then be referenced by the other specs — e.g. > calendars, tasks, mail sharing — to define how you share data of types > between entities within a system in a consistent way. > > Please reply with any comments, questions, objections, or agreement > with the proposal and I will write up a draft splitting out these data > types to propose for acceptance. > +1 to splitting -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------BB5934B7378E4157816EEF20 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/15/20 1:01 AM, Neil Jenkins wrote:
Hi all,

The JMAP Calendars draft-in-progress currently defines the CalendarPrincipal and CalendarShareNotification data types under a separate capability. Looking at it, I have come to the conclusion that we should go a step further: drop "Calendar" from the names and split them out into their own spec. These are really generic sharing primitives that could then be referenced by the other specs — e.g. calendars, tasks, mail sharing — to define how you share data of types between entities within a system in a consistent way.

Please reply with any comments, questions, objections, or agreement with the proposal and I will write up a draft splitting out these data types to propose for acceptance.


+1 to splitting


-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------BB5934B7378E4157816EEF20-- From nobody Tue Dec 15 20:16:08 2020 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 F40573A0E81 for ; Tue, 15 Dec 2020 20:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_DNSWL_BLOCKED=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=l0mbSezC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YJBsD5Wu 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 8xoQRXLIzm77 for ; Tue, 15 Dec 2020 20:16:03 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F053A0E7C for ; Tue, 15 Dec 2020 20:16:02 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5D7765C00F9 for ; Tue, 15 Dec 2020 23:15:57 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 15 Dec 2020 23:15:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=a/vmz+k eeN/HyucbY6kE0fYVWor/OaiXYSBtWmCHnmI=; b=l0mbSezCwIAcwGszSNoRW+n gZ1ZLYlbmG+wvwQ5xTY9JSQ4XEX3qyPZiMLWqDC1RYsruyR/67h8Lo2ab5EqAQ4e Md7RvyZAHIH+irthcFBzCIXRFzMUjNo/RShl4KNOeiHKwLAKOycFYzcVY8P4OTx2 chkyLavuATR5ig4Vr7gY/ShWL2/xpcHk302U1gK8/NSfhUdiEp6g27M8zundiL6A MqpweDVM7vUOtne+iakHCTV+mHr4G56IOD9tOu2hKY1VKD9DO9ckCJlcTdM2HBQN SSuCQ316B/yo6yQmWMy7Hgy6UmCbN9YabRjW/xnS9HEYz/4HFJHOCxXXH7op2yQ= = 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=a/vmz+ keeN/HyucbY6kE0fYVWor/OaiXYSBtWmCHnmI=; b=YJBsD5WuLligdHOb0mRhr6 i+cqTw4SKbjIvzkVfVkWeD9DG2g5odauNqO2XkN3L48nZHCTulv5EQQek7VePa4N KCu+ZRa9xbVCdW+soxU+2+vUC/C1VPjb60vZAtbT/loNp1jVB1rGOL0wwsWPfnmA lrxahuQlpTIvp8gDjEvSUO+9xXjLycwCOg4sRZ9gfzDxgORTTDhSdGmG4qsHH6pN zv44E/o9+YCEQ/nc7fhQSOuq3gCIFW2v2cAwVOtvM17QKDS/CVu4GIetv8gq+oty ZdLAsG900vVFcpiVUWnFxHjGcfzlHFcxJr3epEFLBvGjhW+14pRpgqcyziFXL7IQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeluddgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffvdekfeegle eiueettddtffehveevffefkeduvddttdekiefgjeduvdfhvdduleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 097DE18040A; Tue, 15 Dec 2020 23:15:57 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <4ad35ea7-22f5-4711-ab8b-4a5c5e558400@dogfood.fastmail.com> In-Reply-To: <1eaf6b07-bf9b-e363-d5a0-b326a7f11f9f@fastmail.com> References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> <1eaf6b07-bf9b-e363-d5a0-b326a7f11f9f@fastmail.com> Date: Wed, 16 Dec 2020 15:15:36 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=c63fe12da9704b37969309caf5c842b2 Archived-At: Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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, 16 Dec 2020 04:16:06 -0000 --c63fe12da9704b37969309caf5c842b2 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable My public +1 as well :) (Neil and I already discussed this on a call) Bron. On Wed, Dec 16, 2020, at 04:29, Ken Murchison wrote: >=20 > On 12/15/20 1:01 AM, Neil Jenkins wrote: >> Hi all, >>=20 >> The JMAP Calendars draft-in-progress currently defines the CalendarPr= incipal and CalendarShareNotification data types under a separate capabi= lity. Looking at it, I have come to the conclusion that we should go a s= tep further: drop "Calendar" from the names and split them out into thei= r own spec. These are really generic sharing primitives that could then = be referenced by the other specs =E2=80=94 e.g. calendars, tasks, mail s= haring =E2=80=94 to define how you share data of types between entities = within a system in a consistent way. >>=20 >> Please reply with any comments, questions, objections, or agreement w= ith the proposal and I will write up a draft splitting out these data ty= pes to propose for acceptance. >=20 > +1 to splitting=20 >=20 > --=20 Kenneth Murchison Senior Software Developer Fastmail US LLC > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --c63fe12da9704b37969309caf5c842b2 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
My public +1 as well :)  (Neil and I already dis= cussed this on a call)

Bron.

On Wed, Dec 16, 2020, at 04:29, Ken Murchi= son wrote:

On 12/15/20 1:01 AM, Neil Jenkin= s wrote:
Hi all,
<= br>
The JMAP Calendars draft-in-progress currently defines the= CalendarPrincipal and CalendarShareNotification data types under= a separate capability. Looking at it, I have come to the conclusion that we should go a step further: drop "Calendar" from the names and split them out into their own spec. These are= really generic sharing primitives that could then be referenced by the other specs =E2=80=94 e.g. calendars, tasks, mail sharing= =E2=80=94 to define how you share data of types between entities within a system in a consistent way.

Please = reply with any comments, questions, objections, or agreement with the proposal and I will write up a draft splitting out these data types to propose for acceptance.


+1 to splitting


--=20
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
__________________________________________= _____
Jmap mailing list



--c63fe12da9704b37969309caf5c842b2-- From nobody Tue Dec 15 21:05:09 2020 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 9C1CF3A0EEB for ; Tue, 15 Dec 2020 21:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=TovcSJ8F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r5lNGafo 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 wxwHbH5kj3sl for ; Tue, 15 Dec 2020 21:05:06 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E563A0EE0 for ; Tue, 15 Dec 2020 21:05:06 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9BFD282B for ; Wed, 16 Dec 2020 00:05:05 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Wed, 16 Dec 2020 00:05:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=fdWJ3u/ nFPqh9JwVuCQ88IH0e9hm278P3purKjWm2do=; b=TovcSJ8FvyeA1y7RYDR595i nMtDSxuFHRpFHIn5Rxb5IqafRarFytlfCOlQWAnhmeDoEcTlQa8o1O6GXP/tTnB8 uLdq3P9HUdYfPQhOCSKMlqueiWfSPOAhWKkAp5BVEskjuz1Oc0CizGYAmYoj53jN oSVPKo/IZL3BSKVsdCX9Y4WsMI+jQaV80Wstbn9rctiHH8mK0PPwTVGHhcQES3OV 6sZHZh/Bb66u3wpdlq02ORrRSs15Zpl3QsWJeOJaOO9qTQ3RNXY5Anxt9NWMZ2Z3 hHL21Xz3gYwsdse5EopoFJX/i7edtWKPdUP/kMLTMzEO3qjLjsDBTEtNnWj9ViQ= = 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=fdWJ3u /nFPqh9JwVuCQ88IH0e9hm278P3purKjWm2do=; b=r5lNGafoV+crQcbvR7TGKI 5WDqe4fj4CaasOPDOFHHrY/93c37u3nvS4BBnmHRWp51Ddg6DIGvHIy/gkp4cMi3 4JC3GEurFv/A4DlFI7Csg9tKcmeZOkI83LksaEb9lzrlDtqNOQGjF5w9KjQsCy/p 004bVggDrAfopsznOJ40lH/JVGiLn50qRcBhbgCo95Z7DahpRLUqbso32TfxD17X vZ1KJPWhR/HTCDu8A99cnRrwLaiO+vuVo61O5djiGcDjKYgurySNtsvpI5qu3cdu 6octhtgwwDsqC++Y2MZk200+d5RExqSMgxdCD8nv+AIYf1bTJI1/BAaBg02iUfeA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeluddgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpefhleehffetfeeuiedvkeegieejieeuhfdugfevleelgfev udetuedtleeigefgjeenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgr ihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CB07118040A; Wed, 16 Dec 2020 00:05:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <2248c311-c24e-4c49-b5e2-e778ce60b307@beta.fastmail.com> In-Reply-To: References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> Date: Wed, 16 Dec 2020 16:05:04 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=67249321556e452aae163d0f61ab0dee Archived-At: Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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, 16 Dec 2020 05:05:09 -0000 --67249321556e452aae163d0f61ab0dee Content-Type: text/plain OK, I've published an initial draft that splits off the principals/share notifications; I presume the next step is a call for adoption? I can then publish an update to the calendar spec that references this, On Tue, 15 Dec 2020, at 19:21, Joris Baum wrote: > I also do not expect most of the method calls to deviate all too much from what is defined in JMAP for Calendars. This is why I am planning on simply referencing the methods from JMAP for Calendars instead of copy+pasting the definition into JMAP for Tasks (and probably Notes as well). Maybe there is a better way that I am currently not seeing, or we could move even more into a "generic" spec? I think it will be cleaner if JMAP Tasks is a sibling rather than dependent spec to JMAP Calendars, but it will be easier to discuss once we have a concrete initial draft. Cheers, Neil. --67249321556e452aae163d0f61ab0dee Content-Type: text/html
OK, I've published an initial draft that splits off the principals/share notifications; I presume the next step is a call for adoption? I can then publish an update to the calendar spec that references this,

On Tue, 15 Dec 2020, at 19:21, Joris Baum wrote:
I also do not expect most of the method calls to deviate all too much from what is defined in JMAP for Calendars. This is why I am planning on simply referencing the methods from JMAP for Calendars instead of copy+pasting the definition into JMAP for Tasks (and probably Notes as well). Maybe there is a better way that I am currently not seeing, or we could move even more into a "generic" spec?

I think it will be cleaner if JMAP Tasks is a sibling rather than dependent spec to JMAP Calendars, but it will be easier to discuss once we have a concrete initial draft.

Cheers,
Neil.
--67249321556e452aae163d0f61ab0dee-- From nobody Wed Dec 16 08:48:13 2020 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 2C4B83A11BC; Wed, 16 Dec 2020 08:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g26YuhbvyTmZ; Wed, 16 Dec 2020 08:47:59 -0800 (PST) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (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 58A353A11D8; Wed, 16 Dec 2020 08:47:49 -0800 (PST) Received: by mail-lf1-f45.google.com with SMTP id y19so49935012lfa.13; Wed, 16 Dec 2020 08:47:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UnolFbfSL4OmoYcXHcispv2VEMDlL69AYa2HW1GrHNw=; b=mI+xa2OW3bWdrIpvgp3A1IEzMCNwd0KVtvvijxocD5V2hyeYWwtXTYORVVOsc6OUAu ZPqrLbCLV2k/OTpUromlgA3fs+3pIev4NjEHczT29KxhRtqKnJS/al1GjBM6Nn9UbXS4 JQhs6z9Jg5OdZSjsmzMaTCCGEfgJdJ3gcjL97OrF37hRCfx+y0stRE+Xh9FJUjeLhlQu TWEC60vDhxbFgsIESsxq9OoirR8DlhXtg+038Q0Hkyoum80kOSWhzR7L/UsyE1vnvEec jQKRMjPPDwcYgmpQ+562kAhZqgEdFFBnqNe05b6MCKClLGb1gKcrm71OJA+AbIWQ58w1 f8BA== X-Gm-Message-State: AOAM533/yDRM2r9845s8PezYIbhcpt39AoELmF/N3gXgPKb/8rO5jsuw hhDjLMhnnGsPUIbQph2vEEbAiuHd4azuLfPJUcqCrkde5wk= X-Google-Smtp-Source: ABdhPJy5/pQ9RqX+lmou4IB/H1fmqrzyzmgd1jvJQXlUB0QEPz74SurRfDlmRZkbzLTa4euk8hzzuMjMMEBwxYtWdyw= X-Received: by 2002:ac2:41d9:: with SMTP id d25mr12439789lfi.377.1608137267350; Wed, 16 Dec 2020 08:47:47 -0800 (PST) MIME-Version: 1.0 References: <160193187289.4946.17482930539468511819@ietfa.amsl.com> <3490c237-bb9e-62df-9282-413ba44a1084@linagora.com> In-Reply-To: <3490c237-bb9e-62df-9282-413ba44a1084@linagora.com> From: Barry Leiba Date: Wed, 16 Dec 2020 11:47:36 -0500 Message-ID: To: Benjamin Kaduk , =?UTF-8?Q?Rapha=C3=ABl_Ouazana?= Cc: The IESG , IETF JMAP Mailing List , draft-ietf-jmap-mdn@ietf.org, Bron Gondwana Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and 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, 16 Dec 2020 16:48:07 -0000 Ben, I think the change made in -16 to the penultimate paragraph of Section 2.1 should resolve your DISCUSS. Can you check? Thanks. Barry On Thu, Dec 10, 2020 at 1:24 PM Rapha=C3=ABl Ouazana wrote: > > > Le 05/10/2020 =C3=A0 23:04, Benjamin Kaduk via Datatracker a =C3=A9crit : > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This should be quite easy to resolve; I'm just not sure yet which > > direction the resolution will be. > > > Discussed on the list, this should has been fixed in the last draft. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > Section 1 > > > > A client can have to deal with MDNs in different ways: > > > > (editorial) "have to deal with" seems like it can be read as implying > > obligation to do so (even though the majuscule "MUST" is not used); it > > seems like this is just attempting to enumerate the cases in which an > > MDN might be encountered or need to be interacted with. > Replaced by "come across". Not being native English speaker, the > distinction is subtle for me, I hope it's better. > > > > 2. When sending an email message, an MDN can be requested. This > > must be done with the help of a header, and is already specifie= d > > by [RFC8098] and can already be handled by [RFC8621] this way. > > > > (nit?) "header" or "header field"? (We get this a lot for HTTP and I'v= e > > forgotten if SMTP uses the same rule...) > Fixed > > > > 3. When receiving an MDN, the MDN could be related to an existing > > sent message. This is already covered by [RFC8621] in the > > EmailSubmission object. [...] > > > > (The "DeliveryStatus" member, in particular, right?) > The "mdnBlobIds" member is enough explicit for me to not have to write it= . > > Section 1.3 > > > > The value of this "urn:ietf:params:jmap:mdn" property is an empty > > object in the account's "accountCapabilities" property. > > > > I presume it's also an empty object in the server's "capabilities" > > property as well (and we should probably say so). > Fixed. > > Section 2 > > > > It's a little interesting to me that RFC 8261 did not define or mention > > specific access to the User-Agent string but we need to have a specific > > reportingUA here. I do recognize that it's (an optional) part of the > > RFC 8098 ABNF, and that RFC 8098 mentions the relevant security > > considerations already. Perhaps a subtle nudge in this section that th= e > > "null" option may have better privacy properties would be appropriate. > > (We may also revisit whether/what to include in the examples for > > reportingUA.) > Added. > > o finalRecipient: "String|null" Recipient for which the MDN is bei= ng > > issued. if set, it overrides the value that would be calculated > > by the server from the Identity. > > > > Could we get a couple more words to support the definite article? (I a= m > > not sure which Identity is "the" Identity just from this context; it is > > only later on that we discover that there is an identityId in the > > MDN/send arguments.) > Added. > > > > o extensionFields: "String[String]|null" Object where keys are > > extension-field names and values are extension-field values. > > > > I used process of elimination to conclude that these are RFC 8098 > > extension-field ABNF names/values; I don't know if there's a good way t= o > > hint the reader of that fact. > I tried to add a hint. > > > > o actionMode: "String" This MUST be one of the following strings: > > "manual-action" / "automatic-action" > > > > o sendingMode: "String" This MUST be one of the following strings: > > "mdn-sent-manually" / "mdn-sent-automatically" > > > > I recognize that this is entirely the responsibility of RFC 8098 and no= t > > this document, but is it valid to combine "automatic-action" with > > "mdn-sent-manually"? I am not 100% I understand the semantics. > > Yes it is explained in RFC 8098 : > > "manual-action [...] (This might include the case when the user has > manually configured her MUA to automatically respond to valid MDN > requests.)" > > > Section 2.1 > > > > The latter because of the implicit ca= ll > > to Email/set and the use of Identities, described below. [...] > > > > nit: does this sentence have a verb? > Fixed. > > > > The following already registered SetError would mean: > > > > nit: these are the SetError types, right? > Fixed. > > Section 3.x > > > > It might be helpful to use a different creation ID for the different > > classes of example (though not required by the protocol). > Fixed. > > Section 3.1 > > > > "extension": { > > "X-EXTENSION-EXAMPLE": "example.com" > > } > > > > nit(?): somehow I thought X- extensions were generally thought to not b= e > > needed/useful anymore. > Fixed. > > Section 5 > > > > In order to enforce trust regarding the relation between the user > > sending an email message and the identity of this user, the server > > SHOULD validate in conformance to the provided Identity that the us= er > > is permitted to use the finalRecipient value and return a > > forbiddenFrom error if not. > > > > "enforce" and "SHOULD" are not words I usually see in combination. > Fixed, I meant reinforce. > From nobody Thu Dec 17 02:44:11 2020 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 4C2E13A15BF for ; Thu, 17 Dec 2020 02:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 ti0k7tvslc7y for ; Thu, 17 Dec 2020 02:44:09 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3C03A09E8 for ; Thu, 17 Dec 2020 02:44:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1608201848; d=isode.com; s=june2016; i=@isode.com; bh=1hwJa95ct78nD1MXtL4gfn7SDs//VjNRMOVe113hJYs=; 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=H2JQzJ68yrQ2iSskdgCJvOCz5pVabayapJ0MeJG1u8bb0YEWjs7ELq23TaY5rQiveBLKzz m92O0XECewDCgBR6Hfyfy+WZKmrbfPpK3sXCIaVNzfudc+imNZijPMOY0BqrjQcTqswWUY aJfViGBciL7expevKn48sSA6O09sSfo=; Received: from [172.27.251.141] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 17 Dec 2020 10:44:07 +0000 To: Neil Jenkins , IETF JMAP Mailing List References: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> From: Alexey Melnikov Message-ID: Date: Thu, 17 Dec 2020 10:42:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-Reply-To: <1e765f38-5a7a-4498-ab6a-8361671713f5@beta.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------EB0A2D9FD48A94E4475967F4" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Proposal: split sharing mechanism from JMAP Calendars spec 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, 17 Dec 2020 10:44:10 -0000 --------------EB0A2D9FD48A94E4475967F4 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Neil, On 15/12/2020 06:01, Neil Jenkins wrote: > Hi all, > > The JMAP Calendars draft-in-progress currently defines the=20 > CalendarPrincipal and CalendarShareNotification data types under a=20 > separate capability. Looking at it, I have come to the conclusion that=20 > we should go a step further: drop "Calendar" from the names and split=20 > them out into their own spec. These are really generic sharing=20 > primitives that could then be referenced by the other specs =E2=80=94 e.g.= =20 > calendars, tasks, mail sharing =E2=80=94 to define how you share data of t= ypes=20 > between entities within a system in a consistent way. CalendarShareNotification is referencing CalendarRights. The latter=20 looks rather calendar specific. If you can generalize CalendarRights, what you suggest above looks like=20 a good direction. > Please reply with any comments, questions, objections, or agreement=20 > with the proposal and I will write up a draft splitting out these data=20 > types to propose for acceptance. Best Regards, Alexey --------------EB0A2D9FD48A94E4475967F4 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Neil,

On 15/12/2020 06:01, Neil Jenkins wrote:
Hi all,

The JMAP Calendars draft-in-progress currently defines the CalendarPrincipal and CalendarShareNotification data types under a separate capability. Looking at it, I have come to the conclusion that we should go a step further: drop "Calendar" from the names and split them out into their own spec. These are really generic sharing primitives that could then be referenced by the other specs =E2=80=94 e.g. calendars, tasks, mail sharing =E2= =80=94 to define how you share data of types between entities within a system in a consistent way.

CalendarShareNotification is referencing CalendarRights. The latter looks rather calendar specific.

If you can generalize CalendarRights, what you suggest above looks like a good direction.

Please reply with any comments, questions, objections, or agreement with the proposal and I will write up a draft splitting out these data types to propose for acceptance.


Best Regards,

Alexey


--------------EB0A2D9FD48A94E4475967F4-- From nobody Thu Dec 17 09:02:50 2020 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 9DEA03A1446; Thu, 17 Dec 2020 09:02:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <160822455760.21038.2698556806641351307@ietfa.amsl.com> Date: Thu, 17 Dec 2020 09:02:37 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-sieve-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: Thu, 17 Dec 2020 17:02: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 Sieve Scripts Author : Kenneth Murchison Filename : draft-ietf-jmap-sieve-03.txt Pages : 26 Date : 2020-12-17 Abstract: This document specifies a data model for managing Sieve scripts on a server using the JSON Meta Application Protocol (JMAP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-sieve/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-sieve-03 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-sieve-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-sieve-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 31 10:17:56 2020 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 53C983A0E1E; Thu, 31 Dec 2020 10:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 CDoGvh0YJJ-x; Thu, 31 Dec 2020 10:17:49 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 446083A0E1D; Thu, 31 Dec 2020 10:17:48 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BVIHcre003862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Dec 2020 13:17:43 -0500 Date: Thu, 31 Dec 2020 10:17:38 -0800 From: Benjamin Kaduk To: =?iso-8859-1?Q?Rapha=EBl?= Ouazana , Barry Leiba Cc: The IESG , IETF JMAP Mailing List , draft-ietf-jmap-mdn@ietf.org, Bron Gondwana Message-ID: <20201231181738.GD93151@kduck.mit.edu> References: <160193187289.4946.17482930539468511819@ietfa.amsl.com> <3490c237-bb9e-62df-9282-413ba44a1084@linagora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and 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, 31 Dec 2020 18:17:51 -0000 Yes, it looks good, and I've updated my position in the datatracker. Raphal: thank you for the updates and your responses. -Ben On Wed, Dec 16, 2020 at 11:47:36AM -0500, Barry Leiba wrote: > Ben, I think the change made in -16 to the penultimate paragraph of > Section 2.1 should resolve your DISCUSS. Can you check? Thanks. > > Barry > > On Thu, Dec 10, 2020 at 1:24 PM Raphal Ouazana wrote: > > > > > > Le 05/10/2020 23:04, Benjamin Kaduk via Datatracker a crit : > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > This should be quite easy to resolve; I'm just not sure yet which > > > direction the resolution will be. > > > > > Discussed on the list, this should has been fixed in the last draft. > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > > > > Section 1 > > > > > > A client can have to deal with MDNs in different ways: > > > > > > (editorial) "have to deal with" seems like it can be read as implying > > > obligation to do so (even though the majuscule "MUST" is not used); it > > > seems like this is just attempting to enumerate the cases in which an > > > MDN might be encountered or need to be interacted with. > > Replaced by "come across". Not being native English speaker, the > > distinction is subtle for me, I hope it's better. > > > > > > 2. When sending an email message, an MDN can be requested. This > > > must be done with the help of a header, and is already specified > > > by [RFC8098] and can already be handled by [RFC8621] this way. > > > > > > (nit?) "header" or "header field"? (We get this a lot for HTTP and I've > > > forgotten if SMTP uses the same rule...) > > Fixed > > > > > > 3. When receiving an MDN, the MDN could be related to an existing > > > sent message. This is already covered by [RFC8621] in the > > > EmailSubmission object. [...] > > > > > > (The "DeliveryStatus" member, in particular, right?) > > The "mdnBlobIds" member is enough explicit for me to not have to write it. > > > Section 1.3 > > > > > > The value of this "urn:ietf:params:jmap:mdn" property is an empty > > > object in the account's "accountCapabilities" property. > > > > > > I presume it's also an empty object in the server's "capabilities" > > > property as well (and we should probably say so). > > Fixed. > > > Section 2 > > > > > > It's a little interesting to me that RFC 8261 did not define or mention > > > specific access to the User-Agent string but we need to have a specific > > > reportingUA here. I do recognize that it's (an optional) part of the > > > RFC 8098 ABNF, and that RFC 8098 mentions the relevant security > > > considerations already. Perhaps a subtle nudge in this section that the > > > "null" option may have better privacy properties would be appropriate. > > > (We may also revisit whether/what to include in the examples for > > > reportingUA.) > > Added. > > > o finalRecipient: "String|null" Recipient for which the MDN is being > > > issued. if set, it overrides the value that would be calculated > > > by the server from the Identity. > > > > > > Could we get a couple more words to support the definite article? (I am > > > not sure which Identity is "the" Identity just from this context; it is > > > only later on that we discover that there is an identityId in the > > > MDN/send arguments.) > > Added. > > > > > > o extensionFields: "String[String]|null" Object where keys are > > > extension-field names and values are extension-field values. > > > > > > I used process of elimination to conclude that these are RFC 8098 > > > extension-field ABNF names/values; I don't know if there's a good way to > > > hint the reader of that fact. > > I tried to add a hint. > > > > > > o actionMode: "String" This MUST be one of the following strings: > > > "manual-action" / "automatic-action" > > > > > > o sendingMode: "String" This MUST be one of the following strings: > > > "mdn-sent-manually" / "mdn-sent-automatically" > > > > > > I recognize that this is entirely the responsibility of RFC 8098 and not > > > this document, but is it valid to combine "automatic-action" with > > > "mdn-sent-manually"? I am not 100% I understand the semantics. > > > > Yes it is explained in RFC 8098 : > > > > "manual-action [...] (This might include the case when the user has > > manually configured her MUA to automatically respond to valid MDN > > requests.)" > > > > > Section 2.1 > > > > > > The latter because of the implicit call > > > to Email/set and the use of Identities, described below. [...] > > > > > > nit: does this sentence have a verb? > > Fixed. > > > > > > The following already registered SetError would mean: > > > > > > nit: these are the SetError types, right? > > Fixed. > > > Section 3.x > > > > > > It might be helpful to use a different creation ID for the different > > > classes of example (though not required by the protocol). > > Fixed. > > > Section 3.1 > > > > > > "extension": { > > > "X-EXTENSION-EXAMPLE": "example.com" > > > } > > > > > > nit(?): somehow I thought X- extensions were generally thought to not be > > > needed/useful anymore. > > Fixed. > > > Section 5 > > > > > > In order to enforce trust regarding the relation between the user > > > sending an email message and the identity of this user, the server > > > SHOULD validate in conformance to the provided Identity that the user > > > is permitted to use the finalRecipient value and return a > > > forbiddenFrom error if not. > > > > > > "enforce" and "SHOULD" are not words I usually see in combination. > > Fixed, I meant reinforce. > >