From nobody Fri Feb 1 13:03:38 2019 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 447AD130EAB; Fri, 1 Feb 2019 13:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 Kr2Xvamcz4Bl; Fri, 1 Feb 2019 13:03:20 -0800 (PST) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (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 E782E124408; Fri, 1 Feb 2019 13:03:16 -0800 (PST) Received: by mail-io1-f42.google.com with SMTP id t24so6903047ioi.0; Fri, 01 Feb 2019 13:03:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T4uFEEcHGkkBVBKCRB+bk1dmyVMK+VtHu5ekOi1SsvE=; b=nOHpMbZerC8lsRO0eTFdy89SrEeB9tDGfdJZaTkY9qwZk0UCc9IZ3D/6IYm+RC+BiP FyvlsDeYjpW8gou/B651F4D4tZOV8PAgOqFyw/mbka7HeVb3cJMnI0ggRc8Kx+oXtY0+ YAEr6Rkz776C3LFMRjpagaaJ1GpnhKWiz+PMK1VgFr4Cl9ZaVOClJTOXxZjRmEi7108h EzPatwYo7JZxnj25aMcrtdgRVIGGQX57CV2zHGiM+gvZsoFPukkuLmZzWrKJ416CYBKO c5lxkzM1kGSIuZqtgYcParjZdtYzT+/ffJ/acNEf6Xx2uqdmoQQgz2KymLFRsmX1aAqV NPQg== X-Gm-Message-State: AHQUAuZT/I0tHWcNu42Vm1z05gC2iZj42HKd8WBeav4eL744aZBsLmHR mtsKYYKb/pQjD2Rd5Przv8w879YROuVOF9Pf+e8= X-Google-Smtp-Source: ALg8bN7vGE0jroxDg2GtA+/HJFUxmMmMofXz3JYozf1c6cHQt8Hizc58iAsNBHEYLVAQufc70/VM8AjkiMI8leWTp3w= X-Received: by 2002:a6b:6814:: with SMTP id d20mr24965510ioc.76.1549054995749; Fri, 01 Feb 2019 13:03:15 -0800 (PST) MIME-Version: 1.0 References: <154900252324.10128.7132833415832444034@ietfa.amsl.com> In-Reply-To: <154900252324.10128.7132833415832444034@ietfa.amsl.com> From: Barry Leiba Date: Fri, 1 Feb 2019 16:03:04 -0500 Message-ID: To: Dan Romascanu Cc: draft-ietf-jmap-mail.all@ietf.org, gen-art@ietf.org, ietf@ietf.org, jmap@ietf.org Content-Type: multipart/alternative; boundary="000000000000c261520580db78a6" Archived-At: Subject: Re: [Jmap] Genart last call review of draft-ietf-jmap-mail-14 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, 01 Feb 2019 21:03:23 -0000 --000000000000c261520580db78a6 Content-Type: text/plain; charset="UTF-8" Thanks, Dan, for taking time to review it! Barry On Fri, Feb 1, 2019 at 1:28 AM Dan Romascanu wrote: > Reviewer: Dan Romascanu > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-jmap-mail-?? > Reviewer: Dan Romascanu > Review Date: 2019-01-31 > IETF LC End Date: 2019-02-04 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This is a clear and complete specification which is READY for publication > from > a Gen-ART perspective. > > Major issues: > > Minor issues: > > Nits/editorial comments: > > > --000000000000c261520580db78a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Dan, for taking time to review it!

Barry

On Fri, Feb 1, 2019 at 1:28 AM Dan Rom= ascanu <dromasca@gmail.com>= wrote:
Reviewer: Dan Romascanu
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-jmap-mail-??
Reviewer: Dan Romascanu
Review Date: 2019-01-31
IETF LC End Date: 2019-02-04
IESG Telechat date: Not scheduled for a telechat

Summary:

This is a clear and complete specification which is READY for publication f= rom
a Gen-ART perspective.

Major issues:

Minor issues:

Nits/editorial comments:


--000000000000c261520580db78a6-- From nobody Sun Feb 3 07:24:51 2019 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 0F63712426A; Sun, 3 Feb 2019 07:24:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jmap@ietf.org, brong@fastmailteam.com, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154920748998.10965.10940069948264157655.idtracker@ietfa.amsl.com> Date: Sun, 03 Feb 2019 07:24:49 -0800 Archived-At: Subject: [Jmap] jmap - New Meeting Session Request for IETF 104 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 15:24:50 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: doh oauth saag iasa2 dmarc artarea uta dispatch extra Second Priority: tls httpbis ace lamps core t2trg People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Flipcharts: please specify number in Special Requests field Special Requests: One of the authors would prefer late in the week. --------------------------------------------------------- From nobody Thu Feb 7 02:26:37 2019 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 B825912DDA3; Thu, 7 Feb 2019 02:26:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jmap@ietf.org, brong@fastmailteam.com, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154953519671.23555.3499883549303308040.idtracker@ietfa.amsl.com> Date: Thu, 07 Feb 2019 02:26:36 -0800 Archived-At: Subject: [Jmap] jmap - Update to a Meeting Session Request for IETF 104 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 10:26:37 -0000 An update to a meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: doh oauth saag iasa2 dmarc artarea uta dispatch extra Second Priority: tls httpbis ace lamps core t2trg People who must be present: Barry Leiba Alexey Melnikov Neil Jenkins Bron Gondwana Resources Requested: Special Requests: Many of the same people attend both JMAP and EXTRA, so if they can be placed consecutively, it would be useful, ideally in the afternoon. Two sessions consecutively in the same room would be ideal. --------------------------------------------------------- From nobody Thu Feb 7 03:26:12 2019 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 41E2013110B for ; Thu, 7 Feb 2019 03:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ERVN6e51q_jQ for ; Thu, 7 Feb 2019 03:26:10 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABDB1310F7 for ; Thu, 7 Feb 2019 03:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1549538769; d=isode.com; s=june2016; i=@isode.com; bh=MNo0bLQC3BbkgG3tng3XSdGfaO2+Vj8XaXlVT6zx7HQ=; 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=cF9WevFHRLPj7pibgXZ6aBim8GkjRiuVtAdCmQJ3OBLF/MtKy2DNe/qMzaiuL6fEPPWSmf TSb4iLwg8rzR6PKKTvrCsARO4kR62WYG9wueETpy6URaw1E0tJL7LTx2dorSRIDsI3xFtd q/5RSHsKs+GT1+KbfMTyGpMgZMMGo2U=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 7 Feb 2019 11:26:09 +0000 To: "jmap@ietf.org" From: Alexey Melnikov Message-ID: <57d1323f-d546-5c70-713a-0eca66a2fa3b@isode.com> Date: Thu, 7 Feb 2019 11:25:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.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] Looking for volunteers to co-chair JMAP WG X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 11:26:11 -0000 Dear WG participants, With Barry Leiba being selected as another Application and RealTime Area Director, I am looking for another co-chair to replace him to work with Bron. If you are interested or know somebody who might be interested, please reply to me directly. Thank you, Alexey, as AD From nobody Mon Feb 11 01:01:50 2019 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 112C8130E85 for ; Mon, 11 Feb 2019 01:01:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154987570806.18578.9349962737591481056.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2019 01:01:48 -0800 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: Mon, 11 Feb 2019 09:01:48 -0000 Changed milestone "Submit document with guidance for implementation of IMAP servers and proxies (Informational)", set due date to June 2019 from March 2018. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Mon Feb 11 04:27:51 2019 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 8E879130E8C for ; Mon, 11 Feb 2019 04:27:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154988807057.18676.4700523830517630396.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2019 04:27:50 -0800 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: Mon, 11 Feb 2019 12:27:51 -0000 Changed milestone "Update charter to reflect current and planned work", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Mon Feb 11 06:25:40 2019 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 1E1EE130E95 for ; Mon, 11 Feb 2019 06:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=j6yknGfx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S0H3VvLA 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 3Q6Kei1jMSDe for ; Mon, 11 Feb 2019 06:25:33 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFAE12008A for ; Mon, 11 Feb 2019 06:25:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DF16822B97; Mon, 11 Feb 2019 09:25:31 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 11 Feb 2019 09:25:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=n60VsE90O3xsdpT1NGTnqp7K3 gUxrm/LYyABPAOYy/M=; b=j6yknGfxuFqzp50uwgvG8oAjJfquNGboIM5tnA4Fs WrKKEthnuZy4HLPgt6tL6CTxhdyvPrQ54knylcW+b62CRjfg7oHSjeiZwAOmjx4B pUis7Jd5yy4s3oP5XaGnwzGhpDcFhNWgqC4cotfcnru6cSB8bX71peqAhMPrygMF m1dXhHSxYE9pK6lwlfA31sR5naWxMqvSFd0Ffk8e1FxVOyykH/yGIBS2JtC7Q/Qc g+V8uhk5sfCVHnIa+y/Rr/vPd+rfSOlSVl/ZoQOQWhrDb8upuV/DoJ6cV031lD9i ZMl89q6kf9yjMblt5+hmfHKAkumzPvztBdOKWZbj/qj2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=n60VsE90O3xsdpT1N GTnqp7K3gUxrm/LYyABPAOYy/M=; b=S0H3VvLA169bxOXCzQfPQX3KZgUg0V0wr KVuFifDPI1Iw2VqsA9EuRGyfN/e4VH1INGlFHSlyJNQJsN2MdP1E7EsF/wAWbEkM f5zC7UmAyCitqq2JQCSoVvFpjkl4wCwUUmyqQLIqtSItWrBbBrpDSmNcjUP99M5H oNs71Tkn9ArJjunl3exZ9hD6kapUsT0iDUkYput8LDb4UA/4GnpeKIA73ATrqclu SP0x/T3wfTgZ15K503G/6EK51kQlGB3iPB163JuJ0k7VM5rfJK418tjNT2tYTU4T uXkaRhj2tteMza52sVRhXL0Y37KtwbXOyvhk9kcPDJgI4iXxsLuFw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleelgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfhffhf fvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceo sghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghi lhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EFF3220176; Mon, 11 Feb 2019 09:25:30 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 56629417 Message-Id: In-Reply-To: References: <153270520782.32707.4419621555491459322@ietfa.amsl.com> <2cf743f3-1c18-4062-848e-f85ca505fa55@sloti7d1t02> Date: Mon, 11 Feb 2019 09:25:30 -0500 From: "Bron Gondwana" To: jmap@ietf.org Cc: "Raphael OUAZANA" Content-Type: multipart/alternative; boundary=faf538988bc044e9bfe9d9bb7d7964fa Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mdn-00.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, 11 Feb 2019 14:25:36 -0000 --faf538988bc044e9bfe9d9bb7d7964fa Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rapha=C3=ABl, This document recently expired. Do you have the time to prepare an updat= ed draft before Prague? Thanks, Bron. On Sat, Dec 22, 2018, at 04:05, Raphael OUAZANA wrote: > Hi Neil, >=20 > Thank you very much for your feedback. Not enough time to handle it fo= r=20 > the moment, but it will be in my next year resolutions. >=20 > Regards, > Rapha=C3=ABl. >=20 > Le 2018-12-05 01:46, Neil Jenkins a =C3=A9crit : > > Finally sending my feedback on this draft, as promised in Bangkok. > > Sorry for the delay! Generally this looks good, just some comments t= o > > bring it up to date with the current JMAP conventions and a confusio= n > > over how you're actually meant to send the MDN! > >=20 > >> 2 [1]. Email/createMDN > >>=20 > >> The Email/createMDN method create a [RFC5322 [2]] message from > >> MDN > >> properties. > >=20 > > Where are these Email objects being created? It's not clear to me > > whether these are intended to be saved to the account's mail store o= r > > not. If they _are_ being saved to the mail store, we need to give > > mailboxIds and keywords arguments. If they are not being saved, but > > just being sent immediately, that needs to be made clear and the > > method probably renamed to _sendMDN_. > >=20 > >> It takes the following arguments: > >>=20 > >> o *accountId*: "String|null" The id of the account to use for > >> this > >> call. If "null", defaults to the "urn:ietf:params:jmap:mail" > >> primary account. > >=20 > > This should be non-optional now to match the same change in the othe= r > > JMAP specs. > >=20 > >> o *mdns*: "String[MDN]" A map of creation id (client specified) > >> to > >> MDN objects > >>=20 > >> An *MDN* object has the following properties: > >>=20 > >> o *referencedMessageId*: "String" Message Id of the received > >> message > >> the user wants to create an MDN for. > >=20 > > Again, to match current JMAP convention this should be > > referencedEmailId, or maybe just forEmailId? > >=20 > >> o *subject*: "String" Subject that will be used as "Subject" > >> header > >> for this MDN. > >>=20 > >> o *textBody*: "String" Human readable part of the MDN, as plain > >> text. > >>=20 > >> o *reportingUA*: "String" Name of the MUA creating this MDN. It > >> is > >> used to build the MDN Report part of the MDN. > >>=20 > >> o *disposition*: "Disposition" Object containing the diverse MDN > >> disposition options. > >>=20 > >> A *Disposition* object has the following properties: > >>=20 > >> o *actionMode*: "String" This MUST be one of the following > >> strings: > >> "manual-action" / "automatic-action" > >>=20 > >> o *sendingMode*: "String" This MUST be one of the following > >> strings: > >> "MDN-sent-manually" / "MDN-sent-automatically" > >>=20 > >> o *type*: "String" This MUST be one of the following strings: > >> "deleted" / "dispatched" / "displayed" / "processed" > >>=20 > >> See [RFC8098 [3]] for the exact meaning of these different > >> fields. > >=20 > > This all looks fine. > >=20 > >> If the _referencedMessageId_, _subject_, _textBody_, > >> _reportingUA_, > >> _disposition_ properties are invalid (e.g. missing, wrong type, > >> id > >> not found), the server MUST reject the import with an > >> "invalidProperties" SetError. > >>=20 > >> If the email cannot be created because it would take the account > >> over > >> quota, the creation should be rejected with a "maxQuotaReached" > >> SetError. > >=20 > > import -> create (I presume this is a copy-paste error) and the > > maxQuotaReached error is now just called overQuota. But rather than > > specify the last two paragraphs, probably better just to say it may > > return any standard SetError that is defined for a _create_ in the > > core spec. > >=20 > >> The response has the following arguments: > >>=20 > >> o *accountId*: "String" The id of the account used for this > >> call. > >>=20 > >> o *created*: "String[Email]" A map of the creation id to an > >> object > >> build from the referenced properties. The _blobId_ field of > >> the > >> Email objects can then be used to effectively send the MDN. > >=20 > > Again, I'm unclear how you are supposed to use the blobId to send th= is > > MDN. The EmailSubmission object uses an emailId reference rather tha= n > > a blobId. If it's creating an email object, it also needs to be clea= r > > about which properties the servers should return for each object in > > the response (e.g. id, threadId, blobId, etc.). > >=20 > >> o *notCreated*: "String[SetError]" A map of creation id to a > >> SetError object for each Email that failed to be created. The > >> possible errors are defined above. > >=20 > > This document needs a security considerations section at the end. > >=20 > > Cheers, > >=20 > > Neil. > >=20 > > Links: > > ------ > > [1] https://tools.ietf.org/html/draft-ietf-jmap-mdn-00#section-2 > > [2] https://tools.ietf.org/html/rfc5322 > > [3] https://tools.ietf.org/html/rfc8098 > >=20 > > _______________________________________________ > > Jmap mailing list > > Jmap@ietf.org > > https://www.ietf.org/mailman/listinfo/jmap >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --faf538988bc044e9bfe9d9bb7d7964fa Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Rapha=C3=ABl,

