From nobody Fri Jul 2 15:04:22 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F323A0962; Fri, 2 Jul 2021 15:02:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: jmap@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162526337316.26814.3889191275846452184@ietfa.amsl.com> Date: Fri, 02 Jul 2021 15:02:53 -0700 Archived-At: Subject: [Jmap] jmap - Requested session has been scheduled for IETF 111 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 22:03:00 -0000 Dear Jim Fenton, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jmap Session 1 (2:00 requested) Tuesday, 27 July 2021, Session III 1600-1800 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/111/sessions/jmap.ics Request Information: --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Jim Fenton Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 15 Conflicts to Avoid: People who must be present: Alexey Melnikov Bron Gondwana Jim Fenton Murray Kucherawy Neil Jenkins Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jul 11 23:17:12 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8574E3A003C; Sun, 11 Jul 2021 23:17:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <162607062635.13061.11329185295400770517@ietfa.amsl.com> Date: Sun, 11 Jul 2021 23:17:06 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-gondwana-jmap-blob-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 06:17:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP Blob management extension Author : Bron Gondwana Filename : draft-gondwana-jmap-blob-02.txt Pages : 10 Date : 2021-07-11 Abstract: The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP PUT and GET on defined endpoint. This binary data is called a "Blob". This extension adds additional ways to create and access Blobs, by making inline method calls within a standard JMAP request. This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other datatypes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-gondwana-jmap-blob/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-gondwana-jmap-blob-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-gondwana-jmap-blob-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 11 23:19:04 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B15B33A010A; Sun, 11 Jul 2021 23:18:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <162607073768.30241.9410748258846553381@ietfa.amsl.com> Date: Sun, 11 Jul 2021 23:18:57 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-blob-00.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, 12 Jul 2021 06:18:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP Blob management extension Author : Bron Gondwana Filename : draft-ietf-jmap-blob-00.txt Pages : 10 Date : 2021-07-11 Abstract: The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP PUT and GET on defined endpoint. This binary data is called a "Blob". This extension adds additional ways to create and access Blobs, by making inline method calls within a standard JMAP request. This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other datatypes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-blob/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-blob-00.html Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 03:14:16 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB033A104A; Mon, 12 Jul 2021 03:14:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <162608485472.32047.7626081966947876549@ietfa.amsl.com> Date: Mon, 12 Jul 2021 03:14:14 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-smime-04.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 10:14:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : S/MIME signature verification extension to JMAP Author : Alexey Melnikov Filename : draft-ietf-jmap-smime-04.txt Pages : 7 Date : 2021-07-12 Abstract: This document specifies an extension to JMAP for returning S/MIME signature verification status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 06:17:25 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEA33A1770; Mon, 12 Jul 2021 06:17:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <162609583233.7862.496931021805403582@ietfa.amsl.com> Date: Mon, 12 Jul 2021 06:17:12 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-07.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 13:17:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSContact: A JSON representation of contact data Authors : Robert Stepanek Mario Loffredo Filename : draft-ietf-jmap-jscontact-07.txt Pages : 22 Date : 2021-07-12 Abstract: This specification defines a data model and JSON representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-jscontact-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 07:20:53 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF743A19E9; Mon, 12 Jul 2021 07:20:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <162609965230.7688.15598682188929208452@ietfa.amsl.com> Date: Mon, 12 Jul 2021 07:20:52 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-smime-05.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 14:20:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : S/MIME signature verification extension to JMAP Author : Alexey Melnikov Filename : draft-ietf-jmap-smime-05.txt Pages : 7 Date : 2021-07-12 Abstract: This document specifies an extension to JMAP for returning S/MIME signature verification status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 07:24:55 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E433A1A03 for ; Mon, 12 Jul 2021 07:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 b94X5yUj0Gw4 for ; Mon, 12 Jul 2021 07:24:48 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBA13A19F8 for ; Mon, 12 Jul 2021 07:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1626099886; d=isode.com; s=june2016; i=@isode.com; bh=GrOPS/lU2Xfw+pZ67VKDpqMLsyFVa0r0KbJNuBgMvrI=; 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=LJpvC8AtPayiGQcyrUkW3QzebkzajAtAj17XEsDFc7Eu4gcl/XYqhEAltzmIwwG7dH2E4F dqtyc495hv6F336MFH60PWZ3NYWjC91Z+lpj0utAQ5abeTiTWTzvtTmus6h3zps9zu8MdM 30oAnQmXNyTuKWrLaisD3nlvu3o0JkE=; Received: from [192.168.1.222] (host31-49-142-125.range31-49.btcentralplus.com [31.49.142.125]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 12 Jul 2021 15:24:46 +0100 To: jmap@ietf.org References: <162609965230.7688.15598682188929208452@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <75b5a0ad-d0cb-8759-a839-d87cec5725fa@isode.com> Date: Mon, 12 Jul 2021 15:24:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <162609965230.7688.15598682188929208452@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-smime-05.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 14:24:54 -0000 Hi, On 12/07/2021 15:20, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-05 In the last 2 revisions I've changed the document from Informational to Proposed Standard and did a few minor editorial changes. I think the document is ready for IESG. Best Regards, Alexey From nobody Mon Jul 12 10:01:12 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D81D03A2300; Mon, 12 Jul 2021 10:00:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <162610925584.19850.1109278246348143853@ietfa.amsl.com> Date: Mon, 12 Jul 2021 10:00:55 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-vcard-06.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, 12 Jul 2021 17:01:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSContact: Converting from and to vCard Authors : Mario Loffredo Robert Stepanek Filename : draft-ietf-jmap-jscontact-vcard-06.txt Pages : 42 Date : 2021-07-12 Abstract: This document defines how to convert contact information as defined in the JSContact [draft-ietf-jmap-jscontact] specification from and to vCard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact-vcard/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-vcard-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-vcard-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 15 02:43:39 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CE03A24A6 for ; Thu, 15 Jul 2021 02:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 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, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 7QFw3PjA4QYp for ; Thu, 15 Jul 2021 02:43:33 -0700 (PDT) Received: from waldorf.isode.com (unknown [79.77.168.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD023A24A4 for ; Thu, 15 Jul 2021 02:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1626342205; d=isode.com; s=june2016; i=@isode.com; bh=EZQ13zYFUxoR3semKVtngakNgFyMVbQneu4B0KdRniE=; 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=UXlnO1r/Pt/nS0adXsfufseviy98zTyJaQ0SHxRCmiHmYLw4TC14VfaKnidbswiV8HGQy0 BlmC7hwSzzw+++DRwHaSYo2WTiZ1Lp4RznuLsXu3MUpDXdcIjegMLv+30PA6FWDbVr7fM5 p90Ke07ASR2DNtLpxP30ffmrGR2a6eQ=; Received: from [192.168.1.222] (host5-81-100-105.range5-81.btcentralplus.com [5.81.100.105]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 15 Jul 2021 10:43:25 +0100 To: Neil Jenkins , IETF JMAP Mailing List References: <161556955834.14605.6554401803097956040@ietfa.amsl.com> <258b0c5c-efc1-4534-b1da-8972c73c806c@dogfood.fastmail.com> From: Alexey Melnikov Message-ID: <1c69fa1b-d41a-1ef2-6189-85c1b5ae3978@isode.com> Date: Thu, 15 Jul 2021 10:43:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <258b0c5c-efc1-4534-b1da-8972c73c806c@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------6C71FEA53858EA1B8A845286" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Last Call for draft-ietf-jmap-smime-03 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, 15 Jul 2021 09:43:38 -0000 This is a multi-part message in MIME format. --------------6C71FEA53858EA1B8A845286 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Neil, On 23/03/2021 03:44, Neil Jenkins wrote: > I've read through this version and it seems fine. There are a few > typos/grammar nits but I'm sure the RFC editors will pick those up. It > might be worth adding a paragraph in the /Conventions/ section like we > did in 8621 to note > that the type signatures syntax is from 8620. Sorry, I missed your message earlier. I've added the text in the upcoming -06. Best Regards, Alexey --------------6C71FEA53858EA1B8A845286 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Neil,

On 23/03/2021 03:44, Neil Jenkins wrote:
I've read through this version and it seems fine. There are a few typos/grammar nits but I'm sure the RFC editors will pick those up. It might be worth adding a paragraph in the Conventions section like we did in 8621 to note that the type signatures syntax is from 8620.

Sorry, I missed your message earlier. I've added the text in the upcoming -06.

Best Regards,

Alexey

--------------6C71FEA53858EA1B8A845286-- From nobody Thu Jul 15 03:02:22 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6411E3A2543 for ; Thu, 15 Jul 2021 03:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.305 X-Spam-Level: X-Spam-Status: No, score=-1.305 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, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FX8_UPp2QQCZ for ; Thu, 15 Jul 2021 03:02:06 -0700 (PDT) Received: from waldorf.isode.com (unknown [79.77.168.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4583A254E for ; Thu, 15 Jul 2021 03:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1626343324; d=isode.com; s=june2016; i=@isode.com; bh=dK2EofkkSdowUUwHhIsROIAUAbwaY1m2bvLMb4nfxD8=; 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=gnn95SUpW3wfB0pbJnt9GTYAxFuowlRIw1bc7kMfwCGBbPszsNzyDWv0Ebxo3t2r1pP1Pu 0ehy87j0Ph63VcqAy0zC8uP57ZB2zHix0TI6FismT/BghhCIY92c5IvYrPvTeW3skFrkOT bJ4WqchrH7hp4Za6Z8s1gsVmLmPY/XE=; Received: from [192.168.1.222] (host5-81-100-105.range5-81.btcentralplus.com [5.81.100.105]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 15 Jul 2021 11:02:03 +0100 To: Bron Gondwana , jmap@ietf.org References: <56e51eaa-7f72-4ded-adda-61962fa4a7bb@dogfood.fastmail.com> From: Alexey Melnikov Message-ID: Date: Thu, 15 Jul 2021 11:01:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <56e51eaa-7f72-4ded-adda-61962fa4a7bb@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------1A9E788205B8F4933B9296FB" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-smime-02 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, 15 Jul 2021 10:02:21 -0000 --------------1A9E788205B8F4933B9296FB Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Bron, Sorry for missing replying to your message! On 08/07/2020 13:41, Bron Gondwana wrote: > Hi Alexey, > > Here's a review of the latest smime document. > > *Specific Sections:** > * > > 3. Addition to the capabilities object > > Are you happy to use the 'smime' name for just this part rather than=20 > "urn:ietf:params:jmap:smimeverify" or something? That would be fine with me. Can I use "-" :-), e.g.=20 "urn:ietf:params:jmap:smime-verify"? > 4. Extension to Email/get for S/MIME signature verification > smimeStatus: "String|null". > Servers MAY return other values not defined below. Client > MUST treat unrecognized values as "unknown" or "signed/failed". Note > that the value of this property might change over time. > > Does this need a registry of possible values? I am ambivalent and open to suggestions on this. My implementation also=20 has "encrypted+signed/failed" and "encrypted+signed/verified", but this=20 is for cases when messages are both encrypted and signed (and can be=20 decrypted, which is not covered by this document). > In all other cases > it is set to the date and time of when S/MIME signature was verified > the last time. > > I would phrase this as "was most recently verified".=C2=A0 I had to=20 > re-parse it because of the two different uses of "time" in the sentence. I used your suggested text, thank you. > As recalculating > these values is expensive for the server they MAY be cached for up to > 10 minutes from the moment when they were calculated. > > Do we need a way to tell the server that a fresh calculation is=20 > required and it must not use its cache? In -05 the value is automatically recalculated after 10 minutes. Is this=20 sufficient? Also, is 10 mins a good default for caching this value? > > Examples: > > Some of the JSON keys are missing quotes around them. Fixed in -06. > 5. Open Issues > > From my memory, the issue here is allowing a query "did you verify=20 > this message as being correctly signed in the past, and if so when?".=C2= =A0=20 > That's really useful when looking back at old emails!=C2=A0 I would like t= o=20 > see that feature, but I'm also not likely to be a heavy user of this=20 > feature, so I think feedback from people who use S/MIME is best on that. -05 has "smimeStatusAtDelivery", which is almost doing what you ask. I=20 think it is sufficient. Do you agree? > > I think I would just want a single value=20 > smimeLastSuccessfulVerification: "UTCDate|null".=C2=A0 Which raises anothe= r=20 > issue, and I'm not sure if this is an issue with the language in the=20 > other specs referenced or specific to this one. > > The word "VERIFIED" is used with two different meanings in this=20 > document.=C2=A0 IT's used in 'smimeVerifiedAt' to mention a time when a=20 > check was done, and it's used in 'signed/verified' to refer to a=20 > SUCCESSFUL verification.=C2=A0 These are not the same thing, and I'd be=20 > keen to see a different word used for one of them.=C2=A0 "signed/valid" fo= r=20 > example. I would rather not change returned string values, as I already=20 implemented them. Maybe change 'smimeVerifiedAt' to 'smimeValidatedAt'=20 instead? > > *General comments:** > * > > Should we also extend Email/query to have a couple more filters -=20 > `hasSmime` and `hasVerifiedSmime` are the two I can think of. - where=20 > hasSmime is any status other than NULL, while hasVerifiedSmime is only=20 > the value "signed/verified". Hmm, sound like a good idea. I think this will be used, so I am happy to=20 add. Best Regards, Alexey --------------1A9E788205B8F4933B9296FB Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Bron,

Sorry for missing replying to your message!

On 08/07/2020 13:41, Bron Gondwana wrote:
Hi Alexey,

Here's a review of the latest smime document.

Specific Sections:

3.  Addition to the capabilities object

Are you happy to use the 'smime' name for just this part rather than "urn:ietf:params:jmap:smimeverify" or something?
That would be fine with me. Can I use "-" :-), e.g. "urn:ietf:params:jmap:smime-verify"?
4.  Extension to Email/get for S/MIME signature verification

 smimeStatus: "String|null".

   Servers MAY return other values not defined below.  Client
   MUST treat unrecognized values as "unknown" or "signed/failed".  Note
   that the value of this property might change over time.

Does this need a registry of possible values?
I am ambivalent and open to suggestions on this. My implementation also has "encrypted+signed/failed" and "encrypted+signed/verified", but this is for cases when messages are both encrypted and signed (and can be decrypted, which is not covered by this document).
In all other cases
   it is set to the date and time of when S/MIME signature was verified
   the last time.

I would phrase this as "was most recently verified".=C2=A0 I had to re-parse it because of the two different uses of "time" in the sentence.
I used your suggested text, thank you.
As recalculating 
   these values is expensive for the server they MAY be cached fo=
r up to
   10 minutes from the moment when they were calculated.

Do we need a way to tell the server that a fresh calculation is required and it must not use its cache?
In -05 the value is automatically recalculated after 10 minutes. Is this sufficient? Also, is 10 mins a good default for caching this value?

Examples:

Some of the JSON keys are missing quotes around them.
Fixed in -06.
5.  Open Issues

From my memory, the issue here is allowing a query "did you verify this message as being correctly signed in the past, and if so when?".=C2=A0 That's really useful whe= n looking back at old emails!=C2=A0 I would like to see that feature, but I'm also not likely to be a heavy user of this feature, so I think feedback from people who use S/MIME is best on that.
-05 has "smimeStatusAtDelivery", which is almost doing what you ask. I think it is sufficient. Do you agree?

I think I would just want a single value smimeLastSuccessfulVerification: "UTCDate|null".=C2=A0 Which raises another issue, and I'm not sure if this is an issue with the language in the other specs referenced or specific to this one.

The word "VERIFIED" is used with two different meanings in this document.=C2=A0 IT's used in 'smimeVerifiedAt' to mention a time when a check was done, and it's used in 'signed/verified' to refer to a SUCCESSFUL verification.=C2=A0 These are not the same thing, and I'd be keen to see a different word used for one of them.=C2=A0 "signed/valid" for example.
I would rather not change returned string values, as I already implemented them. Maybe change 'smimeVerifiedAt' to 'smimeValidatedAt' instead?

General comments:

Should we also extend Email/query to have a couple more filters - `hasSmime` and `hasVerifiedSmime` are the two I can think of. - where hasSmime is any status other than NULL, while hasVerifiedSmime is only the value "signed/verified".
Hmm, sound like a good idea. I think this will be used, so I am happy to add.

Best Regards,

Alexey

--------------1A9E788205B8F4933B9296FB-- From nobody Wed Jul 21 05:13:13 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7383A138B for ; Wed, 21 Jul 2021 05:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=w1HPpefy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TBdq8hia 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 fzQHJWoxAe5m for ; Wed, 21 Jul 2021 05:13:06 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FC03A1388 for ; Wed, 21 Jul 2021 05:13:05 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2D534320097C for ; Wed, 21 Jul 2021 08:13:00 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Wed, 21 Jul 2021 08:13:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=M043kJvilz8eWAyy4fNv+jNUNt8W3tKKHT3aldm GrgE=; b=w1HPpefyi6wdJ6eGqVMRak+mYAjQr1XMl95fzwSwVuTz/9ofzziQwso Q+llCV7C/muKZJimtzp/9DNY2CVp9w78VkLrbC034yAPmE1UdRQ7kh8KP6r4DKhU 1LlniAlFx9p8kCXvRL/5kExSziRIC2dES07ibfsQ+r0C0so0CgIQ/5bLyLlIhyan JUzbWplIzTemI5wQZpHMQp53ZV6obyTUdvNJXxfATM/n7VJhURyWcae/goX9OUPf 74pt9W6YmEa4z4VEZlwOxM2bLqHwuI2aqL9BEgx/O3mZsV5BRncqheBEJYV8mEKm ThNGSQIGRFIgwQc7DAlL/jIjvMdxkig== 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=fm3; bh=M043kJvilz8eWAyy4fNv+jNUNt8W3 tKKHT3aldmGrgE=; b=TBdq8hiaGMvC/OYckynE8RsjH4nT1pJFEseUgdE/70z8F 1Fq2p6Ns966sZa0XaeoUCAzfhtoH1AtSbKMj/SagrZxTyJp5gRpc4t2WMCHdF6cp 9fQK2Hk2XQl6OuUhapTzwPTeO+OGKZklBvRkP60f7+SdF6GEWJjLU5NrE05KpCQz x48DnsNJJVN4Pk2iVqZpmJKdg7dWuoBqbIjgwX+ZmurOBrJdnA5d7zVvvJyAajct pXjUHIEaURNHEbeBGJ/trFzraTgC6GltvwPDfh79qcdm/LZ6BnnWdGioFqz95Mvc 2g9Vr8dzxxtYoSHkJAFKiIHWKtLhmBxgMl6+6Wfkg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfeeggdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre erjeenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeelheetledvvefhte efgfeujeegffeutdfgheefiefhhfevueevteefueevtddtgeenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 80767AC0E8F; Wed, 21 Jul 2021 08:12:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-981-g92194709fa-fm-ubox-20210721.002-g92194709 Mime-Version: 1.0 Message-Id: Date: Wed, 21 Jul 2021 14:12:38 +0200 From: "Robert Stepanek" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=932bd6f2b795465db3ded57eaf88acac Archived-At: Subject: [Jmap] JSContact: how to localize content 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, 21 Jul 2021 12:13:12 -0000 --932bd6f2b795465db3ded57eaf88acac Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable At the joint CALEXT/JMAP interim meeting in April we discussed opt= ions how localize JSContact values. This can be useful to provide names = and addresses in multiple languages within the same contact. In VCARD th= is is achieved with the LANG parameter. We would now like to find consensus how to achieve this in JSContact. *Current approach* The current scheme in the spec defines a LocalizedString object for fiel= ds that can be localized. A LocalizedString has a value and optional loc= alized variants of this value: "addresses": { "addr1": { "city": { "value": "Tokyo", "localizations": { "jp": "=E6=9D=B1=E4=BA=AC" } } } } The idea is to keep values and their localizations close. It is built on= the assumption that the majority of values will have localized variants. *Proposed approach* Multiple participants in the interim meeting vouched for replacing the c= urrent approach with the one defined in section 4.6.1 of the JSCalendar RFC. That = is, the "localizations" property is a JSON object where the keys are lan= guage tags, and the values are patch objects which overwrite one or mult= iple properties within a contact. A main benefit of this is to reuse for the same approach in both JMAP c= alendars and contacts. It treats localized content as the exception, not= the norm, and the data types should reflect this. Any property value ca= n be localized (except if the spec explicitly forbids it). In contrast, = only values of LocalizedString can be localized in the current approach. This an example how to localize a single address field: "addresses": { "addr1": { "city": "Tokyo", } }, "localizations": { "jp": { "addresses/addr1/city":"=E6=9D=B1=E4=BA=AC" } } To fully localize an address, one would write: "localizations": { "jp": { "addresses/addr1": { "city": "=E6=9D=B1=E4=BA=AC" } } } *Finding consensus* Mario and I would now like to know which approach you prefer, or any oth= er you would like to propose. Our goal is to reach clear consensus. We l= ook forward to your feedback. Thanks, Robert --932bd6f2b795465db3ded57eaf88acac Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
At the joi= nt CALEXT/JMAP interim meeting in April we discussed= options how localize JSContact values. This can be useful to provide na= mes and addresses in multiple languages within the same contact. In VCAR= D this is achieved with the LANG parameter.

We would now like to find consensus how to achieve this in JSContact.

Current approach
T= he current scheme in the spec defines a LocalizedString object for field= s that can be localized. A LocalizedString has a value and optional loca= lized variants of this value:
"addresses": {
  "addr1": {
    "city": {
      "value": "Tokyo",
      "localizations": {
        "jp": "=E6=9D=B1=E4=BA=AC"
      }
    }
  }
}
The idea is to keep values and= their localizations close. It is built on the assumption that the major= ity of values will have localized variants.
Proposed approach
Multiple= participants in the interim meeting vouched for replacing the current a= pproach with the one defined in section 4.6.1 of the JSCalendar RFC.= That is, the "localizations" property is a JSON object where the keys a= re language tags, and the values are patch objects which overwrite one o= r multiple properties within a contact.

A m= ain benefit  of this is to reuse for the same approach in both JMAP= calendars and contacts. It treats localized content as the exception, n= ot the norm, and the data types should reflect this. Any property value = can be localized (except if the spec explicitly forbids it). In contrast= , only values of LocalizedString can be localized in the current approac= h.

This an example how to localize a = single address field:
"addresses": {
  "addr1": {
    "city": "Tokyo",
   }
},
"localizations": {
  "jp": {
    "addresses/addr1/city":"=E6=9D=B1=E4=BA=AC"
  }
}
To fully localize an address, one would wri= te:
=
"localizations": {
  "jp": {
    "addresses/addr1": {
      "city": "=E6=9D=B1=E4=BA=AC"
    }
  }
}


Finding co= nsensus
Mario and I would now like to know which appro= ach you prefer, or any other you would like to propose. Our goal is to r= each clear consensus. We look forward to your feedback.
Thanks,
Robert
--932bd6f2b795465db3ded57eaf88acac-- From nobody Thu Jul 22 05:05:49 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3143E3A43D5 for ; Thu, 22 Jul 2021 05:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 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_LOW=-0.7, 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=HGNa0REF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NZ5iscky 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 Q0vhA3c8CemE for ; Thu, 22 Jul 2021 05:05:42 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0E93A43D1 for ; Thu, 22 Jul 2021 05:05:42 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4A0045C0148 for ; Thu, 22 Jul 2021 08:05:41 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Thu, 22 Jul 2021 08:05:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=D9Usd0y +PDlomn77PrtGQVZdH05MXLjE30USLhsrVWk=; b=HGNa0REFC/j1n2gqbffeBmA FPMdVh3Mj3RTk2S5bcz5HC5x8J7k9dly7XrKm3Mp/8KzaCCE03Z7zAklNz52KxBF EwFGDaWTENlgqpqELD092WeXfQkJEc56bMbgq9kIg2B28DvcolYGPtNz14oqrcEs Mmppl4fjhKRGxYZOE+CT2jWpZ13LvW05oeZ/WBmju06Rh3oDNDE58evB/AueteQU e8MyTGXhOC5ne4s2YAZWZSgXZIynNI4gYIJmRZGZBG56gMKYWZ17kK7h76bCEQw/ IVkynS1j4+x04TKm24A1eAGdCOo5KIpPvHEa+qsID5pyGySu+scW6vze8sBeNEA= = 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=fm3; bh=D9Usd0 y+PDlomn77PrtGQVZdH05MXLjE30USLhsrVWk=; b=NZ5iscky048OyLbWy6lJqk KVNt8tJx9akwXJR3BPl6cxngwznXGqOSJFsFYQa28kSjsUWCXsh8ull/5F88bVfX cNdyRjOP5jtTv5mUVOFglSYcY11SDopmJoRpsNiM3URsW519JNRnpYeVt1Yq9yBS 6pL+lVr7FZCF02u/o0xOeLkqFGkIyKuB2PT0Fawg0bbI2eIhUc4K9CeRh5EkqVFO yy+IaGe3IgKaegEcVeJ928GHsuKsSFEHJLilLf5He8QUXgJuI9/qlFtXNTn8crKL dT1ojE11IP0A25QCuPMtNUQr/LyRIY0Lm/HYm+WwLTfdvJGsLrAbQkpSeauDJ35g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfeeigdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BC98CAC0E8C; Thu, 22 Jul 2021 08:05:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-996-g43b7eb240e-fm-ubox-20210722.001-g43b7eb24 Mime-Version: 1.0 Message-Id: <5829f2c2-5ea5-44fb-aff4-5fc9bed78622@dogfood.fastmail.com> In-Reply-To: References: Date: Thu, 22 Jul 2021 22:05:36 +1000 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=f82a272bdf724dbdbadbc0392fc371df Archived-At: Subject: Re: [Jmap] JSContact: how to localize content 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, 22 Jul 2021 12:05:48 -0000 --f82a272bdf724dbdbadbc0392fc371df Content-Type: text/plain I am very much in favour of the proposed approach rather than the current approach. Our experience with vCards at least is that the vast majority of contact cards to do not store multiple localised forms. The proposed approach makes sense both from a consistency point with JSCalendar, and more importantly it keeps the simple case simple, which makes adoption much easier. Neil. --f82a272bdf724dbdbadbc0392fc371df Content-Type: text/html
I am very much in favour of the proposed approach rather than the current approach. Our experience with vCards at least is that the vast majority of contact cards to do not store multiple localised forms. The proposed approach makes sense both from a consistency point with JSCalendar, and more importantly it keeps the simple case simple, which makes adoption much easier.

Neil.
--f82a272bdf724dbdbadbc0392fc371df-- From nobody Thu Jul 22 05:42:52 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9D43A4509 for ; Thu, 22 Jul 2021 05:42:51 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=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=wm246NRY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vw+ErC23 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 nALv9Oed9Mkr for ; Thu, 22 Jul 2021 05:42:45 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B653D3A4505 for ; Thu, 22 Jul 2021 05:42:45 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A5AE4320092E for ; Thu, 22 Jul 2021 08:42:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 22 Jul 2021 08:42:43 -0400 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=fm3; bh=1IkjK4JEs+NM4Thr2QP0hhYoPYw X1Z+sWlwQ5F82w7c=; b=wm246NRYSOWfzezMBgn+u+gW/Q1wMkbFx16rdciDNhW AYyXKhkGzemZ5lcPx/s/9XbqalTpRnD8tXBcLZMEkr2WOsdD1BAelqXsM5pkU5Mp pDVNaACLI5u/CUHEZOXwRkcqbidZamVpPLJz6fAy384dPi3I1Ajx1gSKP69ks6gK 45T2oFOxeaUyPpGeQvFfNL259Rd22qKpHe+s8ojgo6dQeQeX6stssRnEtnU8zgh7 HyUDPg5hP/iKjsCTxhwmBnfbWW5UEMfIrCfmK2qbrKo5+u69d8lOfmYFXXSwnsvm kgaT8XSYGP0vOtcHyHthU6bchSLcD3LB9ndYI6TrbJA== 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=fm3; bh=1IkjK4 JEs+NM4Thr2QP0hhYoPYwX1Z+sWlwQ5F82w7c=; b=vw+ErC23Y/B4wh29abzD2N brP4nS/g0l8j6Upt86FtqveyYAytWj1wTFv2BoCoLpIqcAqTqmhreg4bzteifPHU nNHmd1ACMBk2dnoJMCqMlvuwlOR3mWsPVRC9uzn2mACOzZfwzeQmkAlkQcSZq54q d3V1xkHxKd78taup1Pxx2T2dA3jHbatp4JeELCIuhGCfW9Akdw3wZM1abGiZOwIY P5I6Ten0cRE47GDxg7AkbuWNaX37M8xuR8nHX4usl08yh3PckzGx4XNEPF9TQT0k dSxxLdpc3nOKrw+5NTuufXLeXSqzSfdbWQpv8kMxHAyf3LpZMdF3LQYvm4Rqvnew == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfeeigdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshht mhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeffuefhvefggfdvudeuvdetieejue dvvdekudeggedvffevgfduffeuieelgeeggeenucffohhmrghinhepihgvthhfrdhorhhg necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhurh gthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 22 Jul 2021 08:42:42 -0400 (EDT) To: jmap@ietf.org References: <5829f2c2-5ea5-44fb-aff4-5fc9bed78622@dogfood.fastmail.com> From: Ken Murchison Message-ID: <99e9fdfd-7612-1949-0362-8f8c87143775@fastmail.com> Date: Thu, 22 Jul 2021 08:42:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <5829f2c2-5ea5-44fb-aff4-5fc9bed78622@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------014B936EFD77DC952211A29A" Content-Language: en-US Archived-At: Subject: Re: [Jmap] JSContact: how to localize content 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, 22 Jul 2021 12:42:51 -0000 This is a multi-part message in MIME format. --------------014B936EFD77DC952211A29A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I agree with all of Neil's points. On 7/22/21 8:05 AM, Neil Jenkins wrote: > I am very much in favour of the proposed approach rather than the > current approach. Our experience with vCards at least is that the vast > majority of contact cards to do not store multiple localised forms. > The proposed approach makes sense both from a consistency point with > JSCalendar, and more importantly it keeps the simple case simple, > which makes adoption much easier. > > Neil. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------014B936EFD77DC952211A29A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I agree with all of Neil's points.


On 7/22/21 8:05 AM, Neil Jenkins wrote:
I am very much in favour of the proposed approach rather than the current approach. Our experience with vCards at least is that the vast majority of contact cards to do not store multiple localised forms. The proposed approach makes sense both from a consistency point with JSCalendar, and more importantly it keeps the simple case simple, which makes adoption much easier.

Neil.

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

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------014B936EFD77DC952211A29A-- From nobody Thu Jul 22 23:39:23 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5FD3A1FAB for ; Thu, 22 Jul 2021 23:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 a8qUBF9gx3RL for ; Thu, 22 Jul 2021 23:39:18 -0700 (PDT) Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FB63A1FA8 for ; Thu, 22 Jul 2021 23:39:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 77E1BA135 for ; Fri, 23 Jul 2021 08:39:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.audriga.com Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjW_vgKWkgFf for ; Fri, 23 Jul 2021 08:38:48 +0200 (CEST) Received: from [192.168.0.94] (HSI-KBW-46-223-163-221.hsi.kabel-badenwuerttemberg.de [46.223.163.221]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id 6CAB6A10A for ; Fri, 23 Jul 2021 08:38:48 +0200 (CEST) To: jmap@ietf.org References: <5829f2c2-5ea5-44fb-aff4-5fc9bed78622@dogfood.fastmail.com> <99e9fdfd-7612-1949-0362-8f8c87143775@fastmail.com> From: Joris Baum Message-ID: <13211b0d-a5c5-5b6e-3477-000d775eadbd@audriga.com> Date: Fri, 23 Jul 2021 08:38:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <99e9fdfd-7612-1949-0362-8f8c87143775@fastmail.com> Content-Type: multipart/alternative; boundary="------------A3BF5621C7FC781AB09A0B63" Content-Language: en-US Archived-At: Subject: Re: [Jmap] JSContact: how to localize content 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, 23 Jul 2021 06:39:22 -0000 This is a multi-part message in MIME format. --------------A3BF5621C7FC781AB09A0B63 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Total agreement from my side as well :) . On 22.07.21 14:42, Ken Murchison wrote: > > I agree with all of Neil's points. > > > On 7/22/21 8:05 AM, Neil Jenkins wrote: >> I am very much in favour of the proposed approach rather than the >> current approach. Our experience with vCards at least is that the >> vast majority of contact cards to do not store multiple localised >> forms. The proposed approach makes sense both from a consistency >> point with JSCalendar, and more importantly it keeps the simple case >> simple, which makes adoption much easier. >> >> Neil. >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > -- > Kenneth Murchison > Senior Software Developer > Fastmail US LLC > > _______________________________________________ > 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 -------------------------------------------------------------------------- --------------A3BF5621C7FC781AB09A0B63 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Total agreement from my side as well :) .

On 22.07.21 14:42, Ken Murchison wrote:

I agree with all of Neil's points.


On 7/22/21 8:05 AM, Neil Jenkins wrote:
I am very much in favour of the proposed approach rather than the current approach. Our experience with vCards at least is that the vast majority of contact cards to do not store multiple localised forms. The proposed approach makes sense both from a consistency point with JSCalendar, and more importantly it keeps the simple case simple, which makes adoption much easier.

Neil.

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

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

_______________________________________________
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
--------------------------------------------------------------------------
--------------A3BF5621C7FC781AB09A0B63-- From nobody Mon Jul 26 04:29:47 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5872A3A0C6E; Mon, 26 Jul 2021 04:29:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <162729898630.15937.14533377626361469574@ietfa.amsl.com> Date: Mon, 26 Jul 2021 04:29:46 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-smime-06.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, 26 Jul 2021 11:29:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : S/MIME signature verification extension to JMAP Author : Alexey Melnikov Filename : draft-ietf-jmap-smime-06.txt Pages : 8 Date : 2021-07-26 Abstract: This document specifies an extension to JMAP for returning S/MIME signature verification status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 26 04:42:34 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFA73A0CFA; Mon, 26 Jul 2021 04:42:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <162729975242.10898.3071838914343141510@ietfa.amsl.com> Date: Mon, 26 Jul 2021 04:42:32 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-smime-07.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 11:42:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : S/MIME signature verification extension to JMAP Author : Alexey Melnikov Filename : draft-ietf-jmap-smime-07.txt Pages : 8 Date : 2021-07-26 Abstract: This document specifies an extension to JMAP for returning S/MIME signature verification status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 26 04:48:56 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758F33A0D3D for ; Mon, 26 Jul 2021 04:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHwL1F--jAI0 for ; Mon, 26 Jul 2021 04:48:50 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 415C33A0D30 for ; Mon, 26 Jul 2021 04:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1627300098; d=isode.com; s=june2016; i=@isode.com; bh=Ztjo2hmurDz0lRwKs2fjRo1B2MFLLspTWdB5WaBQSI0=; 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=tR2V2Ltq7NGQEY1s70WN05jUt6E55ANTSUXMnjya1wWitA2/FqHsB70TOhdGprRzLq9MsL H9mRD9nTMUbLeJV8VWXLlh+etcoxWT5E0j+X4roqhH3ePkBxabzLGSqwB1RXjgil1ucsPv H79obQJ2LgfLEKsYeT/IKdutvMG2aRc=; Received: from [192.168.1.222] (host5-81-100-7.range5-81.btcentralplus.com [5.81.100.7]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 26 Jul 2021 12:48:17 +0100 To: jmap@ietf.org, Bron Gondwana References: <162729975242.10898.3071838914343141510@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <00188cb6-9bdd-6739-2b98-8a3a42c16976@isode.com> Date: Mon, 26 Jul 2021 12:48:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 In-Reply-To: <162729975242.10898.3071838914343141510@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-smime-07.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 11:48:55 -0000 Hi, On 26/07/2021 12:42, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-07 Changes since -05 - I believe I addressed most of comments from Bron (and Neil). Version -06 had a formatting glitch, so I posted -07 to fix. If people want to see recent changes, please compare versions 05 and 07. Best Regards, Alexey From nobody Mon Jul 26 04:53:46 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECD03A0D64; Mon, 26 Jul 2021 04:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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 eZ9ehD_ukTfI; Mon, 26 Jul 2021 04:53:39 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 3F11D3A0D61; Mon, 26 Jul 2021 04:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1627300417; d=isode.com; s=june2016; i=@isode.com; bh=sgZhiHgcDWRmPZEPEbswIORW28w3O9CoH26qrZr3+Cc=; 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=ZsfxysugkBN/HjGwEDwmLbtLJclncb2UOnLO6d0DfdE778YOpAikL41FUE7SpQ7H6TkuPV sohnZo5X1bnP+T2F5waAx5y9if3PD2V58HgOivGaPICUfv3CbLYbbWws5Lrig635NeKZR6 PnoyvxXoD5Qo6F8eSaGq060DprFbAvk=; Received: from [192.168.1.222] (host5-81-100-7.range5-81.btcentralplus.com [5.81.100.7]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 26 Jul 2021 12:53:37 +0100 To: jmap@ietf.org, jmap-chairs@ietf.org From: Alexey Melnikov Message-ID: <2d2eb020-4eb3-dc84-910f-1c77e3c174a7@isode.com> Date: Mon, 26 Jul 2021 12:53:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [Jmap] 2 JMAP S/MIME drafts X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 11:53:44 -0000 Hi all, I've just updated S/MIME signature verification draft: draft-ietf-jmap-smime-07.txt. I also recently posted a new draft on S/MIME signing and encryption: . This addresses one outstanding charter deliverable agreed earlier. Obviously this still needs to go through full WG process. Best Regards, Alexey P.S. I will not be able to attend JMAP session this time, as I volunteered to co-chair OHTTP BOF without realizing that OHTTP and JMAP are in conflict. My apologies for this. From nobody Tue Jul 27 04:30:39 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 885CA3A2082; Tue, 27 Jul 2021 04:30:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <162738543349.925.14044621335972020250@ietfa.amsl.com> Date: Tue, 27 Jul 2021 04:30:33 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-calendars-06.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: Tue, 27 Jul 2021 11:30:34 -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 Calendars Authors : Neil Jenkins Michael Douglass Filename : draft-ietf-jmap-calendars-06.txt Pages : 43 Date : 2021-07-27 Abstract: This document specifies a data model for synchronizing calendar data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-jmap-calendars-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-calendars-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 27 20:09:31 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E33A18B1 for ; Tue, 27 Jul 2021 20:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=zuh+ZI6J; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZE9ZuFuX 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 6qlhLXm0zmR6 for ; Tue, 27 Jul 2021 20:09:24 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5593A18B0 for ; Tue, 27 Jul 2021 20:09:24 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 7FD2932001AB for ; Tue, 27 Jul 2021 23:09:22 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute3.internal (MEProxy); Tue, 27 Jul 2021 23:09:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=ZgNiAgH ON48FGwoZT2lhi/fmWtTpgAGz4q+cjvfgYjQ=; b=zuh+ZI6JS8BSkyaGkLc/kqL hqiYCDGWOIrTUTOzEuR539QZ1faXbR8ZFplw7EJMWrobaaYn6ZF4jbpURAndxjiC W/hVuBSb8yuLdMHJqrzc+SRS45fbpvsnKnwnfpFCWl6cT/fWgZGawyroYzqrtFQS 3ZnZqcca64NSO+8+1wz6xqQKHaR0LvGfpG9cC1jCWpJqoGn7BhQ3KwlzkdazGQMg Zp7LQI/S64P6PswuW8p8k2xZdyJUPWlETonFfQSYSepwNAj0gDOBwc48RdOAK3wo xwaF55STwMBFVVi6P5zBSWjPfU15vlDG6qMTLc1IWZv8p6CeNcwteQa/hxiibOQ= = 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=fm3; bh=ZgNiAg HON48FGwoZT2lhi/fmWtTpgAGz4q+cjvfgYjQ=; b=ZE9ZuFuXw23aDLyKpVM/t/ MjWHpxz2q0yR3JvukdUfZEbkN/kx2QEvbf+37qf2hF3Qt5++2q3nCTm8iiMEt/0L 1y0itoUFl7UxLMe6rKg05lxH5aXt/i6mgxeHAs+Ykh2a+/WOXvKxHiWXAz13IkbQ ra4Fm/XZ2EOKPo/Tn6IBLgo67pbRpc0ksPkyOJSJchHd1C53MnSya0OaTLZ7glam jdwVEa4q0sOv1ubWHu9OAKkk7z+S693lZ4QsV8Qx3Ga37VJYbrt2LXjBTZ7y/ZPd tSS8DzWup96aP53WTAmQ5p/yKVbIt1uK3jrNpEOk+GYoAL+xuCc9/Iu8EvMsUQ6g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeekgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B2F3BAC0DD0; Tue, 27 Jul 2021 23:09:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1002-g563fbe43fc-fm-ubox-20210727.001-g563fbe43 Mime-Version: 1.0 Message-Id: <0ff71967-a93c-4041-b156-20ecf904765e@dogfood.fastmail.com> In-Reply-To: <00188cb6-9bdd-6739-2b98-8a3a42c16976@isode.com> References: <162729975242.10898.3071838914343141510@ietfa.amsl.com> <00188cb6-9bdd-6739-2b98-8a3a42c16976@isode.com> Date: Wed, 28 Jul 2021 13:09:21 +1000 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=7a2f6d9703dd48229fad7cf5918ecf32 Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-smime-07.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 03:09:30 -0000 --7a2f6d9703dd48229fad7cf5918ecf32 Content-Type: text/plain Looks fine to me. Neil. --7a2f6d9703dd48229fad7cf5918ecf32 Content-Type: text/html
Looks fine to me.

Neil.
--7a2f6d9703dd48229fad7cf5918ecf32-- From nobody Thu Jul 29 22:40:33 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE893A1C97 for ; Thu, 29 Jul 2021 22:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=jysvHoxO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SPGb6A9f 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 ARx6KGN97KJA for ; Thu, 29 Jul 2021 22:40:25 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BED83A1C96 for ; Thu, 29 Jul 2021 22:40:25 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 73C985C0139 for ; Fri, 30 Jul 2021 01:40:24 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Fri, 30 Jul 2021 01:40:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=ZX0qtGGQVnDX9YpfLMzx4ViUIZim9l7Q4+iIM+j plqs=; b=jysvHoxOJLmXq8Xjm94ZtV1yP5w5e+P70pINYRYs1KYbBiCCuEPs8Gm weLLCnb5yaKU8N8+ARnmWpQSxH0CXbAqXp0leKVs+tGKcr2/X0OiGsK3SfiRx6s7 LFCS5U7ovzP20g6rf0/UwvxXCtaqPYoaSw3gxDjt/AB2lRpVhUtqA4ML60HPez9K hQEofzUZMbW6pCnIYxZkuVhhguGm58ZFRIYf5eOGwf/cnz/6nPaa5dHinPrhczKU 5HTR9BZ28yzEtiEpGrnspxoTKQLsbeSDSpcSvx53vyJcuSFOgGwmnEEVwc+GkvnN 8+hTE39UEb0FHiXas6UY064L16/P2kQ== 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=fm3; bh=ZX0qtGGQVnDX9YpfLMzx4ViUIZim9 l7Q4+iIM+jplqs=; b=SPGb6A9fEozANu+tHgionhyhKBapTe6we5QqH30OkTihH i1WWwIkk6JBPN8pJzvEjrUAyrO5orVIegzQ4Sg9aP/82OKDXJMKj4Udj5CmacHyK Wg+loiCotOI4ErKsq18xJDl5OAqz1Nfqeex2bWiqmKZ72/NyKaB7nM0UQuym2PyB xc5oCOP3f1GMgzVEWOw/wDoqUOn4cAUYLESwypnSwGBSu8r/VTIEmwfQ3tPDsVSK eS58kPUUgvAk6rVW3AWionVXR/DVrWpIi8mURIRK2Y/H71cnPd6QnnLMOx84sBkI ilWK1vJAxQr0haXu6brZULz8kjjZXkMqSxGv4EkyA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheeggdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhephfejheekjeekheevue dtjeetiefhffefudeitddtjefhleetveeuheduledtueffnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 35641AC0E77; Fri, 30 Jul 2021 01:40:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1002-g563fbe43fc-fm-ubox-20210727.001-g563fbe43 Mime-Version: 1.0 Message-Id: <17c0d9b2-fe07-4c79-b3e1-86fbdcc2f20d@dogfood.fastmail.com> Date: Fri, 30 Jul 2021 15:40:04 +1000 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=d3c7525ce15040fa9713fe250132b99e Archived-At: Subject: [Jmap] IETF111 minutes uploaded 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, 30 Jul 2021 05:40:32 -0000 --d3c7525ce15040fa9713fe250132b99e Content-Type: text/plain Hi All, I've uploaded the minutes for our meeting the other day. Full minutes are online here: https://datatracker.ietf.org/doc/minutes-111-jmap/ I've also extracted the action points: *ACTION: ALL keep working jmap-calendars design on the list, hopefully finalise by end of the year.** * *** * *ACTION: Bron to check who needs to approve errata for core spec.** * *ACTION: Bron to follow up with DISPATCH about large file problem work** * *ACTION: Bron to issue a call for adoption for draft-melnikov-jmap-smime-advanced** * *ACTION: Bron to publish new jmap-blob draft with capability information and registry instructions** * *ACTION: Bron to update milestones for JMAP WG** * *** * *ACTION: Neil to add property for parent JMAP ID to server-side expanded event recurrences** * *** * *ACTION: Robert to write a draft for storing metadata/history on JMAP objects.* As you can see, mostly me... Please make sure you do your action points, and ideally not 2 days before the next meeting! Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --d3c7525ce15040fa9713fe250132b99e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,
ACTION: Bron to publish new jmap-blob draft = with capability information and registry instructions
ACTION: Bron to update milestones= for JMAP WG

ACTION: Neil to = add property for parent JMAP ID to server-side expanded event recurrence= s

ACTION: Robert to write a d= raft for storing metadata/history on JMAP objects.

As you can see, mostly me...

Please make sure you do your action points, and ideally not 2 = days before the next meeting!

Cheers,

Bron.

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


--d3c7525ce15040fa9713fe250132b99e-- From nobody Thu Jul 29 23:27:40 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD01A3A1E13 for ; Thu, 29 Jul 2021 23:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=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=qoKboHzv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eN8Wh4+b 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 Nku-S3FbE8Mp for ; Thu, 29 Jul 2021 23:27:33 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9533A1E11 for ; Thu, 29 Jul 2021 23:27:33 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 1C5F932004AE for ; Fri, 30 Jul 2021 02:27:33 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Fri, 30 Jul 2021 02:27:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=HiR8xALzp0f1mvwXzsGLNQwuZiVMCyn+QT0v1Bd 0Xpo=; b=qoKboHzvYXlijq59uXf6YH1sdKid060era1UimrgDjDr93Pcx47F/5p ZWlY6fzCK7Br6FfxW6YirRKOkW9QXKJCdYWPFBJUyfmqOQdoGjiVtuCbKgw0ZoIi m4fgAawQ8JMXFSfZ7uPmgui/AzXlBp4LNvXClq6zdIivE83ZjD3KRh4hfbhnEVbA XJpksRmdnI+9VMiW2OWjLdYHTOidTTyg0uAJup+qJxS6VX+S1mu5e3aM2Nlk9xWH 1KQYB8yrdKoXQ6mWTQsOnZ8uyhCt4vro5nAaguRTgwNcHfxMs92IycJ+fjwK4OO5 OuW2wohTupS+3IYZ9ZMBWYVDYtHDWbA== 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=fm3; bh=HiR8xALzp0f1mvwXzsGLNQwuZiVMC yn+QT0v1Bd0Xpo=; b=eN8Wh4+bR0NyuxG1uXiqyNynsJI7SXx51K0D9em1bNwD8 qa5FjwDXyqBd3b8SyYd7kiE2DXyHk8uPXoBPLtohmFW6tJcBHeINWHuaOnUakn+A rqoGr/nNTqDgMoXhUrGyrxEIpwpTRTzIalc78s8fyEC1MB8MtHbxATwREbdQhm5n sH5/SENORQMQHtevEk9YvvfDAYHq4LK0DgGi1TBELzd3Kg+3CVx6RoowMiMfKkb4 hacUUs0wF9arvKLbeHUKsIvir0k1sergsqICW1YAQdqyuBuyDWhKd7XkUj91H6F2 zSq5209B9HFFJog8aa4lV09TREvi6iYTlnd0yzZpg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheeggdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhephfejheekjeekheevue dtjeetiefhffefudeitddtjefhleetveeuheduledtueffnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 54818AC0E77; Fri, 30 Jul 2021 02:27:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1002-g563fbe43fc-fm-ubox-20210727.001-g563fbe43 Mime-Version: 1.0 Message-Id: <322b349a-3346-406f-9605-b1aad3911bea@dogfood.fastmail.com> Date: Fri, 30 Jul 2021 16:27:12 +1000 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=485fa4e98e9e48f5be8066a77e1b587b Archived-At: Subject: [Jmap] Call for adoption of draft-melnikov-jmap-smime-advanced 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, 30 Jul 2021 06:27:39 -0000 --485fa4e98e9e48f5be8066a77e1b587b Content-Type: text/plain Hi All, This is the promised document from Alexey for creating S/MIME emails via JMAP: https://datatracker.ietf.org/doc/draft-melnikov-jmap-smime-advanced/ The meeting at IETF111 had some comment about the name 'advanced', but were otherwise in favour of adoption. This message starts a formal call for adoption of this document. Please reply with any comments for or against. This call for adoption runs for 2 weeks and finishes on Friday 13 August 2021. If adopted, there will be opportunity for changes (like bikeshedding on the name 'advanced') before publishing. Thanks, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --485fa4e98e9e48f5be8066a77e1b587b Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

This is the promised document from = Alexey for creating S/MIME emails via JMAP:
The meeting at IETF111 had some= comment about the name 'advanced', but were otherwise in favour of adop= tion.

This message starts a formal call for adoption of t= his document.  Please reply with any comments for or against. = This call for adoption runs for 2 weeks and finishes on Friday 13 Augus= t 2021.

If adopted, there will be opportunity for changes (= like bikeshedding on the name 'advanced') before publishing.

Thanks,

Bron.

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


--485fa4e98e9e48f5be8066a77e1b587b-- From nobody Thu Jul 29 23:31:38 2021 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 570273A1E37 for ; Thu, 29 Jul 2021 23:31:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162762669634.26623.13028736344711417362@ietfa.amsl.com> Date: Thu, 29 Jul 2021 23:31:36 -0700 From: IETF Secretariat Archived-At: Subject: [Jmap] Milestones changed for jmap WG X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 06:31:36 -0000 Changed milestone "Adopt a document for creating Blobs via JMAP method call", set due date to July 2021 from December 2020, resolved as "Done", added draft-gondwana-jmap-blob to milestone. Changed milestone "Submit JMAP S/MIME signature validation document to the IESG", set due date to July 2021 from March 2021. Changed milestone "Adopt a document for S/MIME key management and server side signing/encryption", set due date to August 2021 from March 2021, added draft-melnikov-jmap-smime-advanced to milestone. Changed milestone "Submit Sieve document to the IESG", set due date to December 2021 from December 2020. Changed milestone "Adopt a document defining JMAP access to addressbooks", set due date to December 2021 from January 2021. Changed milestone "Submit JMAP Calendars document to the IESG", set due date to December 2021 from January 2021. Changed milestone "Submit document for Blobs via JMAP to the IESG", set due date to December 2021 from January 2021, added draft-ietf-jmap-blob to milestone. Changed milestone "Submit JSON Contact document to IESG", set due date to December 2021 from May 2021. Changed milestone "Submit JMAP Quotas document to the IESG", set due date to April 2022 from March 2021. Changed milestone "Submit document with guidance for implementation of IMAP servers and proxies (Informational)", set due date to April 2022 from July 2021. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Fri Jul 30 18:06:35 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102173A1BB4 for ; Fri, 30 Jul 2021 18:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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=minilop.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 LQq2WO-TMhrG for ; Fri, 30 Jul 2021 18:06:29 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 1757D3A1BB3 for ; Fri, 30 Jul 2021 18:06:28 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id g23-20020a17090a5797b02901765d605e14so16765764pji.5 for ; Fri, 30 Jul 2021 18:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minilop.net; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition :content-transfer-encoding; bh=Nvg3UGZeaOx7YBxGoDihKbsrZ3aRtB0OWP+kphB+v+I=; b=fnmQ0nc6ryzwrO6ENGbHfLIqr87raEjqRBbWBBmRMlgfe/xmyYMrNzXaCTmDh+kmJP XFcRTPG5qu0c4kE0JKl0ooFPDXYZ9xSMTjCs7XMa4k7s9s4LobXboYdLO2X7u+QRHBLt sW1Xc6jjxhAnV68R+D/jpWAxOAF3G6r7jCEY4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:content-transfer-encoding; bh=Nvg3UGZeaOx7YBxGoDihKbsrZ3aRtB0OWP+kphB+v+I=; b=dWj4wG42w8tgv506isU0lotL3OuYbYZ8puZZoRLos7n09XTCK+dfNZGOutZDAz+BxB 69iG6T/abNopGzvpUavUKf7cEatI1QkL3rOPUMmc9hUARFzYhtPh8kSGuIWOKAyg3KdE XotOUkcv87PuIcKm5t6XAmvy12Z0cxWDzUjj+KbKO6xRm4pN9YyXKqEzd8H+MXtKWS4F wfjh+XW/emZnDCcUXKaeFTTvGhqgG1Z2ytxDDHOkkMThZd6hV6PmbIMPGpNGyRIDpYsg BxzIAmwipsi58J4W64kiSCt6UvNAGTgotP9W3DyB98jIcQMe1b51HEMDJsg6a+BACPph 4v+g== X-Gm-Message-State: AOAM5332Tecnnl658vdwjqQeo5Sqk7356a21AULzLQAYiZ6aOCTWSK0B SSW6PfBAf60JvCvO6wjLHSqH/5APk82ddT5E X-Google-Smtp-Source: ABdhPJzAoY39bzcntABaL4OUu87ty0BekqC/oorb6qHNaniUW61L0aYPUpniiapE9Z1W+hFL1WGD0w== X-Received: by 2002:a05:6a00:1786:b029:32c:c315:7348 with SMTP id s6-20020a056a001786b029032cc3157348mr5555372pfg.42.1627693587082; Fri, 30 Jul 2021 18:06:27 -0700 (PDT) Received: from eh (63-230-166-62.ptld.qwest.net. [63.230.166.62]) by smtp.gmail.com with ESMTPSA id n123sm4238257pga.69.2021.07.30.18.06.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 30 Jul 2021 18:06:26 -0700 (PDT) Received: by eh (sSMTP sendmail emulation); Fri, 30 Jul 2021 18:06:25 -0700 Date: Fri, 30 Jul 2021 18:06:25 -0700 From: Jamey Sharp To: jmap@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-TUID: XejWAivLySco Archived-At: Subject: [Jmap] the large email (attachment) problem X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 01:06:34 -0000 I've been thinking about Bron's "large email problem" since the meeting on Monday. I know this isn't really in scope for JMAP WG but given that it came up here I'm going to share some thoughts here anyway… I think the requirements on any solution are: - preserve whatever level of confidentiality, integrity, and authenticity are provided by attaching a file as a MIME part; - enable mail agents to apply content filtering and retention policies as if the file were attached as a MIME part; - and, at the sender's discretion, allow recipients to access the attachment even if they don't implement this solution. On the other hand, I think it must not impose any particular file storage or lookup mechanism. In particular, we can't tell people to just send the hash of the content after making it available in some specific DHT. For example, I like IPFS as a content addressed store, but mandating its use would be a mistake. Giving senders the option to choose systems like IPFS is important, though, I think. A sketch of a solution that I think meets all of these requirements looks like this: In the text (plain or HTML) parts of the email, large attachments are still referenced by a URL provided by the sender, as has become common practice today. However, we add new attachment-like parts which serve several purposes: to indicate that a given URL should be treated like an attachment at the recipient, to provide metadata hints, and to provide alternate URLs for retrieving the attachment. Alternative URLs can be provided so that the default URL exposed to unaware recipients can be an HTTP URL while more capable recipients can use e.g. an ipfs:// URL. Each source URL MAY be accompanied by an encryption key which can be used to decrypt the representation from that source. If populating that source exposes either the URL or the contents more broadly than the contents of the email, then that source SHOULD include an encryption key. (This extends any confidentiality protection applied to the email to cover the attachment as well.) Metadata hints include content type, length, and disposition, which SHOULD be provided. These apply to the attachment regardless of which source the recipient retrieves it from. In addition, a cryptographically secure hash of the attachment contents MAY be provided. If any of the sources does not already bind the URL to the content immutably, then a hash SHOULD be provided. (This extends any integrity protection applied to the email to cover the attachment as well, and similarly for any authenticity protection.) So for example, Gmail could generate a Drive link for the unencrypted file, but also pin an encrypted copy of the file into IPFS and provide the key and IPFS URL as an alternative source. A recipient that doesn't understand the attachment information would use the Drive link when the user asks for it, as usual. But a mail delivery agent supporting this extension could fetch from either source, apply content filtering, store a copy of the attachment for as long as the email is retained, and provide the local copy to the recipient instead of the original link. The recommendation that either every source URL is immutable or the hash of the content is provided means that a mail delivery agent doesn't need to fetch the attachment again if it sees a second email with the same source (assuming the hash of the copy it already has matches the new expected one). For messages with many recipients this may have both privacy and performance advantages. On the other hand, a sender which violates the immutability recommendation may cause recipients to see attachments from different emails, possibly with different recipients, which could violate confidentiality expectations. Should it be upgraded to MUST, or is this just a note for the security considerations section? As an alternative to IPFS that this design enables, I could envision major email providers jointly operating a DHT for looking up those encrypted attachments which any of them have copies of. Given an HTTP interface to that DHT that takes a content ID and returns a redirect to one of the email providers' storage platforms, all of the participating providers could generate alternate links for their attachments using URLs to that interface. (Note that the content IDs here need to be a hash over the encrypted contents, not the plaintext.) I'm curious what people think of this approach and I hope it turns out to be helpful in conversations with DISPATCH. Jamey From nobody Sat Jul 31 10:00:58 2021 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512AA3A0E51 for ; Sat, 31 Jul 2021 10:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=iecc.com header.b=uR/HfrE5; dkim=pass (2048-bit key) header.d=taugh.com header.b=EwaFH9TS 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 AfyfeDV-kFYk for ; Sat, 31 Jul 2021 10:00:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 F1A0E3A0E4D for ; Sat, 31 Jul 2021 10:00:51 -0700 (PDT) Received: (qmail 82079 invoked from network); 31 Jul 2021 17:00:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1409c.610581c1.k2107; bh=exicJksBAVxsa+f0fKOGeMpiyAu3wn2k5HL8eU1Wr3w=; b=uR/HfrE5cSx5eypBLXdZzl3OkYQd9I9YdvXxdGM0Eu+rZdgQf0iO38rO3eisy3wqijLhaXk7M1geZhT1JZPhWZJRlwugtJd/Q2/IvfIPaCVuqRXsXKC1jOpZ7xaDPsRiSYhYFgUtE/OpGyx7De17YiESiF6uWh6qzYuJF44sHwTeeP9pgegKpbWaXi5AtM5/ZhIDdHoKdS4kammOehqxqmvV8mnbtbOZH/bCpVl2eDJHC9y+V3QMUBP5wmGFCS3rFzQ1I11kZdjg5JGQ1AvKC7ATZyphRPS4byjHjQIb9Jwf2AM+efvoB++vodDXxG4cqvrlwNuLYuYk6rz5nRFLyw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1409c.610581c1.k2107; bh=exicJksBAVxsa+f0fKOGeMpiyAu3wn2k5HL8eU1Wr3w=; b=EwaFH9TSJFz4cvnfWvjFXwG34K4XL8xS+M+xu5YWsxSNPZWhv9tzMNkwVOPXGvvMn1b2Mt2BGUX0SOxIuoxm4U5AJ36iPZqxVCDVw106yUU+CTNqepthmkTFGfkSrWG5oam6azIKjMt718ANrESbHcHGdP4RKvH2DvmRTudLvyMB6eQScM94agi3MobR2LsLLUIvJIfMfWou39TizXyn6tXWp26dA8W/ijq7WKao6xpUPUQGkx+blv3vRW+ahQTYUsf24b1KouZSjFHkxrwBiFDhcpWYS5eMevV9t127U9HlkxtYh16q4EQrObaKqphmSZE3RHtu9j0dAP5nZo7zxA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 31 Jul 2021 17:00:48 -0000 Received: by ary.qy (Postfix, from userid 501) id DE0772563EB0; Sat, 31 Jul 2021 13:00:47 -0400 (EDT) Date: 31 Jul 2021 13:00:47 -0400 Message-Id: <20210731170047.DE0772563EB0@ary.qy> From: "John Levine" To: jmap@ietf.org Cc: jamey@minilop.net In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Jmap] the large email (attachment) problem X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 17:00:57 -0000 It appears that Jamey Sharp said: >In the text (plain or HTML) parts of the email, large attachments are >still referenced by a URL provided by the sender, as has become common >practice today. However, we add new attachment-like parts which serve >several purposes: to indicate that a given URL should be treated like an >attachment at the recipient, to provide metadata hints, and to provide >alternate URLs for retrieving the attachment. ... Take a look at message/external-body in RFC 2017, 2046 and 2912. It already has size, URL, expiration, and content-features parameters. We could add a few new attributes to external-body like an optional encryption key. R's, John