This document recently exp= ired.  Do you have the time to prepare an updated draft before Prag= ue?

Thanks,
Bron.

On Sat, Dec 22, 2018, at 04:05, Raphael OUAZANA wro= te:
Hi Neil,

Thank you very much for = your feedback. Not enough time to handle it for 
the moment, but it will be in my next year reso= lutions.

Regards,
Rapha=C3=ABl.

<= div style=3D"font-family:Arial;">Le 2018-12-05 01:46, Neil Jenkins a =C3= =A9crit :
> Finally s= ending my feedback on this draft, as promised in Bangkok.
> Sorry for the delay! Generally this lo= oks good, just some comments to
> bring it up to date with the current JMAP conventions and a conf= usion
> over how you're ac= tually meant to send the MDN!
> 
>> 2 [1].&n= bsp; Email/createMDN
>>=  
>> The Email/cre= ateMDN method create a [RFC5322 [2]] message from
>> MDN
>> properties.
>= ; 
> Where are these = Email objects being created? It's not clear to me
> whether these are intended to be saved to the = account's mail store or
> = not. If they _are_ being saved to the mail store, we need to give
> mailboxIds and keywords argume= nts. If they are not being saved, but
> just being sent immediately, that needs to be made clear a= nd the
> method probably r= enamed to _sendMDN_.
>&nbs= p;
>> It takes the foll= owing arguments:
>>&nbs= p;
>> o  *accountI= d*: "String|null" The id of the account to use for
>> this
>> call.  If "null", defaults to the "urn:ietf:params:j= map:mail"
>> primary ac= count.
> 
> This should be non-optional now to = match the same change in the other
> JMAP specs.
>&n= bsp;
>> o  *mdns*:= "String[MDN]" A map of creation id (client specified)
>> to
>> MDN objects
>> 
>> An *= MDN* object has the following properties:
>> 
&= gt;> o  *referencedMessageId*: "String" Message Id of the receiv= ed
>> message
=
>> the user wants to create an M= DN for.
> 
<= div style=3D"font-family:Arial;">> Again, to match current JMAP conve= ntion this should be
> ref= erencedEmailId, or maybe just forEmailId?
> 
>&= gt; o  *subject*: "String" Subject that will be used as "Subject"
>> header
>> for this MDN.
>> 
>> o  *textBody*: "String" Human readable part of the = MDN, as plain
>> text.<= br>
>> 
>> o  *reportingUA*: "String" Na= me of the MUA creating this MDN.  It
>> is
>= > used to build the MDN Report part of the MDN.
>> 
>> o  *disposition*: "Disposition" Object containing t= he diverse MDN
>> dispo= sition options.
>> = ;
>> A *Disposition* ob= ject has the following properties:
>> 
>>= o  *actionMode*: "String" This MUST be one of the following
>> strings:
>> "manual-action" / "automatic-action"<= br>
>> 
>> o  *sendingMode*: "String" Th= is MUST be one of the following
>> strings:
>>= "MDN-sent-manually" / "MDN-sent-automatically"
>> 
>> o  *type*: "String" This MUST be one of the following= strings:
>> "deleted" = / "dispatched" / "displayed" / "processed"
>> 
= >> See [RFC8098 [3]] for the exact meaning of these different
<= /div>
>> fields.
> 
> This all looks fine.
> 
>> If = the _referencedMessageId_, _subject_, _textBody_,
>> _reportingUA_,
>> _disposition_ properties are invalid (e.g. miss= ing, wrong type,
>> id<= br>
>> not found), the serv= er MUST reject the import with an
>> "invalidProperties" SetError.
>> 
>> If the email cannot be created because it would take the accou= nt
>> over
>> quota, the creation should be re= jected with a "maxQuotaReached"
>> SetError.
>&nb= sp;
> import -> create = (I presume this is a copy-paste error) and the
> maxQuotaReached error is now just called overQuot= a. But rather than
> speci= fy the last two paragraphs, probably better just to say it may
=
> return any standard SetError that= is defined for a _create_ in the
> core spec.
>&nbs= p;
>> The response has = the following arguments:
>= > 
>> o  *= accountId*: "String" The id of the account used for this
>> call.
>> 
= >> o  *created*: "String[Email]" A map of the creation id to = an
>> object
<= div style=3D"font-family:Arial;">>> build from the referenced prop= erties.  The _blobId_ field of
>> the
>> = Email objects can then be used to effectively send the MDN.
> 
> Again, I'm unclear how you are supposed to use the blo= bId to send this
> MDN. Th= e EmailSubmission object uses an emailId reference rather than
=
> a blobId. If it's creating an ema= il object, it also needs to be clear
> about which properties the servers should return for each o= bject in
> the response (e= .g. id, threadId, blobId, etc.).
> 
>> o&nbs= p; *notCreated*: "String[SetError]" A map of creation id to a
<= div style=3D"font-family:Arial;">>> SetError object for each Email= that failed to be created.  The
>> possible errors are defined above.
> 
> This document needs a security considerations section at the = end.
> 
> Cheers,
> 
>= Neil.
> 
> Links:
> ------
&g= t; [1] https://tools.ietf.org/html/draft-ietf-jmap-mdn-00#section-2
<= /div>
> [2] https://tools.ietf.org/h= tml/rfc5322
> [3] https://= tools.ietf.org/html/rfc8098
&= gt; 
> ______________= _________________________________
> Jmap mailing list
&= gt; Jmap@ietf.org
> https:= //www.ietf.org/mailman/listinfo/jmap

____________________= ___________________________
J= map mailing list
Jmap@ietf.or= g
https://www.ietf.org/mailma= n/listinfo/jmap


--
&nbs= p; Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--faf538988bc044e9bfe9d9bb7d7964fa-- From nobody Tue Feb 12 01:08:08 2019 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 9286C124408 for ; Tue, 12 Feb 2019 01:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smtpcorp.com header.b=hzam6g1G; dkim=pass (2048-bit key) header.d=linagora.com header.b=Q2GXqhCs 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 kNCnuJEI5jqR for ; Tue, 12 Feb 2019 01:08:03 -0800 (PST) Received: from e2i64.smtp2go.com (e2i64.smtp2go.com [103.2.140.64]) (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 64FFF12894E for ; Tue, 12 Feb 2019 01:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a1-4; h=Feedback-ID:X-Smtpcorp-Track:Message-ID:Subject:To: From:Date:Reply-To:Sender:List-Unsubscribe; bh=nOoI1oI3T9zmlJb2dCMHMR2Ic0GIS2ReSXgN1AxzRh4=; b=hzam6g1GtRXwcIIi29DXp3jAZ6 HBC4SbWnr/7EXx3xLYWHNnL5sfHBIqZGs3F1xb0lErzwm7Opz8C9+uCWN27PVc9l1ltndP7WNsIRP tKdEzVwxAB0RkwW1B7deYo7ZbGtHIcexTfRHLnX9M7ZczG49zImQ+GdrpGyyy5IzBBNNxfMH7J0Wc NYclmlpdeqlLeQUoO6kGpjm37fdbayXBfq1M3gkO2WC54+Z9yHWrZ6ZqW9RXmFoW6QG5fRo3TAUUk N25gxsjjYzy7i1HOMS11RG9l7DiEmiCWVY6gP7ipyERzUn6kFUU8fAcDx+p7Eqrv/W74dtW4qJUHo uzmXPt4Q==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linagora.com; i=@linagora.com; q=dns/txt; s=s266739; t=1549962483; h=from : subject : to : message-id : date; bh=nOoI1oI3T9zmlJb2dCMHMR2Ic0GIS2ReSXgN1AxzRh4=; b=Q2GXqhCsDVc/SanuZvuelpSaPpbxc+aM4WJ45S8ZdMB7XbwonKLlX1PKXmxi8QbaKBVSIK dZEYyJDttoGW9lfWBT0C2NCyeSe+45B00evdiqQsya1RIbmXVl9eeGHCQcMCccS1HU+u2z8w JKhyVAMriF07uLPsfiJijmFugn6TUUrlFS6JTMoKq3fV1UW2FS4PWLn2za75z8EcomzvKgmh YD+Z08z4MG+63OcaI0HZXN2oC6/HYSNP6DH4Lbs8RqSDyAG6mtVnkhHo/v0Avg0Z94lR/23V JSs4kDU0U26U4heOqFS1AJWU1zZ36GlkVyqCzyBd22OGQfkIl68cySIw== Received: from [10.66.228.43] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1gtU2l-cp4WXe-3W; Tue, 12 Feb 2019 09:07:55 +0000 Received: from [10.54.36.8] (helo=smtp.linagora.com) by smtpcorp.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.91) (envelope-from ) id 1gtU2k-wSERvJ-0F; Tue, 12 Feb 2019 09:07:54 +0000 Received: from extranet.linagora.com (obm3-ui.linagora.dc2 [172.24.128.227]) by smtp.linagora.com (Postfix) with ESMTP id D4EA13F1A4; Tue, 12 Feb 2019 10:07:51 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 12 Feb 2019 10:07:51 +0100 X-LINAGORA-Copy-Delivery-Done: 1 From: Raphael OUAZANA To: Bron Gondwana Cc: jmap@ietf.org In-Reply-To: References: <153270520782.32707.4419621555491459322@ietfa.amsl.com> <2cf743f3-1c18-4062-848e-f85ca505fa55@sloti7d1t02> Message-ID: <37240c9d0200928267cc8f97029d29ad@linagora.com> X-Sender: raphael.ouazana@linagora.com User-Agent: Roundcube Webmail/1.1.4 X-Smtpcorp-Track: 1gtl2kwSERvJ0F.YMzoebJno Feedback-ID: 266739m:266739aja3LFS:266739sqomqQgQ91 X-Report-Abuse: Please forward a copy of this message, including all headers, to Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mdn-00.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: Tue, 12 Feb 2019 09:08:07 -0000 Hi Bron, Yes, I'll take the time to update it soon. Regards, Raphaël. Le 2019-02-11 15:25, Bron Gondwana a écrit : > Hi Raphaël, > > This document recently expired. Do you have the time to prepare an > updated draft before Prague? > > Thanks, > > Bron. > > On Sat, Dec 22, 2018, at 04:05, Raphael OUAZANA wrote: > >> Hi Neil, >> >> Thank you very much for your feedback. Not enough time to handle it >> for >> >> the moment, but it will be in my next year resolutions. >> >> Regards, >> >> Raphaël. >> >> Le 2018-12-05 01:46, Neil Jenkins a écrit : >> >>> Finally sending my feedback on this draft, as promised in Bangkok. >> >>> Sorry for the delay! Generally this looks good, just some comments >> to >> >>> bring it up to date with the current JMAP conventions and a >> confusion >> >>> over how you're actually meant to send the MDN! >> >>> >> >>>> 2 [1]. Email/createMDN >> >>>> >> >>>> The Email/createMDN method create a [RFC5322 [2]] message from >> >>>> MDN >> >>>> properties. >> >>> >> >>> Where are these Email objects being created? It's not clear to me >> >>> whether these are intended to be saved to the account's mail store >> or >> >>> not. If they _are_ being saved to the mail store, we need to give >> >>> mailboxIds and keywords arguments. If they are not being saved, >> but >> >>> just being sent immediately, that needs to be made clear and the >> >>> method probably renamed to _sendMDN_. >> >>> >> >>>> It takes the following arguments: >> >>>> >> >>>> o *accountId*: "String|null" The id of the account to use for >> >>>> this >> >>>> call. If "null", defaults to the "urn:ietf:params:jmap:mail" >> >>>> primary account. >> >>> >> >>> This should be non-optional now to match the same change in the >> other >> >>> JMAP specs. >> >>> >> >>>> o *mdns*: "String[MDN]" A map of creation id (client specified) >> >>>> to >> >>>> MDN objects >> >>>> >> >>>> An *MDN* object has the following properties: >> >>>> >> >>>> o *referencedMessageId*: "String" Message Id of the received >> >>>> message >> >>>> the user wants to create an MDN for. >> >>> >> >>> Again, to match current JMAP convention this should be >> >>> referencedEmailId, or maybe just forEmailId? >> >>> >> >>>> o *subject*: "String" Subject that will be used as "Subject" >> >>>> header >> >>>> for this MDN. >> >>>> >> >>>> o *textBody*: "String" Human readable part of the MDN, as plain >> >>>> text. >> >>>> >> >>>> o *reportingUA*: "String" Name of the MUA creating this MDN. It >> >>>> is >> >>>> used to build the MDN Report part of the MDN. >> >>>> >> >>>> o *disposition*: "Disposition" Object containing the diverse MDN >> >>>> disposition options. >> >>>> >> >>>> A *Disposition* object has the following properties: >> >>>> >> >>>> o *actionMode*: "String" This MUST be one of the following >> >>>> strings: >> >>>> "manual-action" / "automatic-action" >> >>>> >> >>>> o *sendingMode*: "String" This MUST be one of the following >> >>>> strings: >> >>>> "MDN-sent-manually" / "MDN-sent-automatically" >> >>>> >> >>>> o *type*: "String" This MUST be one of the following strings: >> >>>> "deleted" / "dispatched" / "displayed" / "processed" >> >>>> >> >>>> See [RFC8098 [3]] for the exact meaning of these different >> >>>> fields. >> >>> >> >>> This all looks fine. >> >>> >> >>>> If the _referencedMessageId_, _subject_, _textBody_, >> >>>> _reportingUA_, >> >>>> _disposition_ properties are invalid (e.g. missing, wrong type, >> >>>> id >> >>>> not found), the server MUST reject the import with an >> >>>> "invalidProperties" SetError. >> >>>> >> >>>> If the email cannot be created because it would take the account >> >>>> over >> >>>> quota, the creation should be rejected with a "maxQuotaReached" >> >>>> SetError. >> >>> >> >>> import -> create (I presume this is a copy-paste error) and the >> >>> maxQuotaReached error is now just called overQuota. But rather >> than >> >>> specify the last two paragraphs, probably better just to say it >> may >> >>> return any standard SetError that is defined for a _create_ in the >> >>> core spec. >> >>> >> >>>> The response has the following arguments: >> >>>> >> >>>> o *accountId*: "String" The id of the account used for this >> >>>> call. >> >>>> >> >>>> o *created*: "String[Email]" A map of the creation id to an >> >>>> object >> >>>> build from the referenced properties. The _blobId_ field of >> >>>> the >> >>>> Email objects can then be used to effectively send the MDN. >> >>> >> >>> Again, I'm unclear how you are supposed to use the blobId to send >> this >> >>> MDN. The EmailSubmission object uses an emailId reference rather >> than >> >>> a blobId. If it's creating an email object, it also needs to be >> clear >> >>> about which properties the servers should return for each object >> in >> >>> the response (e.g. id, threadId, blobId, etc.). >> >>> >> >>>> o *notCreated*: "String[SetError]" A map of creation id to a >> >>>> SetError object for each Email that failed to be created. The >> >>>> possible errors are defined above. >> >>> >> >>> This document needs a security considerations section at the end. >> >>> >> >>> Cheers, >> >>> >> >>> Neil. >> >>> >> >>> Links: >> >>> ------ >> >>> [1] https://tools.ietf.org/html/draft-ietf-jmap-mdn-00#section-2 >> >>> [2] https://tools.ietf.org/html/rfc5322 >> >>> [3] https://tools.ietf.org/html/rfc8098 >> >>> >> >>> _______________________________________________ >> >>> Jmap mailing list >> >>> Jmap@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/jmap >> >> _______________________________________________ >> >> Jmap mailing list >> >> Jmap@ietf.org >> >> https://www.ietf.org/mailman/listinfo/jmap > > -- > > Bron Gondwana, CEO, FastMail Pty Ltd > > brong@fastmailteam.com From nobody Tue Feb 12 01:14:56 2019 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 277AF128CE4 for ; Tue, 12 Feb 2019 01:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=W6fZof4R; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=usQku/Ft 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 YiXd6mIVJSJb for ; Tue, 12 Feb 2019 01:14:51 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7268612894E for ; Tue, 12 Feb 2019 01:14:51 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A8123221C6 for ; Tue, 12 Feb 2019 04:14:50 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 12 Feb 2019 04:14:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=xeNV7Chd2R+tZJUlxA/HECyID+gc WNhs1JixsK4nCAE=; b=W6fZof4RfILLW9cMp4aLh60V13dcAUUqMVa3OXsYNRL1 0zHLFMHhJqdH0LKFqARIfFjbgAOE/qIHs9HqheOByB9gbldZPWcoEWVstfwX5Sn8 l8iv8wzbHdkfTsvBN85mnSuaoIB1IdUzc+mp+/S3dFzwWyhN1Sz5fYnQKlq8mL0+ MC4q5XrTG8N+3d6DOvcUlKpZHvE5ATEE7IafmIEDrHq94iVWO3UEeetx2CQ+m3St RrEmJNEwaM8gfw9PWDzDelZPbquJ52OogdFLIcyHz9s4JuMp6aMRB1Quza+WCp3b NOrhQlCWsQ7XO56DAQJcB+qrvAS9yByTdE/T+rLh7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=xeNV7Chd2R+tZJUlx A/HECyID+gcWNhs1JixsK4nCAE=; b=usQku/FtF95tX4mb0q9TEDOquaFBaDu0t icFQP4o45FRPN/70huptCumzJipHkehWqaXyGgt2zXcDhXpltcatkMDeWXsHm0Qz G1J6Nztyump1tzYNJcr4oQOJaya7fPFe4xRUsbFCvphLHqNK1AiOSDkULDZ6SGEc PLhzhN6m+X3GPvnJqT/3KLbHwkHpBoafZkG0adC7V2UR0hz2Eqm+vbHiCiJk7dQ9 ujJ+hAAxXfAJY8msfULqI1WdDQYLAUhg3g76TMk2zQbAuIho6DjVfOfWquB192+N q1inGTZR0/wQYxX7X0fYISrvvm4PtYIPtjFVxQc3S49wQ0pf/3/EA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtuddgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpe dfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghm rdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfh hrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghr ufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0AE4A2023C; Tue, 12 Feb 2019 04:14:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 56629417 Message-Id: <6f38e91e-3bac-4873-912b-c44b7fee42ff@www.fastmail.com> In-Reply-To: <37240c9d0200928267cc8f97029d29ad@linagora.com> References: <153270520782.32707.4419621555491459322@ietfa.amsl.com> <2cf743f3-1c18-4062-848e-f85ca505fa55@sloti7d1t02> <37240c9d0200928267cc8f97029d29ad@linagora.com> Date: Tue, 12 Feb 2019 04:14:49 -0500 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=28318ff3bb7d46d487ca814a9ff20387 Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mdn-00.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: Tue, 12 Feb 2019 09:14:54 -0000 --28318ff3bb7d46d487ca814a9ff20387 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Awesome, thanks for that. Cheers, Bron. On Tue, Feb 12, 2019, at 20:08, Raphael OUAZANA wrote: > Hi Bron, >=20 > Yes, I'll take the time to update it soon. >=20 > Regards, > Rapha=C3=ABl. >=20 > Le 2019-02-11 15:25, Bron Gondwana a =C3=A9crit : > > Hi Rapha=C3=ABl, > >=20 > > This document recently expired. Do you have the time to prepare an > > updated draft before Prague? > >=20 > > Thanks, > >=20 > > Bron. > >=20 > > On Sat, Dec 22, 2018, at 04:05, Raphael OUAZANA wrote: > >=20 > >> Hi Neil, > >>=20 > >> Thank you very much for your feedback. Not enough time to handle it= > >> for > >>=20 > >> the moment, but it will be in my next year resolutions. > >>=20 > >> Regards, > >>=20 > >> Rapha=C3=ABl. > >>=20 > >> Le 2018-12-05 01:46, Neil Jenkins a =C3=A9crit : > >>=20 > >>> Finally sending my feedback on this draft, as promised in Bangkok.= > >>=20 > >>> Sorry for the delay! Generally this looks good, just some comments= > >> to > >>=20 > >>> bring it up to date with the current JMAP conventions and a > >> confusion > >>=20 > >>> over how you're actually meant to send the MDN! > >>=20 > >>>=20 > >>=20 > >>>> 2 [1]. Email/createMDN > >>=20 > >>>>=20 > >>=20 > >>>> The Email/createMDN method create a [RFC5322 [2]] message from > >>=20 > >>>> MDN > >>=20 > >>>> properties. > >>=20 > >>>=20 > >>=20 > >>> Where are these Email objects being created? It's not clear to me > >>=20 > >>> whether these are intended to be saved to the account's mail store= > >> or > >>=20 > >>> not. If they _are_ being saved to the mail store, we need to give > >>=20 > >>> mailboxIds and keywords arguments. If they are not being saved, > >> but > >>=20 > >>> just being sent immediately, that needs to be made clear and the > >>=20 > >>> method probably renamed to _sendMDN_. > >>=20 > >>>=20 > >>=20 > >>>> It takes the following arguments: > >>=20 > >>>>=20 > >>=20 > >>>> o *accountId*: "String|null" The id of the account to use for > >>=20 > >>>> this > >>=20 > >>>> call. If "null", defaults to the "urn:ietf:params:jmap:mail" > >>=20 > >>>> primary account. > >>=20 > >>>=20 > >>=20 > >>> This should be non-optional now to match the same change in the > >> other > >>=20 > >>> JMAP specs. > >>=20 > >>>=20 > >>=20 > >>>> o *mdns*: "String[MDN]" A map of creation id (client specified) > >>=20 > >>>> to > >>=20 > >>>> MDN objects > >>=20 > >>>>=20 > >>=20 > >>>> An *MDN* object has the following properties: > >>=20 > >>>>=20 > >>=20 > >>>> o *referencedMessageId*: "String" Message Id of the received > >>=20 > >>>> message > >>=20 > >>>> the user wants to create an MDN for. > >>=20 > >>>=20 > >>=20 > >>> Again, to match current JMAP convention this should be > >>=20 > >>> referencedEmailId, or maybe just forEmailId? > >>=20 > >>>=20 > >>=20 > >>>> o *subject*: "String" Subject that will be used as "Subject" > >>=20 > >>>> header > >>=20 > >>>> for this MDN. > >>=20 > >>>>=20 > >>=20 > >>>> o *textBody*: "String" Human readable part of the MDN, as plain > >>=20 > >>>> text. > >>=20 > >>>>=20 > >>=20 > >>>> o *reportingUA*: "String" Name of the MUA creating this MDN. It > >>=20 > >>>> is > >>=20 > >>>> used to build the MDN Report part of the MDN. > >>=20 > >>>>=20 > >>=20 > >>>> o *disposition*: "Disposition" Object containing the diverse MDN > >>=20 > >>>> disposition options. > >>=20 > >>>>=20 > >>=20 > >>>> A *Disposition* object has the following properties: > >>=20 > >>>>=20 > >>=20 > >>>> o *actionMode*: "String" This MUST be one of the following > >>=20 > >>>> strings: > >>=20 > >>>> "manual-action" / "automatic-action" > >>=20 > >>>>=20 > >>=20 > >>>> o *sendingMode*: "String" This MUST be one of the following > >>=20 > >>>> strings: > >>=20 > >>>> "MDN-sent-manually" / "MDN-sent-automatically" > >>=20 > >>>>=20 > >>=20 > >>>> o *type*: "String" This MUST be one of the following strings: > >>=20 > >>>> "deleted" / "dispatched" / "displayed" / "processed" > >>=20 > >>>>=20 > >>=20 > >>>> See [RFC8098 [3]] for the exact meaning of these different > >>=20 > >>>> fields. > >>=20 > >>>=20 > >>=20 > >>> This all looks fine. > >>=20 > >>>=20 > >>=20 > >>>> If the _referencedMessageId_, _subject_, _textBody_, > >>=20 > >>>> _reportingUA_, > >>=20 > >>>> _disposition_ properties are invalid (e.g. missing, wrong type, > >>=20 > >>>> id > >>=20 > >>>> not found), the server MUST reject the import with an > >>=20 > >>>> "invalidProperties" SetError. > >>=20 > >>>>=20 > >>=20 > >>>> If the email cannot be created because it would take the account > >>=20 > >>>> over > >>=20 > >>>> quota, the creation should be rejected with a "maxQuotaReached" > >>=20 > >>>> SetError. > >>=20 > >>>=20 > >>=20 > >>> import -> create (I presume this is a copy-paste error) and the > >>=20 > >>> maxQuotaReached error is now just called overQuota. But rather > >> than > >>=20 > >>> specify the last two paragraphs, probably better just to say it > >> may > >>=20 > >>> return any standard SetError that is defined for a _create_ in the= > >>=20 > >>> core spec. > >>=20 > >>>=20 > >>=20 > >>>> The response has the following arguments: > >>=20 > >>>>=20 > >>=20 > >>>> o *accountId*: "String" The id of the account used for this > >>=20 > >>>> call. > >>=20 > >>>>=20 > >>=20 > >>>> o *created*: "String[Email]" A map of the creation id to an > >>=20 > >>>> object > >>=20 > >>>> build from the referenced properties. The _blobId_ field of > >>=20 > >>>> the > >>=20 > >>>> Email objects can then be used to effectively send the MDN. > >>=20 > >>>=20 > >>=20 > >>> Again, I'm unclear how you are supposed to use the blobId to send > >> this > >>=20 > >>> MDN. The EmailSubmission object uses an emailId reference rather > >> than > >>=20 > >>> a blobId. If it's creating an email object, it also needs to be > >> clear > >>=20 > >>> about which properties the servers should return for each object > >> in > >>=20 > >>> the response (e.g. id, threadId, blobId, etc.). > >>=20 > >>>=20 > >>=20 > >>>> o *notCreated*: "String[SetError]" A map of creation id to a > >>=20 > >>>> SetError object for each Email that failed to be created. The > >>=20 > >>>> possible errors are defined above. > >>=20 > >>>=20 > >>=20 > >>> This document needs a security considerations section at the end. > >>=20 > >>>=20 > >>=20 > >>> Cheers, > >>=20 > >>>=20 > >>=20 > >>> Neil. > >>=20 > >>>=20 > >>=20 > >>> Links: > >>=20 > >>> ------ > >>=20 > >>> [1] https://tools.ietf.org/html/draft-ietf-jmap-mdn-00#section-2 > >>=20 > >>> [2] https://tools.ietf.org/html/rfc5322 > >>=20 > >>> [3] https://tools.ietf.org/html/rfc8098 > >>=20 > >>>=20 > >>=20 > >>> _______________________________________________ > >>=20 > >>> Jmap mailing list > >>=20 > >>> Jmap@ietf.org > >>=20 > >>> https://www.ietf.org/mailman/listinfo/jmap > >>=20 > >> _______________________________________________ > >>=20 > >> Jmap mailing list > >>=20 > >> Jmap@ietf.org > >>=20 > >> https://www.ietf.org/mailman/listinfo/jmap > >=20 > > -- > >=20 > > Bron Gondwana, CEO, FastMail Pty Ltd > >=20 > > brong@fastmailteam.com >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --28318ff3bb7d46d487ca814a9ff20387 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Awesome, thanks for that.

Cheers,
=

Bron.

On Tue, Feb 1= 2, 2019, at 20:08, Raphael OUAZANA wrote:
Hi Bron,

Yes, I'll take the time to update it soon.

= Regards,
Rapha=C3=ABl.

Le 2019-02-11 15:25, Bron Gondwana a =C3=A9crit :
> Hi Rapha=C3=ABl,
> 
> This document recently expired.  Do you have the tim= e to prepare an
> updated = draft before Prague?
>&nbs= p;
> Thanks,
> 
> Bron.
>&n= bsp;
> On Sat, Dec 22, 201= 8, at 04:05, Raphael OUAZANA wrote:
> 
>> Hi= Neil,
>> 
>> Thank you very much for you= r feedback. Not enough time to handle it
>> for
>= > 
>> the momen= t, but it will be in my next year resolutions.
>> 
>> Regards,
>>= ; 
>> Rapha=C3=ABl= .
>> 
>> Le 2018-12-05 01:46, Neil Jenkin= s a =C3=A9crit :
>>&nbs= p;
>>> Finally sendi= ng my feedback on this draft, as promised in Bangkok.
>> 
>>> Sorry for the delay! Generally this looks good, = just some comments
>> t= o
>> 
>>> bring it up to date with the= current JMAP conventions and a
>> confusion
>>= ; 
>>> over how= you're actually meant to send the MDN!
>> 
>= ;>> 
>> = ;
>>>> 2 [1].&nbs= p; Email/createMDN
>>&n= bsp;
>>>> 
>> 
>>>> The Email/createMDN method = create a [RFC5322 [2]] message from
>> 
>>= ;>> MDN
>> <= br>
>>>> properties.<= br>
>> 
>>> 
>> 
>>> Where are these Email objects being created? It's not = clear to me
>> 
>>> whether these are = intended to be saved to the account's mail store
>> or
>> 
>>>= ; not. If they _are_ being saved to the mail store, we need to give
<= /div>
>> 
>>> mailboxIds and keywords arguments.= If they are not being saved,
>> but
>> <= br>
>>> just being sent = immediately, that needs to be made clear and the
>> 
>>> method probably renamed to _sendMDN_.
>> 
>>> 
>> 
>>&g= t;> It takes the following arguments:
>> 
&g= t;>>> 
>>=  
>>>> o&nbs= p; *accountId*: "String|null" The id of the account to use for
=
>> 
>>>> this
>> 
&= gt;>>> call.  If "null", defaults to the "urn:ietf:params:= jmap:mail"
>> 
=
>>>> primary account= .
>> 
>>> 
>> 
>>> This should be non-optional now to match the same ch= ange in the
>> other
>> 
>>> JMAP specs.
>> 
>>> 
>= ;> 
>>>> = o  *mdns*: "String[MDN]" A map of creation id (client specified)
>> 
>>>> to
>> 
>>>> MDN objects
>> 
>>&g= t;> 
>> 
>>>> An *MDN* obje= ct has the following properties:
>> 
>>&g= t;> 
>> 
>>>> o  *refe= rencedMessageId*: "String" Message Id of the received
>> 
>>>> message
>> 
>>= ;>> the user wants to create an MDN for.
>> 
>>> 
>&g= t; 
>>> Again, = to match current JMAP convention this should be
>> 
>>> referencedEmailId, or maybe just forEmailId?
=
>> 
>>> 
>> 
>= >>> o  *subject*: "String" Subject that will be used as "S= ubject"
>> 
>>>> header
>> 
>>>> for this MDN.
>> 
>>>> 
= >> 
>>>&g= t; o  *textBody*: "String" Human readable part of the MDN, as plain=
>> 
>>>> text.
>> 
>>>> 
>> 
>>&g= t;> o  *reportingUA*: "String" Name of the MUA creating this MDN= .  It
>> 
=
>>>> is
>> 
>>>> used to build the MDN Report part of t= he MDN.
>> 
>>>> 
>> 
>>>> o  *disposition*: "Disposition" O= bject containing the diverse MDN
>> 
>>&g= t;> disposition options.
&= gt;> 
>>>>= ; 
>> 
>>>> A *Disposition* ob= ject has the following properties:
>> 
>>= >> 
>> =
>>>> o  *ac= tionMode*: "String" This MUST be one of the following
>> 
>>>> strings:
>> 
>&g= t;>> "manual-action" / "automatic-action"
>> 
>>>> 
&= gt;> 
>>>>= ; o  *sendingMode*: "String" This MUST be one of the following
<= /div>
>> 
>>>> strings:
>> 
>>>> "MDN-sent-manually" / "MDN-sent-automatically"
>> 
>>>> 
>> 
>>>> o  *type*: "String" This MUST be one of the= following strings:
>>&= nbsp;
>>>> "delet= ed" / "dispatched" / "displayed" / "processed"
>> 
>>>> 
&g= t;> 
>>>>= See [RFC8098 [3]] for the exact meaning of these different
>> 
>>>> fields.
>> 
&= gt;>> 
>>&nb= sp;
>>> This all loo= ks fine.
>> 
>>> 
>> 
>>>> If the _referencedMessageId_, _subject_, = _textBody_,
>> 
>>>> _reportingUA_,=
>> 
>>>> _disposition_ properties = are invalid (e.g. missing, wrong type,
>> 
>= >>> id
>> = ;
>>>> not found)= , the server MUST reject the import with an
>> 
>>>> "invalidProperties" SetError.
>> 
>>>> 
&= gt;> 
>>>>= ; If the email cannot be created because it would take the account
>> 
>>>> over
>> 
>>>> quota, the creation should be rejected with a "maxQu= otaReached"
>> 
>>>> SetError.
<= /div>
>> 
>>> 
>> 
>>> import -> create (I presume this is a copy-paste error)= and the
>> 
>>> maxQuotaReached error= is now just called overQuota. But rather
>> than
&g= t;> 
>>> spe= cify the last two paragraphs, probably better just to say it
>> may
>> 
>>> return any standard SetError that is defined for a _creat= e_ in the
>> 
<= /div>
>>> core spec.
=
>> 
>>> 
>> 
>= >>> The response has the following arguments:
>> 
>>>> 
>> 
>>= >> o  *accountId*: "String" The id of the account used for th= is
>> 
>>>> call.
>> 
>>>> 
>> 
>>= >> o  *created*: "String[Email]" A map of the creation id to = an
>> 
>>>> object
>> 
>>>> build from the referenced properties. = ; The _blobId_ field of
>&= gt; 
>>>> th= e
>> 
>>>> Email objects can then b= e used to effectively send the MDN.
>> 
>>= ;> 
>> 
>>> Again, I'm unclear= how you are supposed to use the blobId to send
>> this
>> 
>>&g= t; MDN. The EmailSubmission object uses an emailId reference rather
<= /div>
>> than
>> 
>>> a blobId. If it's creating an email object, it al= so needs to be
>> clear=
>> 
>>> about which properties the se= rvers should return for each object
>> in
>>&n= bsp;
>>> the respons= e (e.g. id, threadId, blobId, etc.).
>> 
>&g= t;> 
>> 
>>>> o  *notC= reated*: "String[SetError]" A map of creation id to a
>> 
>>>> SetError object for each Email that failed t= o be created.  The
>&= gt; 
>>>> po= ssible errors are defined above.
>> 
>>&g= t; 
>> 
>>> This document needs a= security considerations section at the end.
>> 
>>> 
>>=  
>>> Cheers,
>> 
>>> 
>> 
>>> Neil.
>&g= t; 
>>> 
>> 
>>> Links:
>> 
>>> ------
>= > 
>>> [1] h= ttps://tools.ietf.org/html/draft-ietf-jmap-mdn-00#section-2
>> 
>>> [2] https://tools.ietf.org/html/rfc5322
>> 
>>> [3] https://tools.ietf.org/html/= rfc8098
>> 
>>> 
>> 
>>> ______________________________________________= _
>> 
>>> Jmap mailing list
<= div style=3D"font-family:Arial;">>> 
>>> Jmap@ietf.org
>> 
>>> https://www.ietf.org/mailman/listinfo/jmap
>> 
>> _______________________________________________=
>> 
>> Jmap mailing list
>> 
>> Jmap@ietf.org
>> 
>&g= t; https://www.ietf.org/mailman/listinfo/jmap
> 
&= gt; --
> 
>   Bron Gondwana, CEO, Fas= tMail Pty Ltd
> 
<= /div>
>   brong@fastmailte= am.com

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


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


--28318ff3bb7d46d487ca814a9ff20387-- From nobody Tue Feb 12 04:53:56 2019 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 600D6130E74; Tue, 12 Feb 2019 04:53:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Cc: jmap@ietf.org, draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154997601829.8330.1953392138178618640@ietfa.amsl.com> Date: Tue, 12 Feb 2019 04:53:38 -0800 Archived-At: Subject: [Jmap] Secdir telechat review of draft-ietf-jmap-core-14 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, 12 Feb 2019 12:53:47 -0000 Reviewer: Tero Kivinen Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is rereview of this document, and all my previous issues have been solved, so I think this document is ready. From nobody Tue Feb 12 11:37:43 2019 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 E6862130DE3 for ; Tue, 12 Feb 2019 11:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gultsch-de.20150623.gappssmtp.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 JVUM67iOdZq2 for ; Tue, 12 Feb 2019 11:37:38 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 8A8F3130DC8 for ; Tue, 12 Feb 2019 11:37:38 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id v28so1706459pgk.10 for ; Tue, 12 Feb 2019 11:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gultsch-de.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=AQoCj8wAHlYv3JkZuklDQITE+JyLDc+DLywkX+/86T4=; b=hnB69xhqU0CP+caVY+Imfyl8HMjVKiO5x0dSMV6+Y8cs3D2eMNp9PvxQXUGsczOXbK Qf06uuveGWZvV0Gy/sw6PRVa+MSn8sWSUMrG1UnnATNChUoVkzamR0tx8Bu7VLyPLK8+ 92G77CSz14uHbwXdgLQIrNzD93Nmj538+SwAzGOhyhfQYU3EflMZHeRuAHn1KyFCJ3rD ahVVjzE2zuEwIL7PumcWQvLBAmy2Cq0eu8lTHgI9fhMg7C1py1iDrsmGcPchj+MMdcE0 juzk26Lamx0JcldccG+jywJSd8UAnSGOajFstmE0aqoO5GmAUtM4WM7HNIpmUPOkCCOo 5fUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=AQoCj8wAHlYv3JkZuklDQITE+JyLDc+DLywkX+/86T4=; b=NCWb7wQIbbTOa7tUARgjGhQWaNBsJNkn8GsEgL285Q9St3w+75VguQLWJu++vDMzC0 pwk5hQ8vPsWGvpHhYm6Yj6XPchiQgv1qcYVRDNeIF8COYwRWV3LOPSWG/yeCGuIvQv+F XesYr1OBWXv+n7j46PhokLO8zoz+0k1hCHvFaN7p9BZ6HlpaWQkUtJpzvrSXvWqc00B9 IJgTkPn1nUOli0k8HcsN29qEIMol8Li2qy1DTSphYlLLjP/aqBcnUnOiGr74a+dRbS6X sopUO1R0hmujRn83EyID3A22l1Fe5kgBoIGc7unoD27tjT2uC6RAAKNyQU14IOEq69QV yrlQ== X-Gm-Message-State: AHQUAuYtAYePKVs0Ha+bViiMLnDArD4Dv2ZpQ2pnd4z+sPHKimOrgwaF Xnef5jAUv+hCJGNuZXDRW4h15NNZ/HJyoa8oLPraSv6c58hWOA== X-Google-Smtp-Source: AHgI3Ib/RPLP9+O/5Mbp27eTrkj25eHDpfMMkxtKhYH46oYQofqBqENC1I26eS/4pc3HlBmboecpZOQDY0vhLwP7O6A= X-Received: by 2002:a62:6702:: with SMTP id b2mr5436956pfc.244.1550000257106; Tue, 12 Feb 2019 11:37:37 -0800 (PST) MIME-Version: 1.0 From: Daniel Gultsch Date: Tue, 12 Feb 2019 19:37:26 +0000 Message-ID: To: jmap@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Jmap] Multiple responses for method? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 19:37:41 -0000 Hi, are multiple responses for the same method call still a thing in JMAP? I remember them being used to trigger subsequent calls (get after changes) before back references were introduced. Now they seem obsolete (at least I can=E2=80=99t find an actual use case) however Example 3.3.1 (https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-14#sectio= n-3.3.1) still has them and the text above that example neither specifically allows nor forbids them. Is there a 1:1 relationship between request and response or a 1:n? And should this be explicitly specified? cheers Daniel From nobody Tue Feb 12 20:24:03 2019 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 35920130F9C for ; Tue, 12 Feb 2019 20:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=I20I6vVS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nwGXfUlV 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 NyNDCeEE-b60 for ; Tue, 12 Feb 2019 20:23:59 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65AB12D4F3 for ; Tue, 12 Feb 2019 20:23:59 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D4D32222F9 for ; Tue, 12 Feb 2019 23:23:58 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 12 Feb 2019 23:23:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=458KNJMv+x4K0s6L/YGVqZs+WSNs B5x1JwFZZseFY0U=; b=I20I6vVSwIt/vT2DOYn/JxIOFrLFLx+aRm4pLfCTUAvI eP2nHUrO5JBIxwB3rN5CKk2Ohnbm8pqnZKX4DPFDR2SD23Ia1OBJDNKpAuyglrl2 BpEzPjNlHMsQAABjkCyhOKgPRNdVX0bP+fREBF9ZU59ZH0ceEvBXbgEz0tzIy3OB GdW+k3zRvhrYuGQ2lM1Zzf43bNnDumdOiI0LxfjcRKawmRIQGumGUTjVoV+l9T2n S05XfAD9UHE9HsCqLmXLYXCqbZGaPIEi3unm9JAm+KD3I9JQa4vZQCfVid9Pcoid HjiZ8aPceetkqG/GEfKn4N9IyjEtQf/I1xQliZW0tg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=458KNJMv+x4K0s6L/ YGVqZs+WSNsB5x1JwFZZseFY0U=; b=nwGXfUlV7HB54l5y719YT2NeuiGmq0jUr q4AEXziJ5gmS2V0NUUwutB1It/S52WsSv0v7WnTT+YR+A1IEZjQXS76Nlqr7Y4Ln p0GPgMMTy52pcvZbTGRYquEBNdU5kce2hVW8mVLIK8SKZ2FQt6PmdPTgAFugEe6u gpl4Wtp0jPaZbFqnjuG9Pf3KWxBuIZ4XArU9sY9nLsd/8Q4lWAA1otV0ANKYGoaA l8qZpst/M9u9KcvByCqokfNOzCxGLI/kC2I86lfGHApMVBmq/adHE8dxCBFlw53h k3p80ybJliFUt451ooTnN7NeFDWvn3LPYp97B+v5Gh5mnbWHQVQbQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtvddgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefofgfkjghfff fhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceo nhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghi lhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6025B20250; Tue, 12 Feb 2019 23:23:58 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 64588216 Message-Id: <760238df-9a97-40a3-b607-20295569aa6b@beta.fastmail.com> In-Reply-To: References: Date: Tue, 12 Feb 2019 23:23:58 -0500 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=1e3fe0a5badd486c92f0d15994e65ce6 Archived-At: Subject: Re: [Jmap] Multiple responses for method? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 04:24:01 -0000 --1e3fe0a5badd486c92f0d15994e65ce6 Content-Type: text/plain https://tools.ietf.org/html/draft-ietf-jmap-core-14#section-3.2 (a method may return 1 or more responses, as it may make implicit calls to other methods; all responses initiated by this method call get the same client id in the response). See the real-world example in Section 7.5.1 of the mail spec , where the EmailSubmission call makes an implicit Email/set call to move the message from "drafts" to "sent" if it sends successfully. Cheers, Neil. --1e3fe0a5badd486c92f0d15994e65ce6 Content-Type: text/html 

 (a method may return 1 or more responses, as it may make
 implicit calls to other methods; all responses initiated by
 this method call get the same client id in the response).

See the real-world example in Section 7.5.1 of the mail spec, where the EmailSubmission call makes an implicit Email/set call to move the message from "drafts" to "sent" if it sends successfully.

Cheers,
Neil.
--1e3fe0a5badd486c92f0d15994e65ce6-- From nobody Sat Feb 16 16:17:42 2019 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 97B4B12785F; Sat, 16 Feb 2019 16:17:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: jmap@ietf.org, draft-ietf-jmap-core@ietf.org, Bron Gondwana , jmap-chairs@ietf.org, brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155036265361.28448.17454562785142380047.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2019 16:17:33 -0800 Archived-At: Subject: [Jmap] Eric Rescorla's Discuss on draft-ietf-jmap-core-14: (with DISCUSS and COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 00:17:34 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-jmap-core-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4155 I believe I have found a security issue, noted below. In addition, I have noted a potential interop issue. DETAIL S 2. > "urn:ietf:params:jmap:contacts", while the second account would > just have the last of these. Attempts to use the methods > defined in a specification with one of the accounts that does > not contain those data types are rejected with an > _accountNotSupportedByMethod_ error (see section 3.5.2: method- > level errors). What happens if this changes after the user has logged in. So, for instance, I log in and am told that account X has contacts, but later calendars get added. Do requests have to fail? S 7.2.2. > o *pushSubscriptionId*: "String" The id of the push subscription > that was created. > > o *verificationCode*: "String" The verification code to add to the > push subscription. This MUST contain sufficient entropy to avoid > the client being able to brute force guess the code. This doesn't actually guarantee permission. Consider the case where the client provides a push URL for some sort of open server upload endpoint. The client could then read the verification code off that endpoint and confirm the push subscription. Off the top of my head, requiring the push endpoint to respond in-band with a function of the code would be better. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 1.2. > the "URL and Filename safe" Base 64 Alphabet, as defined in section 5 > of [RFC4648]. This is the ASCII alphanumeric characters ("A-Za- > z0-9"), hyphen ("-"), and underscore ("_"). > > These characters are safe to use in almost any context (e.g., > filesystems, URIs, IMAP atoms). For maximum safety, servers should SHOULD? S 1.7. > > 1.7. The JMAP API model > > JMAP uses HTTP [RFC7230] to expose API, Push, Upload and Download > resources. Implementations MUST support HTTP/1.1, and MAY support > later versions. All HTTP requests MUST use [RFC8446] TLS (HTTPS) You need to cite 2818 here too. S 1.7. > > 1.7. The JMAP API model > > JMAP uses HTTP [RFC7230] to expose API, Push, Upload and Download > resources. Implementations MUST support HTTP/1.1, and MAY support > later versions. All HTTP requests MUST use [RFC8446] TLS (HTTPS) At this point, do you think it should be SHOULD for H2 S 1.7. > and caching are assumed. > > All HTTP requests MUST be authenticated. Servers MUST conform with > the [RFC7235] HTTP Authentication framework to reject requests that > fail authentication and inform the client of available authentication > schemes. This seems pretty restrictive. I read it as forbidding TLS client auth and/or PAKEs. S 2. > something like "urn:ietf:params:jmap:mail", > "urn:ietf:params:jmap:calendars", > "urn:ietf:params:jmap:contacts", while the second account would > just have the last of these. Attempts to use the methods > defined in a specification with one of the accounts that does > not contain those data types are rejected with an Is this a MUST-level statement or something else? S 2. > o *downloadUrl*: "String" The URL endpoint to use when downloading > files, in [RFC6570] URI Template (level 1) format. The URL MUST > contain variables called "accountId", "blobId", "type" and "name". > The use of these variables is described in section 6.2. Due to > potential encoding issues with slashes in content types, it is > recommended to put the "type" variable in the query section of the Should this be RECOMMENDED? S 3.2. > > 3. A "String" *client id*: an arbitrary string from the client to > be echoed back with the responses emitted by that method call > (a method may return 1 or more responses, as it may make > implicit calls to other methods; all responses initiated by > this method call get the same client id in the response). Do all the responses have to come back in the same package, so that I know when I have received the last one? S 3.2. > different servers. For example it could send the first two method > calls to server A, then the third to server B, before sending the > fourth to server A again. By passing the createdIds of the > previous response to the next request, it can ensure all of these > still resolve. See section 5.8 for further discussion of proxy > considerations. This is a bit hard to parse and would be improved by an example. S 3.5.2. > and, unless otherwise specified, further processing MUST NOT happen > within that method call. > > Any further method calls in the request MUST then be processed as > normal. Errors at the method level MUST NOT generate an HTTP-level > error. So, what do I do if I want to have method 1 execute and then method 2 execute only if method 1 succeeded. E.g., copy an object and then delete the original? Do two requests? it looks like maybe I can use back-references for this, but will that always work? S 5.4. > to copy them using the _Foo/copy_ method, then once the copy has > succeeded, delete the original. The _onSuccessDestroyOriginal_ > argument allows you to try to do this in one method call, however > note that the two different actions are not atomic, and so it is > possible for the copy to succeed but the original not to be destroyed > for some reason. Can the other direction happen? S 8.1. > 8.1. Transport confidentiality > > All HTTP requests MUST use [RFC8446] TLS (https) transport to ensure > the confidentiality and integrity of data sent and received via JMAP. > Clients MUST validate TLS certificate chains to protect against man- > in-the-middle attacks. You should cite 7525. Also, you need to specify which versions are acceptbale. From nobody Sun Feb 17 09:56:20 2019 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 4911E130E5B; Sun, 17 Feb 2019 09:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31U0qmwE_Ipd; Sun, 17 Feb 2019 09:56:11 -0800 (PST) Received: from mail-it1-f172.google.com (mail-it1-f172.google.com [209.85.166.172]) (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 1A75F130E74; Sun, 17 Feb 2019 09:56:05 -0800 (PST) Received: by mail-it1-f172.google.com with SMTP id i2so35719338ite.5; Sun, 17 Feb 2019 09:56:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AoZ2wG9JqJU/ipLQa0wATdXmwyr6ky08icP48HSk+40=; b=l7Jd3ugYogpx+Y8SsGuI7A/L4qQvSM58TC+ReUXTv3qUJcGVktGL0c+MV33k463izt QC1Wcuo2VAMpeUfj+umcMa1tkLmnbJqEXpCdwe8onMAAI/+oE3J2JBHYBRDURJ7Advjn 3uShFjyEnUs9A/l6k7ZdGPItqI1X5OvtPKtUgLd1eJ6nJNI2yJ3goFUXmov9PDMhw6YH WD+UPqhWWV9IsReKdg9ziMYxqp1LZNCvY1SqPWov7YSX1vkFOImDLEFggVZUHvBi7Gab nlWdhdo9Ri5GvEEA2DfEtt0NXcx+bSZe0lcfRDiTNwTcGSJnpO9kKXMffm7mQeN7FGQt uXuQ== X-Gm-Message-State: AHQUAuYaG2BOIxBfshiEJs5l6b/aodHsiPABrbkjejSNZPat6Jhcz0su oVsdzAzyem4gm8Bj2eneqhGROZTO5HQ521tlZfYQ0w== X-Google-Smtp-Source: AHgI3IY8ndRaCP8YA4wOfbXZz6ezQ7g1BXzKZtSBA/yseebF5ZkI/LYsTubQ9PoQpDwAsaGnvLj53FWFmjHk9jcomok= X-Received: by 2002:a24:6fc4:: with SMTP id x187mr12028603itb.93.1550426163942; Sun, 17 Feb 2019 09:56:03 -0800 (PST) MIME-Version: 1.0 References: <155036265361.28448.17454562785142380047.idtracker@ietfa.amsl.com> In-Reply-To: <155036265361.28448.17454562785142380047.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Sun, 17 Feb 2019 12:55:52 -0500 Message-ID: To: Eric Rescorla Cc: The IESG , IETF JMAP Mailing List , draft-ietf-jmap-core@ietf.org, Bron Gondwana , jmap-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jmap] Eric Rescorla's Discuss on draft-ietf-jmap-core-14: (with DISCUSS and COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 17:56:18 -0000 Just on three of the comments: > S 1.2. > > the "URL and Filename safe" Base 64 Alphabet, as defined in section 5 > > of [RFC4648]. This is the ASCII alphanumeric characters ("A-Za- > > z0-9"), hyphen ("-"), and underscore ("_"). > > > > These characters are safe to use in almost any context (e.g., > > filesystems, URIs, IMAP atoms). For maximum safety, servers should > > SHOULD? I think so, as it speaks to a choice related to interoperability. > S 1.7. > > > > 1.7. The JMAP API model > > > > JMAP uses HTTP [RFC7230] to expose API, Push, Upload and Download > > resources. Implementations MUST support HTTP/1.1, and MAY support > > later versions. All HTTP requests MUST use [RFC8446] TLS (HTTPS) > > At this point, do you think it should be SHOULD for H2 Yes. "Implementations MUST support HTTP/1.1, SHOULD support HTTP/2, and MAY support later versions. And this will come up again when QUIC is ready. > S 2. > > something like "urn:ietf:params:jmap:mail", > > "urn:ietf:params:jmap:calendars", > > "urn:ietf:params:jmap:contacts", while the second account would > > just have the last of these. Attempts to use the methods > > defined in a specification with one of the accounts that does > > not contain those data types are rejected with an > > Is this a MUST-level statement or something else? It's a style choice in writing out a protocol. There are times, I think, when you want to use MUST to highlight that there are multiple ways one might handle something, and this is the one you have to use. Here, it's just saying, "This is how the protocol works." If you don't do this, it's not this protocol. I don't think it's necessary to use "MUST" here. That said, of course (1) it doesn't hurt to say MUST and (2) we're inconsistent, in general, with when we say, "this is what happens," and when, "this is what you MUST do." Barry From nobody Sun Feb 17 16:06:16 2019 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 58A151292F1; Sun, 17 Feb 2019 16:06:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: jmap@ietf.org, draft-ietf-jmap-mail@ietf.org, Bron Gondwana , jmap-chairs@ietf.org, brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155044837435.4109.3653101027278525875.idtracker@ietfa.amsl.com> Date: Sun, 17 Feb 2019 16:06:14 -0800 Archived-At: Subject: [Jmap] Eric Rescorla's Discuss on draft-ietf-jmap-mail-14: (with DISCUSS and COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 00:06:14 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-jmap-mail-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4198 IMPORTANT: It's a bit hard to tell what the server is required to do. Which of the many properties of emails (headers, the like) is the server required to provide? DETAIL S 2. > > * *mayReadItems*: "Boolean" If true, the user may use this > mailbox as part of a filter in a _Email/query_ call and the > mailbox may be included in the _mailboxIds_ set of _Email_ > objects. If a sub-mailbox is shared but not the parent > mailbox, this may be "false". Corresponds to IMAP ACLs "lr". This doesn't have any impact on Email/get? that seems odd. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- S 2. > A *Mailbox* object has the following properties: > > o *id*: "Id" (immutable; server-set) The id of the mailbox. > > o *name*: "String" User-visible name for the mailbox, e.g. "Inbox". > This may be any Net-Unicode string ([RFC5198]) of at least 1 MAY? S 2. > > o *role*: "String|null" (default: null) Identifies mailboxes that > have a particular common purpose (e.g. the "inbox"), regardless of > the _name_ (which may be localised). This value is shared with > IMAP (exposed in IMAP via the [RFC6154] SPECIAL-USE extension). > However, unlike in IMAP, a mailbox may only have a single role, MUST only S 2. > o *totalEmails*: "PositiveInt" (server-set) The number of emails in > this mailbox. > > o *unreadEmails*: "PositiveInt" (server-set) The number of emails in > this mailbox that have neither the "$seen" keyword nor the > "$draft" keyword. This is the first appearance of "keyword" in this document. Please provide some explanation of what that means before this. S 2. > o *totalThreads*: "PositiveInt" (server-set) The number of threads > where at least one email in the thread is in this mailbox. > > o *unreadThreads*: "PositiveInt" (server-set) An indication of the > number of "unread" threads in the mailbox. This may be presented > by the client as a badge or marker associated with the mailbox. I know we're in 8174-land, but it seems to me that this may is a bit confusing in any case. The client can do anything it wants with this at all, right? S 4.1. > list rather than a single part as messages may have headers and/or > footers appended/prepended as separate parts as they are > transmitted, and some clients send text and images intended to be > displayed inline in the body (or even videos and sound clips) as > multiple parts rather than a single HTML part with referenced > images. Does the server have to supply this? It seems like it's a bit of a pain if you don't otherwise have a bunch of MIME-parsing machiner. S 4.1.1. > properties is specified over the following three sub-sections. > > 4.1.1. Metadata > > These properties represent metadata about the [RFC5322] message, and > are not derived from parsing the message itself. As above, is the server required to supply all of these? S 4.1.2.3. > > o Resent-Cc > > o Resent-Bcc > > o Any header not defined in [RFC5322] or [RFC2369] Can this list be updated in the future? If so, how? S 9.2. > > Subtle differences in parsing of HTML can introduce security flaws: > to filter with 100% accuracy you need to use the same parser when > sanitizing that the HTML rendering engine will use. > > o Encapsulating the message in an "