From nobody Mon Jan 6 09:14:38 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3B12086C; Mon, 6 Jan 2020 09:14:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, fenton@bluepopcorn.net, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <157833087603.7991.7955347162905703406.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2020 09:14:36 -0800 Archived-At: Subject: [Jmap] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-jmap-websocket-04=3A_=28with_COMMENT=29?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 17:14:36 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-jmap-websocket-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/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-websocket/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The TSV-ART review (Thanks Bob!) flagged an issue about further discussing failure cases. Alexey indicated that the spec should add more text about this, however, no update has been posted since. I assume this will be addressed before publication, as Alexey is aware, so I'm balloting no objection. From nobody Mon Jan 6 10:41:05 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B235120077; Mon, 6 Jan 2020 10:41:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, fenton@bluepopcorn.net, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <157833606256.7987.10843100204677119647.idtracker@ietfa.amsl.com> Date: Mon, 06 Jan 2020 10:41:02 -0800 Archived-At: Subject: [Jmap] Alissa Cooper's Discuss on draft-ietf-jmap-websocket-04: (with DISCUSS) 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, 06 Jan 2020 18:41:03 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-jmap-websocket-04: 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-websocket/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- If I understand correctly, in JMAP transport confidentiality is required to use for requests and in WebSocket it is required to implement but not required to use. Which set of requirements applies to the binding specified in this document? From nobody Mon Jan 6 10:51:19 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC90120077; Mon, 6 Jan 2020 10:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=ciwZe8ee; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DdR41kRm 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 ox9CqWQY_WlC; Mon, 6 Jan 2020 10:51:10 -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 24FE9120105; Mon, 6 Jan 2020 10:51:09 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5623E217FC; Mon, 6 Jan 2020 13:51:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 06 Jan 2020 13:51:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=3 p3aln5HIcrX/YqACNAwdPyU79NHMggopxRKBsU6CbA=; b=ciwZe8ee/2OmGc8TX KjJkPECOLsxxR6inA6tfDhZQZoc4gPXOH1+DMTNGQsKLQCyPYBPBXIfXNoyjXCxD s9xEFR6yH1fCQFeDIIfI2XNQrKVB+xrcxu/4ytuklWv4R94ZiBZrcjseP3202FBB EDpS/bYFvV13k12UisUiT2VWh+ZEPeTTChznyY6TtVyMiUB5uz5K9GElVd3hGzse rUcRkauryFb0LLlMIPDBEVLHIjWHXPveo3QgFmoXuUOVhkUUDpmCSIcKYtazhskD Cb8k57dOZlBuP4TXnNsptUJjiDV24XKms4K7Qncf9wSuchKfDkHUyCRhQdZQq7xM /y3Uw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=3p3aln5HIcrX/YqACNAwdPyU79NHMggopxRKBsU6C bA=; b=DdR41kRmyJZPLgolIpQI6wEU9qWj6vlEJ+XFPFYix8sm7T7qMIY8ZPdQI g1f69U9QGhIv9o+N/tSuygxgtBjl8nN7B/gsU5KSWARZowboyX9nB4Smpazeb2rI nzLYezc6gRklUUe5yb1slQNjiNCfDE5GNxFki5S5fMuC9PkMJTRrRvB81VlHy+aM ArhSJTjDcMbzqfdT3u7GX4bO251P7HAvOWZA1cDnUGv0mcHOG+6nQzDAIBjZMSHu 26jRc7XZYC4AzYjRgjrgiGefqruD6qGy5lIDiOfHazpSFZv7dFkv1tPYOAPw0EWP StzgMRgz0jJnkEtpgc24i0AuHeZLQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehtddguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghdphhhtthhprhgvqhhuvghsthhshhgrshhvvghrhihlohif uggvphhlohihmhgvnhhtrdhishenucfkphepudejfedrfeekrdduudejrdekvdenucfrrg hrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id 99B8480068; Mon, 6 Jan 2020 13:51:07 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <157601705841.9885.14627802012368211966@ietfa.amsl.com> Date: Mon, 6 Jan 2020 13:51:06 -0500 Cc: gen-art@ietf.org, last-call@ietf.org, draft-ietf-jmap-websocket.all@ietf.org, jmap@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2AD30F37-FDCD-470F-9FA2-36A1788E4D67@cooperw.in> References: <157601705841.9885.14627802012368211966@ietfa.amsl.com> To: Linda Dunbar X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Jmap] [Gen-art] Genart last call review of draft-ietf-jmap-websocket-04 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, 06 Jan 2020 18:51:13 -0000 Linda, thanks for your review. I asked a question in my DISCUSS ballot = related to your question about MITM (regarding transport = confidentiality, not uses of JMAP beyond those specified for the = WebSocket binding, which I think is clear). Alissa > On Dec 10, 2019, at 5:30 PM, Linda Dunbar via Datatracker = wrote: >=20 > Reviewer: Linda Dunbar > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-jmap-websocket-04 > Reviewer: Linda Dunbar > Review Date: 2019-12-10 > IETF LC End Date: 2019-12-19 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: the document describes binding JSON Meta Application = Protocol (JMAP) > over a WebSocket Transport Layer (instead the current HTTP layer) >=20 > The document is written very clear. I think it is ready with a few = questions. >=20 > 1. The current practice of binding JMAP over HTTP requires = authentication for > every request, vs. over WebSocket Transport only requires = authentication at the > initial OPEN step. What if there is Man in the Middle attack after the = initial > OPEN? >=20 > 2. In the Introduction you stated that compression for HTTP requests = has very > low deployment. Is it because HTTP request only has very small packet = size, > therefore with very little benefit of compression? >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 > Best Regards, > Linda Dunbar >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue Jan 7 13:08:38 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D68120025; Tue, 7 Jan 2020 13:08:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, fenton@bluepopcorn.net, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <157843131129.21019.4453575321747210277.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2020 13:08:31 -0800 Archived-At: Subject: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-websocket-04: (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: Tue, 07 Jan 2020 21:08:32 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-jmap-websocket-04: 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-websocket/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Alissa's Discuss and suggest an approach of making a definitive statement about "wss://" usage, akin to RFC 8620's "All HTTP requests MUST use the 'https://' scheme". I don't understand how adding a "pushState" value to the StateChange object (Section 4.2.4.1) that reflects the state of "ALL of the data types in the account" can work, if the regular StateChange and notification flows are not tied to a specific account (and in fact the example in Section 7.1.1 of RFC 8620 includes state changes about multiple accounts in a single StateChange) but rather the authentication credentials. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The discussion of compression bears some closer scrutiny, as if we allow the entire websocket frame to be part of the compression state, then there may be more avenues for an attacker to inject content into the same compression state as data that we want to keep somewhat confidential. (This is not as bad as, say, the initial CRIME attack impact, as the authentication credentials are not being repeatedly sent, but the general principle of mixing attacker-controlled and confidential data into the same compression domain is the same.) We could say something in the security considerations about the potential consequences for a client that sends multiple requests in parallel without request IDs and gets back responses in a different order. (Or just require unique request IDs, I suppose.) Section 1 resources. In such circumstances, authenticating every JMAP API request may harm performance. I'd suggest phrasing this as "reauthenticating for every JMAP API request" -- we still want to have the API requests be authenticated, we're just batching them via a persistent connection. Section 4.1 The JMAP WebSocket client and JMAP WebSocket server negotiate the use of the WebSocket JMAP subprotocol during the WebSocket handshake, either via a HTTP/1.1 Upgrade request (see Section 1.3 of [RFC6455]) or a HTTP/2 Extended CONNECT request (see Section 5 of [RFC8441]). nit: "either" suggests that these are the only options, unnecessarily ruling out (e.g.) HTTP/3 websockets. header field. The reply from the server MUST also contain "jmap" in its corresponding "Sec-WebSocket-Protocol" header field in order for a JMAP subprotocol connection to be established. If a client receives a handshake response that does not include "jmap" in the "Sec-WebSocket-Protocol" header, then a JMAP subprotocol WebSocket connection was not established and the client MUST close the WebSocket connection. [just to note that what the TSV-art reviewer pointed out is valid -- core websockets requires exactly one value in the response] The credentials used for authenticating the HTTP request to initiate the handshake remain in effect for the duration of the WebSocket connection. I think we should say something about the server closing the websocket if the underlying credentials expire. Section 4.2 Data frame messages in the JMAP subprotocol MUST be of the text type and contain UTF-8 encoded data. The messages MUST be in the form of nit: RFC 6455 seems to refer to these as being "text frames" or frames with "text data type", but not "text type". Also, just to double-check: we're requiring a 1:1 mapping between JMAP message and websocket frame, with no fragmentation or anything like that allowed? Section 4.2.1 o id: "String" (optional) A client-specified identifier for the request. I see that RFC 8620 defines an "id" type that is more-specific than just "String", but also note that it claims to always be server-assigned and to correspond to "real resources" (in some sense of the term) as opposed to ephemeral requests, so I can understand if pulling in the additional guidance about formatting and length is not desired. Additionally, the "maxConcurrentRequests" field in the "capabilities" object (see Section 2 of [RFC8620]) limits the number of inflight requests over the WebSocket. nit(?): a strict reading of RFC 8620 would be that "maxConcurrent Requests" applies only to the (traditional) JMAP API endpoint, and the websocket endpoint is presumably a different end point, which would not be covered by that strict reading. So it might be worth phrasing this more definitively, a la "the 'maxConcurrentRequests' JMAP capability also applies to requests made on the websocket connection". (Presumably, also specifying whether the cap is per-endpoint or shared across traditional requests and websocket ones.) Section 4.2.4.2 Are we implicitly saying that the WebSocketPushEnable object, unlike the RFC 8620 PushSubscription object, does have an accountId property? This does not seem to be reflected in the examples. o pushState: "String" (optional) The last "pushState" token that the client received from the server. Upon receipt of a "pushState" token, the server SHOULD immediately send all changes since that state token. What does the server do if there is no provided pushState? Section 4.2.4.3 What is the granularity at which the WebSocketPushDisable applies? Per-authentication-credentials? Section 4.3 Do we want to say anything about having prior "pushState" of "aaa" in the WebSocketPushEnable message for the HTTP/1.1 example? I'd also suggest saying something about what triggers the state change for the push notification, as I don't see how the junk message ("The quick brown fox jumps over the lazy dog") would affect the Email state. From nobody Tue Jan 7 20:51:11 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6C9120025; Tue, 7 Jan 2020 20:51:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, fenton@bluepopcorn.net, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <157845906410.20960.13743309018111160231.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2020 20:51:04 -0800 Archived-At: Subject: [Jmap] Barry Leiba's No Objection on draft-ietf-jmap-websocket-04: (with COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 04:51:04 -0000 Barry Leiba has entered the following ballot position for draft-ietf-jmap-websocket-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/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-websocket/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the DISCUSS positions that suggest explicit text to require encryption. I think that RFC 7692 needs to be a normative reference. The IESG statement about references ( https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ ) says this: Note 1: Even references that are relevant only for optional features must be classified as normative if they meet the above conditions for normative references. From nobody Wed Jan 8 04:54:53 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B0A120026; Wed, 8 Jan 2020 04:54:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, fenton@bluepopcorn.net, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <157848809108.22615.18269038960236690776.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2020 04:54:51 -0800 Archived-At: Subject: [Jmap] Martin Vigoureux's No Objection on draft-ietf-jmap-websocket-04: (with COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 12:54:51 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-jmap-websocket-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/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-websocket/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hello, I only have one nit, as a comment: The references to Sections 3.2, 3.3, and 3.5.1 of RFC8620, in Section 4 of this document, seem wrong. I believe they should, be 3.3, 3.4, 3.6.1, respectively. From nobody Thu Jan 9 05:06:29 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 586E11200C1; Thu, 9 Jan 2020 05:06:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Leif Johansson via Datatracker To: Cc: last-call@ietf.org, draft-ietf-jmap-websocket.all@ietf.org, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.115.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Leif Johansson Message-ID: <157857518227.11730.7008293637130176864@ietfa.amsl.com> Date: Thu, 09 Jan 2020 05:06:22 -0800 Archived-At: Subject: [Jmap] Secdir last call review of draft-ietf-jmap-websocket-04 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, 09 Jan 2020 13:06:22 -0000 Reviewer: Leif Johansson Review result: Has Issues 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. I apologize for being very late with this review and since this is already in the IESG process it is clearly ok to completely ignore this review! In summary I think the security considerations sections have a few issues. In particular several of the identified security issues in section 10 of RFC 6455 place requirements on implementations and profiles but JMAP websocket makes no effort to expand on those requirements. For instance is the intention of jmap websocket to be built into non- browser clients so section 10.1 applies (or not)? What are the authentication requirements of jmap websocket (section 10.5) etc. I think the security considerations should make an attempt to cover this if at all possible. From nobody Thu Jan 9 05:07:12 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48A3120947; Thu, 9 Jan 2020 05:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=u8VrKn/f; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GRzK+BoU 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 HYrqI9c5E8Zn; Thu, 9 Jan 2020 05:07:01 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7FE9120933; Thu, 9 Jan 2020 05:07:01 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id E79FD75D; Thu, 9 Jan 2020 08:07:00 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Thu, 09 Jan 2020 08:07:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=S/hFZrPUGuatAre7CWSbkKXeBubqZbL OSFwPQhNmROU=; b=u8VrKn/fkW7m06DUbuHXnfbb2B0Mxfi0t6B3VQ2ZgBdGjiW 3xQultEID+dxLWWoGunht/5B4oIYDFD/4UOIJ9UwJLES/oBSAHni62IjYwMwPAzX aOw6kYfoNMx0CvvX+UiHeJCpE3TDbApHfuvz820jbwoWIekpAmJI2runtxnW1LS/ iF3CsEVNa2lYtk9xXCNg+xDEESPgXtLJLL/SHb+e+CvmjGF77tTgvvBwBX7nP0sj /dltxYLZTgODosh2g2vY58RdFfG0aez9bZ/1EUO+jrcRmsSweCkQrcsdGy5iWu5i SinGXwHEfZgo2HTEn7/uwQPpWAAyyhnlqpi029g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=S/hFZr PUGuatAre7CWSbkKXeBubqZbLOSFwPQhNmROU=; b=GRzK+BoUg/16KJjkXvZRuF OpXopkeIoeOwxaWM3Z4bc5FnS0QSsgjK+YB6zu9nNvKMeI+kdfozUuRulyR9nI9O BnRI8rMFCqK8tQ1bb45yAidEvh+VNe1rCPunwDbxgs6TcARQFiMM+WRP7LDYnfhW k3R4RWfRFxWSTN7u4DrdT7xwLsXMFmh12QlycSNZ1SqCABaiUJWAsDttImDum5Vl r8066r3T+V9/3WMUqCTJ0lJ0VvlL8CvEQ3vSG1xCIpD1yA/3+dwnWPdnQTZ8p6wJ eQLB0OiRqdwq3JbZruRy1EY6D9Qm088DlJE9Hvnw4gqAKZ4aPs/V8ZQfV6GbvLXA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeiuddgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedu X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 45E13C200A4; Thu, 9 Jan 2020 08:07:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-740-g7d9d84e-fmstable-20200109v1 Mime-Version: 1.0 Message-Id: <3f8d2180-e136-42be-a4ff-88cff9dcce77@www.fastmail.com> In-Reply-To: <157833606256.7987.10843100204677119647.idtracker@ietfa.amsl.com> References: <157833606256.7987.10843100204677119647.idtracker@ietfa.amsl.com> Date: Thu, 09 Jan 2020 13:06:20 +0000 From: "Alexey Melnikov" To: "Alissa Cooper" , "The IESG" Cc: "Jim Fenton" , jmap@ietf.org, draft-ietf-jmap-websocket@ietf.org, jmap-chairs@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Jmap] =?utf-8?q?Alissa_Cooper=27s_Discuss_on_draft-ietf-jmap-we?= =?utf-8?q?bsocket-04=3A_=28with_DISCUSS=29?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 13:07:07 -0000 Hi Alissa, On Mon, Jan 6, 2020, at 6:41 PM, Alissa Cooper via Datatracker wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-jmap-websocket-04: Discuss > > If I understand correctly, in JMAP transport confidentiality is required to use > for requests and in WebSocket it is required to implement but not required to > use. Which set of requirements applies to the binding specified in this > document? Well spotted. I think wss:// is intended here. It looks like the editor is on holidays, so I will wait for him to confirm. Best Regards, Alexey From nobody Thu Jan 9 06:17:03 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251D2120048; Thu, 9 Jan 2020 06:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=fqVK2zP4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KNsYdriO 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 0kyxzNiwThkx; Thu, 9 Jan 2020 06:16:56 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF338120026; Thu, 9 Jan 2020 06:16:55 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 6E1DA7E4; Thu, 9 Jan 2020 09:16:53 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 09 Jan 2020 09:16:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=q dWXbmPZq0cU0ghqHJceMYSQKHOtqaMAwaONSm+AEB8=; b=fqVK2zP45nULoaYRK n9GGuP/zSLhEefqPQ2PpqwiB/rOrqApP+bHgCbUkRdy+70SsxKX8iYlXRSPjBWuq JWXjmz3SXDTbStraHDStpLljBRJQBUq5rTzUnJAEiNGmzuS2qtDq41dQ/S3uRr75 hsMexuODqtUVmTNvo6pGwgLwKtwnQsbJj/TQGHAby49g4Cv0KYcjz+lSKMT358EV acIW7kBlgOAz3SeddJB167wXremOg34lW1PtuV6YgcVB3a8GzrNoznUwlIxyGyDV slOLH1EjgRJ5UePUAU57R1tg0U2lHgNk37w/Z8x8UP9HO6VuHMHDonE0zS2H8tuc 6l9Ow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=qdWXbmPZq0cU0ghqHJceMYSQKHOtqaMAwaONSm+AE B8=; b=KNsYdriOg4xwce7j5IbhpO8uE7kevwnBOhMduneK00TY/owkSpeUsL5oC GXXi7wEGQSQmtIHWICt+VZ5Rh/32bc1PuhP8yIeiCQ1sygREnuqn3r+ap+itC6QY J6dDRuKT559Wr38EO5kH7qjeGKPVBAFhl05plInKC/UVWwmG2BeXO9FsTkZIlZPN O11ZG6t+qiU223wFreMVnanQ0j4/sXzGX3dm8vWQx55XZALsT32M7IW7seelqe7x oMBncE+PAvX/Z23Z00/dVp3v40DKZnvxNrRcFE33VSsCA72eKltN+glOEGtZOuy4 RgGOkYYecb0CLNx1dWpu2NaqKi25Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeiuddgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefmvghn ucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucfkph epjeegrdejjedrkeehrddvhedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghh sehfrghsthhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id EED6F30607D0; Thu, 9 Jan 2020 09:16:51 -0500 (EST) To: Alexey Melnikov , Alissa Cooper , The IESG Cc: Jim Fenton , jmap@ietf.org, draft-ietf-jmap-websocket@ietf.org, jmap-chairs@ietf.org References: <157833606256.7987.10843100204677119647.idtracker@ietfa.amsl.com> <3f8d2180-e136-42be-a4ff-88cff9dcce77@www.fastmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <6753a7d8-e771-bfeb-faf7-09ffeb7019f1@fastmail.com> Date: Thu, 9 Jan 2020 09:16:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <3f8d2180-e136-42be-a4ff-88cff9dcce77@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] Alissa Cooper's Discuss on draft-ietf-jmap-websocket-04: (with DISCUSS) 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, 09 Jan 2020 14:16:57 -0000 I will carve out some time next week to address all of the IESG comments. On 1/9/20 8:06 AM, Alexey Melnikov wrote: > Hi Alissa, > > On Mon, Jan 6, 2020, at 6:41 PM, Alissa Cooper via Datatracker wrote: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-jmap-websocket-04: Discuss >> >> If I understand correctly, in JMAP transport confidentiality is required to use >> for requests and in WebSocket it is required to implement but not required to >> use. Which set of requirements applies to the binding specified in this >> document? > Well spotted. I think wss:// is intended here. > > It looks like the editor is on holidays, so I will wait for him to confirm. > > Best Regards, > Alexey > -- Ken Murchison Cyrus Development Team Fastmail US LLC From nobody Thu Jan 16 20:54:38 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977051200E0 for ; Thu, 16 Jan 2020 20:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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=TErkpUlM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lcd+Owgz 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 bPzvh26xydqU for ; Thu, 16 Jan 2020 20:54:34 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED17A120099 for ; Thu, 16 Jan 2020 20:54:33 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 62C474C9 for ; Thu, 16 Jan 2020 23:54:33 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute6.internal (MEProxy); Thu, 16 Jan 2020 23:54:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=FDt8gMJ voqhxkjU5TO9RghDtkZCiQZWcWCu3iK7s0cE=; b=TErkpUlMGYgtclEYvSFwRBx gLxYp2xR/fe91oNtb92jgwlIMRYCEBjLGmiXGZj9BFrvxOSYAYsjGkvB0h4go3/6 9LvR6/BuKZwC4vy00E3fPhV82khgWQM3Y/klirE7OFt55n/9cEyda2j/mVKy2L53 +qZoGTPjapczNAAOmrTTfuwYaalQYU0tA8LPOAiwFAOUr0UzmIDc0MsXVmkIMxFM 6cMULv/01To+QNKZRAnkAp6gKP4UQ1ReFVDBjvXeE2KJHls4kF/670Yer9TnkVrw wawlsXCl9PdyduwYFDA0dMPuqiJLRI0R/+6zjR8bQqB0/w9d6ZuBe6Sr48zS5uw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FDt8gM JvoqhxkjU5TO9RghDtkZCiQZWcWCu3iK7s0cE=; b=lcd+Owgz5d8vMGh6R6vFCm is12Rr2Vm7yGZ3eqDaIlq6nd4/SIqWKs2mqM4smCdhNMXYzYXMwqL1/NUQND+6aj WwmpD/qyE4vJP0h0NPvBoJNiKg3Df2QiQv9JkG9dEYBHr+3hICq5eubwz0zjE0O5 yxkzHTB22b5lG0YEpmSurLxfO2xAEhaoike0j6Bagjt5xyy9jB4j06Er+DOsLUlK +ldgbDaLtZh0PlZWe8G7X6Hkf5pWQ9dBDdCE4x6hMymkRoByrWS+1LQPJvyV1hod FuNgh/krvgtS7MIy3ihEd+s1kIAgVzvZjZDGUrR3T8syT38hRC+9HCKOslp/0kaQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdeigdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc frrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 931E624009E; Thu, 16 Jan 2020 23:54:32 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1 Mime-Version: 1.0 Message-Id: <058f9550-b495-4d2c-a438-ce195daea081@beta.fastmail.com> In-Reply-To: References: Date: Fri, 17 Jan 2020 15:54:11 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=58a41c7ca6ba4266b3d8ce4bd06b006e Archived-At: Subject: Re: [Jmap] Feedback on the quota draft 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, 17 Jan 2020 04:54:37 -0000 --58a41c7ca6ba4266b3d8ce4bd06b006e Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Following up on this thread - there's been a bunch of feedback on the la= st draft. Can you please produce a new draft incorporating the feedback = so we can discuss it again. I'd like to have this document in a conditio= n to have a productive discussion in Vancouver. Thanks, Bron. On Thu, Nov 21, 2019, at 22:11, Ren=C3=A9 CORDIER wrote: > Hi Bron, hi the Jmap community, > First of all, I apologize for not being present at the meeting, and fo= r forgetting to send a notice about it. I will try to do better in the f= uture ! > Then, thanks a lot for all your feedbacks. Some make total sense to me= , some others we might need to think a bit more and discuss. I will come= back towards you after we take the proper time to analyze all of this. > Cheers, > Rene. > Le 20 novembre 2019 18:20, de brong@fastmailteam.com >> Hi, >>=20 >> This is a combination of feedback collected from the meeting yesterda= y as well as my own suggestions! These suggestions only come with my own= personal weight, and are not a "you must", they are an "I suggest" - pl= ease feel free to offer counter proposals or even outright rejections of= my suggestions, there is no "chair weight" attached. >>=20 >> With that said, here's the suggestions :) >>=20 >> *Scope* >>=20 >> I'm not sure if there's any point to it, but so long as it can be *nu= ll* (which might be the same thing as "account") then I don't see a prob= lem in having it available for those who want it. >>=20 >> I would just call the key "scope" rather than "usedScope". I don't se= e the point of putting different scopes on it, that seems unworkable. In= stead, if you have quotas in multiple scopes I would expect a quota entr= y per scope with the amount that was used and the limit - e.g. "you're u= sing 400Mb of 1Gb account quota, and your domain is using 34Gb of 100Gb = allocated to the domain" - there's no point having "you're using 400Mb o= f your domain's 100Gb", because your domain could be using 99.9Gb and yo= u'd have no way to see - so the "limit" needs to be the total minus what= everyone else is using to be meaningful for calculating what you can do= . >>=20 >> *Datatypes* >>=20 >> At the moment there's no way to tie datatypes to quotas. I would like= to add an array of datatypes to each object (example below). As an exam= ple, you may have a different quota for Calendars than for Mail - or the= y may be shared. This is somewhat different from scope (server, domain, = user, ...). >>=20 >> *Quota/query* >>=20 >> At the moment the only way to get the list of quotas is "Quota/get#id= s: null". I think in the interests of consistency we should allow a /que= ry as well (probably don't need a /queryChanges, just have a canCalculat= eChanges; false, but we could allow that too if a server finds it easy w= ith their general model). >>=20 >> *Quota/changes* >>=20 >> Like with Mailbox/changes - I could see value in having a updatedProp= erties which can be either null or a list of properties, such that you c= ould issue: >>=20 >> [["Quota/changes", { "sinceState": ... }, "1"], >> ["Quota/get", {=20 >> "#ids": { "resultOf": "1", "name": "Quota/changes", "path": "/update= d" },=20 >> "#properties" : { "resultOf": "1", "Quota/changes", "path": "/update= dProperties" }, >> "2"]] >>=20 >> Which might only need to fetch the "used" most of the time. >>=20 >> *Push* >>=20 >> There should be a nod towards Push and mention that Quota state chang= es are pushed like other state changes. >>=20 >> *Description* >>=20 >> Do we need to provide for both a short "name" and a longer "descripti= on" field on each quota? >>=20 >> *Soft limits* >>=20 >> Does anybody care about soft vs hard limits? Soft limit being "you wo= n't be blocked, but you'll be told off any maybe charged more", hard lim= its being "your changes will be rejected". Should we have an optional se= cond limit field in the spec? >>=20 >> Something of this sort was raised on mailing list by John van der Kam= p - in fact he talked of 3 levels. Perhaps they could be something like:= >>=20 >> warnLimit >> softLimit >> limit >>=20 >> Where obviously warnLimit and softLimit are optional (and must each b= e lower than the next level up). This is more complexity, but it's optio= nal complexity at both ends: servers don't need to set them, and clients= don't need to display them. >>=20 >> *Resource Types* >>=20 >> The IMAP quota draft defines three types of resources for quotas, and= also a registry where more can be described. The initial types are "STO= RAGE" (units 1024 octets), "MESSAGE" (number of individual emails) and "= MAILBOX" (number of mailboxes). It maybe viable to use the same registry= . >>=20 >> Of course, then you get issues like what should you call it for Calen= dar or Addressbook? Should the limits be given DAVish names like "COLLEC= TION" and "RESOURCE" such that MESSAGE becomes "RESOURCE" and "MAILBOX" = becomes "COLLECTION"? in JMAP quotas? >>=20 >> Also: should we do storage in bytes, or do 1024 octets for our storag= e numbers in JMAP as well so they map identically to the definition in t= he registry? >>=20 >> *EXAMPLE:* >>=20 >> As promised, a Quota object for my example: >>=20 >> { >> "id": "2a06df0d-9865-4e74-a92f-74dcc814270e", "type": "storage", "used": 105645, "scope": "account", "limit": 200000, "description": "Personal account usage", "name": "brong@brong.net", "datatypes" : [ "Mail", "Calendar", "Contact", "Todo" ], >> } >>=20 >> And this would be displayed in a a box called "Quota Use": >> brong@brong.net 52% >>=20 >> Something like that :) >>=20 >> Cheers, >>=20 >> Bron.** >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --58a41c7ca6ba4266b3d8ce4bd06b006e Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Following up on this thread - there's been a bunch of= feedback on the last draft.  Can you please produce a new draft in= corporating the feedback so we can discuss it again.  I'd like to h= ave this document in a condition to have a productive discussion in Vanc= ouver.

Thanks,
=
Bron.


On Thu, Nov 21, 2019, at 22:11, = Ren=C3=A9 CORDIER wrote:
Hi Bron, hi the Jmap community,

First of all, I apologize for= not being present at the meeting, and for forgetting to send a notice about it. I will try to do= better in the future !

Then, thanks a lot for all your feedba= cks. Some make total sense to me, some others we might need to think a b= it more and discuss. I will come back towards you after we take the prop= er time to analyze all of this.

Cheers,

Rene.

Le 20 novembre 2019 18:20, de b= rong@fastmailteam.com
Hi,

This is a combination of feedback collect= ed from the meeting yesterday as well as my own suggestions!  These= suggestions only come with my own personal weight, and are not a "you m= ust", they are an "I suggest" - please feel free to offer counter propos= als or even outright rejections of my suggestions, there is no "chair we= ight" attached.

With that said, here's the suggestions :)=

Scope
=
I'm not sure if there's any = point to it, but so long as it can be null (which might be the sa= me thing as "account") then I don't see a problem in having it available= for those who want it.

<= /div>
I would just call the key "scope"= rather than "usedScope".  I don't see the point of putting differe= nt scopes on it, that seems unworkable.  Instead, if you have quota= s in multiple scopes I would expect a quota entry per scope with the amo= unt that was used and the limit - e.g. "you're using 400Mb of 1Gb accoun= t quota, and your domain is using 34Gb of 100Gb allocated to the domain"= - there's no point having "you're using 400Mb of your domain's 100Gb", = because your domain could be using 99.9Gb and you'd have no way to see -= so the "limit" needs to be the total minus what everyone else is using = to be meaningful for calculating what you can do.

Data= types

At the moment there's no way to tie datatypes t= o quotas.  I would like to add an array of datatypes to each object= (example below).  As an example, you may have a different quota fo= r Calendars than for Mail - or they may be shared.  This is somewha= t different from scope (server, domain, user, ...).

Quot= a/query

At the moment the only way to get the list of= quotas is "Quota/get#ids: null".  I think in the interests of cons= istency we should allow a /query as well (probably don't need a /queryCh= anges, just have a canCalculateChanges; false, but we could allow that t= oo if a server finds it easy with their general model).

<= b>Quota/changes

Like with Mailbox/changes - I could s= ee value in having a updatedProperties which can be either null or a lis= t of properties, such that you could issue:

[["Quota/chan= ges", { "sinceState": ... }, "1"],
 ["Quota/get", {
=    "#ids": { "resultOf": "1", "name": "Quota/changes", "path": "/updated" },
   "#properties" : { "resultOf": "1", "Quota/changes", "path": "/updatedProperties" },
= "2"]]

Which might only need to fetch the "used" most of t= he time.

Push

There should be a nod= towards Push and mention that Quota state changes are pushed like other= state changes.

Description

Do we n= eed to provide for both a short "name" and a longer "description" field = on each quota?

Soft limits

Does any= body care about soft vs hard limits?  Soft limit being "you won't b= e blocked, but you'll be told off any maybe charged more", hard limits b= eing "your changes will be rejected".  Should we have an optional s= econd limit field in the spec?

Something of this sort was= raised on mailing list by John van der Kamp - in fact he talked of 3 le= vels.  Perhaps they could be something like:

warnLim= it
softLimit
limit

Where obviously warnLimi= t and softLimit are optional (and must each be lower than the next level= up).  This is more complexity, but it's optional complexity at bot= h ends: servers don't need to set them, and clients don't need to displa= y them.

Resource Types

The IMAP quota= draft defines three types of resources for quotas, and also a registry = where more can be described.  The initial types are "STORAGE" (unit= s 1024 octets), "MESSAGE" (number of individual emails) and "MAILBOX" (n= umber of mailboxes).  It maybe viable to use the same registry.
=

Of course, then you get issues like what should you call it = for Calendar or Addressbook?  Should the limits be given DAVish nam= es like "COLLECTION" and "RESOURCE" such that MESSAGE becomes "RESOURCE"= and "MAILBOX" becomes "COLLECTION"? in JMAP quotas?

Also= : should we do storage in bytes, or do 1024 octets for our storage numbe= rs in JMAP as well so they map identically to the definition in the regi= stry?

EXAMPLE:

As promised, a Quota= object for my example:

<= /div>
{
     "id": "2a06d=
f0d-9865-4e74-a92f-74dcc814270e",
     "type": "storage",
     "used": 105645,
     "scope": "account",
     "limit": 200000,
     "description": "Personal account usage",
     "name": "brong@brong.net",
     "datatypes" : [ "Mail", "Calendar", "Contact", "Todo" ],
<= div style=3D"font-family:Arial;">}

And this would be disp= layed in a a box called "Quota Use":
brong@brong.net 52%

Something like that :)

Cheers,

B= ron.
--
  Bron Gondwana, CEO, F= astmail Pty Ltd
  brong@fastma= ilteam.com


__________________= _____________________________
Jmap mailing list
<= div>Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jm= ap


--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com
<= div class=3D"signature">

--58a41c7ca6ba4266b3d8ce4bd06b006e-- From nobody Thu Jan 16 20:57:36 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AFF1200D6 for ; Thu, 16 Jan 2020 20:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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=JZ9VUcnd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PEdpW79q 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 qZhwWQIGPiTy for ; Thu, 16 Jan 2020 20:57:32 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95744120099 for ; Thu, 16 Jan 2020 20:57:32 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E46EC4C9; Thu, 16 Jan 2020 23:57:31 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute6.internal (MEProxy); Thu, 16 Jan 2020 23:57:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=L0yH 77lorxULNkXBKFLuWgN0FOFnkSU3MwVGLg9XT9E=; b=JZ9VUcndbtyts0naz9hN wx3D+TwLqS/8k+MhpqoaKaKgfF3rCDLo9HB/IPYEarHXChbQDHHGrMePCnUls3lp z2lzHq2SK7R5sFs0MC/e1bbcAYw+uuhuxwCuwFeVaQc2yLH8Ubk6n/Ef2kqWaTOX xxuEDJ+MuffcofORk4FlrdsTFTj/CEsi6tXrVnYlDom2zjGBGcO44rycWebjDNG4 L1Gdf9dsR9jLjIJzFqVwDCEIgF5DbBDySek0c2aGcVoDFRqenjxMAu0CdtiSm3gK pwyjYKTW2PpAYHQdDs1crr4hhM6qKhYDFJP9KdXz3GKjDalGJ+WkAvNDaxQvIppd 4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=L0yH77 lorxULNkXBKFLuWgN0FOFnkSU3MwVGLg9XT9E=; b=PEdpW79qQHB09cvs1OHJ2B SmKDuxIYk9yXoBvlW1HcXMorzrGVPAY0YMrsy+v/qRD9smWOb5MRiTq/zZr6ByKX naxXJECVCDZI69QavKx0Xuh2ZCMtqk2kVgMBx5H00Ad2rR02GRnHtempEUbVe30r hVC/NfYB+PGpbzzvyg2ac1EKpVxIEWxnZ98wbDGpGKsgwmEj0/64tjPhlfDEcsDt acTMEbMzXscB3uBlzE1sZ3iEILGZtEvYkwQlhnrBR7EVYvELv+tenEsUTxHKjQSz yBfGrBukzG9mxs/DRkLWdRT8RSe5thclPzm6O+J66myHx5qLvqyMBWWkwsMEtq3w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdeigdejfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhepihgvthhfrdhorhhgpdhivghtfhdrrdhorhhgnecurfgrrhgrmhep mhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlh hushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0F90C24009E; Thu, 16 Jan 2020 23:57:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com> Date: Fri, 17 Jan 2020 15:57:10 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: "Raphael OUAZANA" Content-Type: multipart/alternative; boundary=465820058ff6431dba9e0c0f735f4592 Archived-At: Subject: Re: [Jmap] Working group last call: draft-ietf-jmap-mdn-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: Fri, 17 Jan 2020 04:57:35 -0000 --465820058ff6431dba9e0c0f735f4592 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry that I haven't gone ahead with this! It's on my list to write up t= he Shepherding document and submit it. Just to confirm, can you let me know if you have any IPR to disclose for= this document. Thanks, Bron. On Tue, Dec 17, 2019, at 03:58, Raphael OUAZANA wrote: > Thank you all for your remarks. > I uploaded a new version of the draft. I have taken care of all the co= mments that were made, thank you very much for the suggestions, it was r= eally helpful. > Regards, > Rapha=C3=ABl. > Le 22 novembre 2019 06:19, de brong@fastmailteam.com >> Raphael, >>=20 >> With my chair hat on - I'm happy for you to either issue drafts with = updates during the last call period, or wait until the end and issue ano= ther draft containing all the feedback at the end of the last call perio= d. >>=20 >> Either way, I'm happy to submit to publication after this last call w= ithout doing another last call - so long as those who have given feedbac= k during this time agree that it's been addressed in the final draft! >>=20 >> Cheers, >>=20 >> Bron. >>=20 >> On Fri, Nov 22, 2019, at 15:51, Neil Jenkins wrote: >>> Overall I think this doc is good. A few nits: >>>=20 >>>> o forEmailId: "String" Email Id of the received email this MDN is relative to. >>>=20 >>> This needs to be nullable, as described in MDN/parse. >>>=20 >>>> o originalMessageID: "String|null" (server-set) >>>=20 >>> I think this should be *originalMessageId* (lowercase d on the end) = for consistency. >>>=20 >>>> 2.1 . MDN/set >>>>=20 Standard "/set" method as described in [RFC8620 ] where only the _create_ parameter is supported. >>>=20 >>> This is not quite right: the "accountId" and "ifInState" arguments a= re fine. I think this text should say something like: >>>=20 >>>> Only create is supported; any attempt to update/destroy MUST be rej= ected with a "forbidden" SetError. >>>=20 >>> And as a general comment, in the final versions of RFC8620/8621 we c= leaned up the formatting so it worked better in the plain text version o= f the RFCs; I suggest adopting the same. So we use "quote" for a propert= y name reference (not _underscore_) and remove the *asterisks* around th= e property names in the definitions. >>>=20 >>> Cheers, >>> Neil. >>> _______________________________________________ >>> Jmap mailing list >>> Jmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/jmap >>>=20 >>=20 >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --465820058ff6431dba9e0c0f735f4592 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sorry that I haven't gone ahead with this!  It's= on my list to write up the Shepherding document and submit it.

Just to confirm, can you let me know if you have any IPR to discl= ose for this document.

Thanks,

Bron.

On Tue, Dec 17, 201= 9, at 03:58, Raphael OUAZANA wrote:

Thank you all for your remarks.

I uploaded a new v= ersion of the draft. I have taken care of all the comments that were mad= e, thank you very much for the suggestions, it was really helpful.

Regards,

Rapha=C3=ABl.

Le 22 novembre 2019 06:19, de brong@fastmailteam.com=
Raphael,
With my chair hat on - I'm hap= py for you to either issue drafts with updates during the last call peri= od, or wait until the end and issue another draft containing all the fee= dback at the end of the last call period.

Either wa= y, I'm happy to submit to publication after this last call without doing= another last call - so long as those who have given feedback during thi= s time agree that it's been addressed in the final draft!

Cheers,

Bron.

On Fri, Nov 22, 2019, at 15:51, Neil Jenkins wro= te:
Overall I think= this doc is good. A few nits:

o  forEmailId: "String" Email Id of the re=
ceived email this MDN is
   relative to.

This needs to = be nullable, as described in MDN/parse.

o  originalMessageID: "Str=
ing|null" (server-set)

I think= this should be originalMessageId (lowercase d on the end) f= or consistency.

2.1.  MDN/set

   Standard "/set" method as described in [RFC8620] where only the
   _create_ parameter is supported.
This is not quite right: the "accountId" and "ifInState" arg= uments are fine. I think this text should say something like:
<= div>
Only create is supported; a= ny attempt to update/destroy MUST be rejected with a "forbidden" SetErro= r.

And as a general comment, i= n the final versions of RFC8620/8621 we cleaned up the formatting so it = worked better in the plain text version of the RFCs; I suggest adopting = the same. So we use "quote" for a property name reference (not _undersco= re_) and remove the *asterisks* around the property names in the definit= ions.

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


--
  Bron Go= ndwana, CEO, Fastmail Pty Ltd
 = ; brong@fastmailteam.com

=

____= ___________________________________________
Jmap mailing l= ist
Jmap@ietf.org
https://www.ietf.org/mailm= an/listinfo/jmap


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


--465820058ff6431dba9e0c0f735f4592-- From nobody Thu Jan 16 23:31:57 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC87912080A for ; Thu, 16 Jan 2020 23:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, 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 (2048-bit key) header.d=linagora.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 amcJ_4NUov64 for ; Thu, 16 Jan 2020 23:31:50 -0800 (PST) Received: from outgoing.linagora.com (outgoing.linagora.com [51.75.198.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3D61207FC for ; Thu, 16 Jan 2020 23:31:49 -0800 (PST) Received: from linagora.com (unknown [10.233.69.202]) by outgoing.linagora.com (Postfix) with ESMTP id A76933B for ; Fri, 17 Jan 2020 07:31:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1579246307; bh=YkrP6fYR3Wq2H1Y+DaCrp8zwOruhwOHY+qWfHyNwq+U=; h=From:Reply-To:To:Subject:Date:References:From; b=lv6gNIvw1z5uLt+n6np2ohDRol7rJEBjcd0GxrD4KBcLbJgECRQ4Jq2N/UukuPHnW Lh4V8bnMGjs+LqN07LSyVKbJDVSVk+K08XaHFmUlD2exEOSNkF+7vGKxmVFead/BDk eekVn32FSy7A23FPoQNJx6Z5xQHEHW6tElf1q4fBAHJgBRm+ZhPqB1sf3erEFYBtu9 jvGUZH2r0z6oHcceLil2XUZK9fNxxakJ+XI4/ukGgBGsMW/Ex/J8MTDtnQQcSSg8VR tqYeKO6/gL+RiTHor2TH5yBT3DCP2AZfOhbEjtj4bPfRn68x9qiC4t8iUUcJD8HaI+ HLx2hEJVDsezg== MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Ren=E9_CORDIER?= Sender: =?ISO-8859-1?Q?Ren=E9_CORDIER?= Reply-To: rcordier@linagora.com To: "jmap@ietf.org" Message-ID: Date: Fri, 17 Jan 2020 07:31:46 +0000 References: Archived-At: Subject: Re: [Jmap] Feedback on the quota draft 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, 17 Jan 2020 07:31:55 -0000

Hi Bron,

I've been lacking time unfortunately lately to rework on = this, but it's still in the back of my mind=2E I should be able to give it = more thoughts on it and rework it soon=2E When is your meeting in Vancouver= ?

Apologies regarding the delay !

Cheers,

Rene=2E

= Le 17 janvier 2020 11:54, de brong@fastmailteam=2Ecom
Following up on this thr= ead - there's been a bunch of feedback on the last draft=2E  Can you p= lease produce a new draft incorporating the feedback so we can discuss it a= gain=2E  I'd like to have this document in a condition to have a produ= ctive discussion in Vancouver=2E

Thanks,

Bron=2E


On Thu, Nov 21,= 2019, at 22:11, Ren=C3=A9 CORDIER wrote:

Hi Bron, hi the Jmap community,

First of all, I ap= ologize for not being present at the meeting, and for forgetting to send a= notice about it=2E I will try to do better in the future !

Then= , thanks a lot for all your feedbacks=2E Some make total sense to me, some = others we might need to think a bit more and discuss=2E I will come back to= wards you after we take the proper time to analyze all of this=2E

Cheers,

Rene=2E

L= e 20 novembre 2019 18:20, de brong@fastmailteam=2Ecom
Hi,

This is a combinat= ion of feedback collected from the meeting yesterday as well as my own sugg= estions!  These suggestions only come with my own personal weight, and= are not a "you must", they are an "I suggest" - please feel free to offer = counter proposals or even outright rejections of my suggestions, there is n= o "chair weight" attached=2E
With that said, here's the suggest= ions :)

Scope

I'm not sure if there's any po= int to it, but so long as it can be null (which might be the same th= ing as "account") then I don't see a problem in having it available for tho= se who want it=2E

I would just call the key "scope" rather than= "usedScope"=2E  I don't see the point of putting different scopes on = it, that seems unworkable=2E  Instead, if you have quotas in multiple = scopes I would expect a quota entry per scope with the amount that was used= and the limit - e=2Eg=2E "you're using 400Mb of 1Gb account quota, and you= r domain is using 34Gb of 100Gb allocated to the domain" - there's no point= having "you're using 400Mb of your domain's 100Gb", because your domain co= uld be using 99=2E9Gb and you'd have no way to see - so the "limit" needs t= o be the total minus what everyone else is using to be meaningful for calcu= lating what you can do=2E

Datatypes

At the = moment there's no way to tie datatypes to quotas=2E  I would like to a= dd an array of datatypes to each object (example below)=2E  As an exam= ple, you may have a different quota for Calendars than for Mail - or they m= ay be shared=2E  This is somewhat different from scope (server, domain= , user, =2E=2E=2E)=2E

=
Quota/query

At the mom= ent the only way to get the list of quotas is "Quota/get#ids: null"=2E = ; I think in the interests of consistency we should allow a /query as well = (probably don't need a /queryChanges, just have a canCalculateChanges; fals= e, but we could allow that too if a server finds it easy with their general= model)=2E

Quota/changes

Like with Mailbox/= changes - I could see value in having a updatedProperties which can be eith= er null or a list of properties, such that you could issue:

[["= Quota/changes", { "sinceState": =2E=2E=2E }, "1"],
 ["Quota/get", {
   "#ids": { "resultOf": = "1", "name": "Quota/changes", = "path": "/updated" },
   "#properties" : { "resultOf": = "1", "Quota/changes", "path": "/updatedProper= ties" },
"2"]]

Which might only need to fetch the "used" most of the = time=2E

Push
=
There should be a nod towards P= ush and mention that Quota state changes are pushed like other state change= s=2E

Description

Do we need to provide for b= oth a short "name" and a longer "description" field on each quota?

Soft limits

Does anybody care about soft vs hard lim= its?  Soft limit being "you won't be blocked, but you'll be told off a= ny maybe charged more", hard limits being "your changes will be rejected"= =2E  Should we have an optional second limit field in the spec?

Something of this sort was raised on mailing list by John van der Kam= p - in fact he talked of 3 levels=2E  Perhaps they could be something = like:

warnLimit
soft= Limit
limit

Where o= bviously warnLimit and softLimit are optional (and must each be lower than = the next level up)=2E  This is more complexity, but it's optional comp= lexity at both ends: servers don't need to set them, and clients don't need= to display them=2E

Resource Types

The IMA= P quota draft defines three types of resources for quotas, and also a regis= try where more can be described=2E  The initial types are "STORAGE" (u= nits 1024 octets), "MESSAGE" (number of individual emails) and "MAILBOX" (n= umber of mailboxes)=2E  It maybe viable to use the same registry=2E

Of course, then you get issues like what should you call it for C= alendar or Addressbook?  Should the limits be given DAVish names like = "COLLECTION" and "RESOURCE" such that MESSAGE becomes "RESOURCE" and "MAILB= OX" becomes "COLLECTION"? in JMAP quotas?

Also: should we do st= orage in bytes, or do 1024 octets for our storage numbers in JMAP as well s= o they map identically to the definition in the registry?

EX= AMPLE:

As promised, a Quota object for my example:

{
     "id": "2a06df0d-9865-4e74-a92f-74dcc814270e",
   =
  "type": "storage",
     "used": 105645,
     "scope": "account",
     "li=
mit": 200000,
     "description": "Personal account usage",
     "name": "<=
a href=3D"mailto:brong@brong=2Enet">brong@brong=2Enet",
     "datatypes=
" : [ "Mail", "Calendar", "Contact", "Todo" ],
}

And this would be displayed in a a box called = "Quota Use":

Something like that= :)

Cheers,

Bron=2E
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam=2Ecom


_______________________________________________
Jmap = mailing list
Jmap@ietf=2Eorg
https://www=2Eietf= =2Eorg/mailman/listinfo/jmap


--
  Bron Gondwana, CEO, Fa= stmail Pty Ltd
  brong@fastmailteam= =2Ecom


From nobody Thu Jan 16 23:53:04 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DAD1207FC for ; Thu, 16 Jan 2020 23:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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=lRC/5nTU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=exknKUwn 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 zV_T3Vb_6wxW for ; Thu, 16 Jan 2020 23:52:55 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079C7120273 for ; Thu, 16 Jan 2020 23:52:55 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id AA4CF48D; Fri, 17 Jan 2020 02:52:53 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute6.internal (MEProxy); Fri, 17 Jan 2020 02:52:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=i1cd RxP+rV1A/PHRkLsCw8OHz+mCrc1FdbpOV0FrDuA=; b=lRC/5nTUhPjt9JDNd9us 28Zeohaj0Ni/V/1ePe9Bl5y3jJq+bRc+ge/CrI9T6ZdYXXAtTr/nj1F5PHBvDf/P v6QQibyNnlUYcalHLcs83YA/2T+LINPPKy7nheB235aklhaBnJhkde6EI+l8GNTs 12V5C8Gi4DHq5kIpJsJxpkXq+nE2Z69/wKIaO1I4qO/r9kavY+CdVYS+9avL+Eer gkb/XkHhd3ZowKms5goMf1oUc1IZX7XSu3bNX1CSSnbd330RvzSdiJTBabasyXRb U8bxqtsG/zOc6o6wRDVfvcyfa54VM/rRd9nY6JDUQj24qQA9DNi4QokHRcbE4Ljm vg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=i1cdRx P+rV1A/PHRkLsCw8OHz+mCrc1FdbpOV0FrDuA=; b=exknKUwnDO4qufjT8T/Fed CXWnu0xEAdMUvKjcRgclLr6lbwrQMgWgeT5k/ccwOQrgIcmNCu1Yd7JQYrsIQveE InBRR5RpBNo9zYONP5oPoXCABS2i9sEkmTHbhz/D+I3uVf0RIF4Nc3MuD3mXPYpL Q7ST4SGcEHF45HLUOy7LCg3WqjzsjnjIjZcyV7qSjRpeL4trZ31EENZS9WYRSn+Q 5o9vxXT5nZqd4miGRDlsQ+qHtIApl8x1Yhf7/xk38JcWzS396NLZhjgruEnwVsMz uwznZncOHTXiC5LOJTukmWEQ3NVTwdyg7tD8O4w3AvzsW/57JeLhBwzlrwp4a5rQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdeigddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhep sghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E080724009E; Fri, 17 Jan 2020 02:52:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1 Mime-Version: 1.0 Message-Id: <4cf1ef6d-6e5e-4d7e-8022-adafb2949932@dogfood.fastmail.com> In-Reply-To: References: Date: Fri, 17 Jan 2020 18:52:33 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: =?UTF-8?Q?Ren=C3=A9_CORDIER?= Content-Type: multipart/alternative; boundary=2d784004904f48098d0e01acfc637634 Archived-At: Subject: Re: [Jmap] Feedback on the quota draft 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, 17 Jan 2020 07:53:00 -0000 --2d784004904f48098d0e01acfc637634 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rene, IETF107 in Vancouver is 21-17 March. Cheers, Bron. On Fri, Jan 17, 2020, at 18:31, Ren=C3=A9 CORDIER wrote: > Hi Bron, > I've been lacking time unfortunately lately to rework on this, but it'= s still in the back of my mind. I should be able to give it more thought= s on it and rework it soon. When is your meeting in Vancouver? > Apologies regarding the delay ! > Cheers, > Rene. > Le 17 janvier 2020 11:54, de brong@fastmailteam.com >> Following up on this thread - there's been a bunch of feedback on the= last draft. Can you please produce a new draft incorporating the feedba= ck so we can discuss it again. I'd like to have this document in a condi= tion to have a productive discussion in Vancouver. >>=20 >> Thanks, >>=20 >> Bron. >>=20 >>=20 >> On Thu, Nov 21, 2019, at 22:11, Ren=C3=A9 CORDIER wrote: >>> Hi Bron, hi the Jmap community, >>> First of all, I apologize for not being present at the meeting, and = for forgetting to send a notice about it. I will try to do better in the= future ! >>> Then, thanks a lot for all your feedbacks. Some make total sense to = me, some others we might need to think a bit more and discuss. I will co= me back towards you after we take the proper time to analyze all of this= . >>> Cheers, >>> Rene. >>> Le 20 novembre 2019 18:20, de brong@fastmailteam.com >>>> Hi, >>>>=20 >>>> This is a combination of feedback collected from the meeting yester= day as well as my own suggestions! These suggestions only come with my o= wn personal weight, and are not a "you must", they are an "I suggest" - = please feel free to offer counter proposals or even outright rejections = of my suggestions, there is no "chair weight" attached. >>>>=20 >>>> With that said, here's the suggestions :) >>>>=20 >>>> *Scope* >>>>=20 >>>> I'm not sure if there's any point to it, but so long as it can be *= null* (which might be the same thing as "account") then I don't see a pr= oblem in having it available for those who want it. >>>>=20 >>>> I would just call the key "scope" rather than "usedScope". I don't = see the point of putting different scopes on it, that seems unworkable. = Instead, if you have quotas in multiple scopes I would expect a quota en= try per scope with the amount that was used and the limit - e.g. "you're= using 400Mb of 1Gb account quota, and your domain is using 34Gb of 100G= b allocated to the domain" - there's no point having "you're using 400Mb= of your domain's 100Gb", because your domain could be using 99.9Gb and = you'd have no way to see - so the "limit" needs to be the total minus wh= at everyone else is using to be meaningful for calculating what you can = do. >>>>=20 >>>> *Datatypes* >>>>=20 >>>> At the moment there's no way to tie datatypes to quotas. I would li= ke to add an array of datatypes to each object (example below). As an ex= ample, you may have a different quota for Calendars than for Mail - or t= hey may be shared. This is somewhat different from scope (server, domain= , user, ...). >>>>=20 >>>> *Quota/query* >>>>=20 >>>> At the moment the only way to get the list of quotas is "Quota/get#= ids: null". I think in the interests of consistency we should allow a /q= uery as well (probably don't need a /queryChanges, just have a canCalcul= ateChanges; false, but we could allow that too if a server finds it easy= with their general model). >>>>=20 >>>> *Quota/changes* >>>>=20 >>>> Like with Mailbox/changes - I could see value in having a updatedPr= operties which can be either null or a list of properties, such that you= could issue: >>>>=20 >>>> [["Quota/changes", { "sinceState": ... }, "1"], >>>> ["Quota/get", {=20 >>>> "#ids": { "resultOf": "1", "name": "Quota/changes", "path": "/upda= ted" },=20 >>>> "#properties" : { "resultOf": "1", "Quota/changes", "path": "/upda= tedProperties" }, >>>> "2"]] >>>>=20 >>>> Which might only need to fetch the "used" most of the time. >>>>=20 >>>> *Push* >>>>=20 >>>> There should be a nod towards Push and mention that Quota state cha= nges are pushed like other state changes. >>>>=20 >>>> *Description* >>>>=20 >>>> Do we need to provide for both a short "name" and a longer "descrip= tion" field on each quota? >>>>=20 >>>> *Soft limits* >>>>=20 >>>> Does anybody care about soft vs hard limits? Soft limit being "you = won't be blocked, but you'll be told off any maybe charged more", hard l= imits being "your changes will be rejected". Should we have an optional = second limit field in the spec? >>>>=20 >>>> Something of this sort was raised on mailing list by John van der K= amp - in fact he talked of 3 levels. Perhaps they could be something lik= e: >>>>=20 >>>> warnLimit >>>> softLimit >>>> limit >>>>=20 >>>> Where obviously warnLimit and softLimit are optional (and must each= be lower than the next level up). This is more complexity, but it's opt= ional complexity at both ends: servers don't need to set them, and clien= ts don't need to display them. >>>>=20 >>>> *Resource Types* >>>>=20 >>>> The IMAP quota draft defines three types of resources for quotas, a= nd also a registry where more can be described. The initial types are "S= TORAGE" (units 1024 octets), "MESSAGE" (number of individual emails) and= "MAILBOX" (number of mailboxes). It maybe viable to use the same regist= ry. >>>>=20 >>>> Of course, then you get issues like what should you call it for Cal= endar or Addressbook? Should the limits be given DAVish names like "COLL= ECTION" and "RESOURCE" such that MESSAGE becomes "RESOURCE" and "MAILBOX= " becomes "COLLECTION"? in JMAP quotas? >>>>=20 >>>> Also: should we do storage in bytes, or do 1024 octets for our stor= age numbers in JMAP as well so they map identically to the definition in= the registry? >>>>=20 >>>> *EXAMPLE:* >>>>=20 >>>> As promised, a Quota object for my example: >>>>=20 >>>> { >>>> "id": "2a06df0d-9865-4e74-a92f-74dcc814270e", "type": "storage", "used": 105645, "scope": "account", "limit": 200000, "description": "Personal account usage", "name": "brong@brong.net", "datatypes" : [ "Mail", "Calendar", "Contact", "Todo" ], >>>> } >>>>=20 >>>> And this would be displayed in a a box called "Quota Use": >>>> brong@brong.net 52% >>>>=20 >>>> Something like that :) >>>>=20 >>>> Cheers, >>>>=20 >>>> Bron.** >>>> -- >>>> Bron Gondwana, CEO, Fastmail Pty Ltd >>>> brong@fastmailteam.com >>>>=20 >>>>=20 >>> _______________________________________________ >>> Jmap mailing list >>> Jmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/jmap >>>=20 >>=20 >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --2d784004904f48098d0e01acfc637634 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Rene,
<= br>
IETF107 in Vancouver is 21-17= March.

Cheers,
=
Bron.

On F= ri, Jan 17, 2020, at 18:31, Ren=C3=A9 CORDIER wrote:

Hi Bron,

I've been lacking time u= nfortunately lately to rework on this, but it's still in the back of my = mind. I should be able to give it more thoughts on it and rework it soon= . When is your meeting in Vancouver?

Apologies regarding the d= elay !

Cheers,

Rene.

Le 17 janvier 2020 11:54, de brong@fastmailteam.com
Following up o= n this thread - there's been a bunch of feedback on the last draft. = ; Can you please produce a new draft incorporating the feedback so we ca= n discuss it again.  I'd like to have this document in a condition = to have a productive discussion in Vancouver.

Thanks,
=

Bron.


On Thu, Nov 21, 2019, at 22:11, Ren=C3=A9 CORDIER wrote:=

Hi Bron, hi the Jmap= community,

First of all, I apologize for not being present at= the meeting, and for forgetting to send a notice about it. I will try to do= better in the future !

Then, thanks a lot for all your feedba= cks. Some make total sense to me, some others we might need to think a b= it more and discuss. I will come back towards you after we take the prop= er time to analyze all of this.

Cheers,

Rene.

Le 20 novembre 2019 18:20, de b= rong@fastmailteam.com
Hi,

This is a combination of feedback collect= ed from the meeting yesterday as well as my own suggestions!  These= suggestions only come with my own personal weight, and are not a "you m= ust", they are an "I suggest" - please feel free to offer counter propos= als or even outright rejections of my suggestions, there is no "chair we= ight" attached.

With that said, here's the suggestions :)=

Scope
=
I'm not sure if there's any = point to it, but so long as it can be null (which might be the sa= me thing as "account") then I don't see a problem in having it available= for those who want it.

<= /div>
I would just call the key "scope"= rather than "usedScope".  I don't see the point of putting differe= nt scopes on it, that seems unworkable.  Instead, if you have quota= s in multiple scopes I would expect a quota entry per scope with the amo= unt that was used and the limit - e.g. "you're using 400Mb of 1Gb accoun= t quota, and your domain is using 34Gb of 100Gb allocated to the domain"= - there's no point having "you're using 400Mb of your domain's 100Gb", = because your domain could be using 99.9Gb and you'd have no way to see -= so the "limit" needs to be the total minus what everyone else is using = to be meaningful for calculating what you can do.

Data= types

At the moment there's no way to tie datatypes t= o quotas.  I would like to add an array of datatypes to each object= (example below).  As an example, you may have a different quota fo= r Calendars than for Mail - or they may be shared.  This is somewha= t different from scope (server, domain, user, ...).

Quot= a/query

At the moment the only way to get the list of= quotas is "Quota/get#ids: null".  I think in the interests of cons= istency we should allow a /query as well (probably don't need a /queryCh= anges, just have a canCalculateChanges; false, but we could allow that t= oo if a server finds it easy with their general model).

<= b>Quota/changes

Like with Mailbox/changes - I could s= ee value in having a updatedProperties which can be either null or a lis= t of properties, such that you could issue:

[["Quota/chan= ges", { "sinceState": ... }, "1"],
 ["Quota/get", {
=    "#ids": { "resultOf": "1", "name": "Quota/changes", "path": "/updated" },
   "#properties" : { "resultOf": "1", "Quota/changes", "path": "/updatedProperties" },
= "2"]]

Which might only need to fetch the "used" most of t= he time.

Push

There should be a nod= towards Push and mention that Quota state changes are pushed like other= state changes.

Description

Do we n= eed to provide for both a short "name" and a longer "description" field = on each quota?

Soft limits

Does any= body care about soft vs hard limits?  Soft limit being "you won't b= e blocked, but you'll be told off any maybe charged more", hard limits b= eing "your changes will be rejected".  Should we have an optional s= econd limit field in the spec?

Something of this sort was= raised on mailing list by John van der Kamp - in fact he talked of 3 le= vels.  Perhaps they could be something like:

warnLim= it
softLimit
limit

Where obviously warnLimi= t and softLimit are optional (and must each be lower than the next level= up).  This is more complexity, but it's optional complexity at bot= h ends: servers don't need to set them, and clients don't need to displa= y them.

Resource Types

The IMAP quota= draft defines three types of resources for quotas, and also a registry = where more can be described.  The initial types are "STORAGE" (unit= s 1024 octets), "MESSAGE" (number of individual emails) and "MAILBOX" (n= umber of mailboxes).  It maybe viable to use the same registry.
=

Of course, then you get issues like what should you call it = for Calendar or Addressbook?  Should the limits be given DAVish nam= es like "COLLECTION" and "RESOURCE" such that MESSAGE becomes "RESOURCE"= and "MAILBOX" becomes "COLLECTION"? in JMAP quotas?

Also= : should we do storage in bytes, or do 1024 octets for our storage numbe= rs in JMAP as well so they map identically to the definition in the regi= stry?

EXAMPLE:

As promised, a Quota= object for my example:

<= /div>
{
     "id": "2a06d=
f0d-9865-4e74-a92f-74dcc814270e",
     "type": "storage",
     "used": 105645,
     "scope": "account",
     "limit": 200000,
     "description": "Personal account usage",
     "name": "brong@brong.net",
     "datatypes" : [ "Mail", "Calendar", "Contact", "Todo" ],
<= div style=3D"font-family:Arial;">}

And this would be disp= layed in a a box called "Quota Use":
brong@brong.net 52%

Something like that :)

Cheers,

B= ron.
--
  Bron Gondwan= a, CEO, Fastmail Pty Ltd
  = brong@fastmailteam.com


___= ____________________________________________
Jmap mailing = list
Jmap@ietf.org
https://www.ietf.org/mail= man/listinfo/jmap


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


____________= ___________________________________
Jmap mailing list
<= /div>
Jmap@ietf.org
https://www.ietf.org/mailman/listi= nfo/jmap


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


--2d784004904f48098d0e01acfc637634-- From nobody Fri Jan 17 00:07:02 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DCB12080F for ; Fri, 17 Jan 2020 00:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, 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 (2048-bit key) header.d=linagora.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 IF8hIrlknsqk for ; Fri, 17 Jan 2020 00:06:55 -0800 (PST) Received: from outgoing.linagora.com (outgoing.linagora.com [51.75.198.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A91012080C for ; Fri, 17 Jan 2020 00:06:54 -0800 (PST) Received: from linagora.com (unknown [10.233.69.202]) by outgoing.linagora.com (Postfix) with ESMTP id 5E4683B; Fri, 17 Jan 2020 08:06:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1579248413; bh=JYGLGDq46Q4XfWBbjOaaoRV485MH2HQFrXklVXrK+c4=; h=From:Reply-To:To:Subject:Date:References:From; b=c9yCrbZgfk/uDagkMKJl4PSv0PrjobaxM6Bd9bnYUT+hZK69+icmlfohzcmsAk+CT z1BOCLoJaPahanEpuW/Cb6JLFBKkKY3noGNFgmyyMIfpjL7lPEsTs+6wTJSmBHrnJQ +6JfxLL4BvPolKJtueYRZlrB+xDO4rkx8aGjnWBHUaoCfKCfPouglcYY9YhSbjDnjp MYeBN1TY5kOgm1mNG/EjwnRiyyJ5E7ARFvPhKeovNMmL13d8hLrlqra+ywOeEh/4m9 mMU2vhOI3Uw4mo7g0+042PXA8PI3tFysAL/p4W9bUehJHKnRc+nmv1BK6LQ96zWNwj RXsSeSREZfIQA== MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Ren=E9_CORDIER?= Sender: =?ISO-8859-1?Q?Ren=E9_CORDIER?= Reply-To: rcordier@linagora.com To: "jmap@ietf.org" , Bron Gondwana Message-ID: Date: Fri, 17 Jan 2020 08:06:48 +0000 References: Archived-At: Subject: Re: [Jmap] Feedback on the quota draft 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, 17 Jan 2020 08:07:00 -0000

That should do it, thank you Bron !

Cheers,

Rene=2E

<= cite>Le 17 janvier 2020 14:52, de brong@fastmailteam=2Ecom
Hi Rene,

IETF= 107 in Vancouver is 21-17 March=2E

Cheers,

Bron=2E

On Fri, Jan 17, 2020, at 18:31, Ren=C3=A9 CORDIER wrote:=

Hi Bron,

I've be= en lacking time unfortunately lately to rework on this, but it's still in t= he back of my mind=2E I should be able to give it more thoughts on it and r= ework it soon=2E When is your meeting in Vancouver?

Apologies reg= arding the delay !

Cheers,

Rene=2E

Le 17 janvier 2020 11:54, de brong@fastmailteam= =2Ecom
Follow= ing up on this thread - there's been a bunch of feedback on the last draft= =2E  Can you please produce a new draft incorporating the feedback so = we can discuss it again=2E  I'd like to have this document in a condit= ion to have a productive discussion in Vancouver=2E

Thanks,
=
<= br>
Bron=2E


On Thu, Nov 21, 2019, at 22:11, Ren=C3=A9 CORDIER wrote:
=

Hi Bron, hi the Jmap community,

First of all, I apologize for not being present at the meeting, a= nd for forgetting to send a notice about it=2E I will try to do better in = the future !

Then, thanks a lot for all your feedbacks=2E Some ma= ke total sense to me, some others we might need to think a bit more and dis= cuss=2E I will come back towards you after we take the proper time to analy= ze all of this=2E

Cheers,

Rene=2E

Le 20 novembre 2019 18:20, de brong@fastmailteam= =2Ecom
Hi,

This is a combination of feedback collected from the meeting yest= erday as well as my own suggestions!  These suggestions only come with= my own personal weight, and are not a "you must", they are an "I suggest" = - please feel free to offer counter proposals or even outright rejections o= f my suggestions, there is no "chair weight" attached=2E

With t= hat said, here's the suggestions :)

Scope

I'= m not sure if there's any point to it, but so long as it can be null= (which might be the same thing as "account") then I don't see a problem in= having it available for those who want it=2E

I would just call= the key "scope" rather than "usedScope"=2E  I don't see the point of = putting different scopes on it, that seems unworkable=2E  Instead, if = you have quotas in multiple scopes I would expect a quota entry per scope w= ith the amount that was used and the limit - e=2Eg=2E "you're using 400Mb o= f 1Gb account quota, and your domain is using 34Gb of 100Gb allocated to th= e domain" - there's no point having "you're using 400Mb of your domain's 10= 0Gb", because your domain could be using 99=2E9Gb and you'd have no way to = see - so the "limit" needs to be the total minus what everyone else is usin= g to be meaningful for calculating what you can do=2E

Data= types

At the moment there's no way to tie datatypes to qu= otas=2E  I would like to add an array of datatypes to each object (exa= mple below)=2E  As an example, you may have a different quota for Cale= ndars than for Mail - or they may be shared=2E  This is somewhat diffe= rent from scope (server, domain, user, =2E=2E=2E)=2E

Quota/q= uery

At the moment the only way to get the list of quotas i= s "Quota/get#ids: null"=2E  I think in the interests of consistency we= should allow a /query as well (probably don't need a /queryChanges, just h= ave a canCalculateChanges; false, but we could allow that too if a server f= inds it easy with their general model)=2E

Quota/changes<= br>

Like with Mailbox/changes - I could see value in having a updat= edProperties which can be either null or a list of properties, such that yo= u could issue:

[["Quota/changes", { "sinceState": =2E=2E=2E }, = "1"],
 ["Quota/get", {
=
   "#ids": { = "resultOf": "1", "name": "Q= uota/changes", "path": "/updated" = },
   = "#properties" : { "resultOf": "1", "Quota/changes", = "path": "/updatedProperties" },
<= div style=3D"font-family:Arial;">"2"]]

Which might only need to= fetch the "used" most of the time=2E

Push

T= here should be a nod towards Push and mention that Quota state changes are = pushed like other state changes=2E

Description
=

Do we need to provide for both a short "name" and a longer "description"= field on each quota?

=
Soft limits

Does anybo= dy care about soft vs hard limits?  Soft limit being "you won't be blo= cked, but you'll be told off any maybe charged more", hard limits being "yo= ur changes will be rejected"=2E  Should we have an optional second lim= it field in the spec?

=
Something of this sort was raised on mail= ing list by John van der Kamp - in fact he talked of 3 levels=2E  Perh= aps they could be something like:

warnLimit
softLimit
limit

Where obviously warnLimit and softLimit are optional (a= nd must each be lower than the next level up)=2E  This is more complex= ity, but it's optional complexity at both ends: servers don't need to set t= hem, and clients don't need to display them=2E

Resource Type= s

The IMAP quota draft defines three types of resources for= quotas, and also a registry where more can be described=2E  The initi= al types are "STORAGE" (units 1024 octets), "MESSAGE" (number of individual= emails) and "MAILBOX" (number of mailboxes)=2E  It maybe viable to us= e the same registry=2E

Of course, then you get issues like what= should you call it for Calendar or Addressbook?  Should the limits be= given DAVish names like "COLLECTION" and "RESOURCE" such that MESSAGE beco= mes "RESOURCE" and "MAILBOX" becomes "COLLECTION"? in JMAP quotas?

Also: should we do storage in bytes, or do 1024 octets for our storage = numbers in JMAP as well so they map identically to the definition in the re= gistry?

EXAMPLE:

As promised, a Quota object= for my example:

{
     "id": "2a06df0d-9865-4e74=
-a92f-74dcc814270e",
     "type": "storage",
     "used": 105645,
     "sco=
pe": "account",
     "limit": 200000,
     "description": "Personal account=
 usage",
     "name": "brong@brong=2En=
et",
     "datatypes" : [ "Mail", "Calendar", "Contact", "Todo" ],
<=
/pre>
}

And this would be disp=
layed in a a box called "Quota Use":
brong@brong=2Enet 52%

Something like that :)

=

Cheers,

Bron=2E<=
br>
--
  Bron Gondwana, CEO, Fastmail P=
ty Ltd
  brong@fastmailteam=2E=
com


____________________________=
___________________
Jmap mailing list
Jmap@ietf=
=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/jmap


<=
div id=3D"qt-sig56629417">
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam=2Ecom


_______________________________________________
Jmap mailing list
Jmap@ietf=2Eorg
http=
s://www=2Eietf=2Eorg/mailman/listinfo/jmap


--
  Bron Gon=
dwana, CEO, Fastmail Pty Ltd
  brong=
@fastmailteam=2Ecom





From nobody Fri Jan 17 00:13:29 2020
Return-Path: 
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D1C120803 for ; Fri, 17 Jan 2020 00:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.521
X-Spam-Level: 
X-Spam-Status: No, score=-1.521 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, 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 (2048-bit key) header.d=linagora.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 Ib2oCk6Tkzif for ; Fri, 17 Jan 2020 00:13:23 -0800 (PST)
Received: from outgoing.linagora.com (outgoing.linagora.com [51.75.198.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03EAB1207FC for ; Fri, 17 Jan 2020 00:13:22 -0800 (PST)
Received: from linagora.com (unknown [10.233.69.202]) by outgoing.linagora.com (Postfix) with ESMTP id 58CE63B; Fri, 17 Jan 2020 08:13:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1579248801; bh=+JsDL3PENlfgbInTiHZO8yiS1+YxqpOW577yc8TSbBI=; h=From:Reply-To:To:Subject:Date:References:From; b=h3i/WLyp1d9xfXALxr8nQe8TqvhI/Fugs0ztkoHqQYViWiF9Z1FE7u43JxKL70DvC RRVNVwM8s0NPQ5VVa3mIoUxe68EX3/tHs5gsHYU9oMdr4TU51v1LwtP3zlhKrzA4kF FbQV+hag7kd/fYxBemN/R4qHAPKAarkGoe0SucqYK0Q6bKVIZ4qyzkQqZDXQVAGqvH gsyegiESdKRYWn2H1iz+2+biZmlOBCQNu3DIwLrKUejGPQ7egT8xlBX/jGt5yTZdu/ FZik6JeQ+RJOPe3Mcl5IFLDqC608SzRG9YrSb9JUROQ6+IHJng8ApOXYoCuelFMpw2 v20jRAWNpOYnQ==
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
From: Raphael OUAZANA 
Sender: Raphael OUAZANA 
Reply-To: rouazana@linagora.com
To: "jmap@ietf.org" , Bron Gondwana 
Message-ID: 
Date: Fri, 17 Jan 2020 08:13:19 +0000
References: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com>  
Archived-At: 
Subject: Re: [Jmap] Working group last call: draft-ietf-jmap-mdn-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: Fri, 17 Jan 2020 08:13:28 -0000


Hi Bron,
What do you mean? Do you need any IPR notice from my comp=
any?
Regards,
Rapha=C3=ABl=2E
Le 17 janvier 2020 0=
5:57, de brong@fastmailteam=2Ecom
Sorry that I haven't gone ahead with this!  I=
t's on my list to write up the Shepherding document and submit it=2E

Just to confirm, can you let me know if you have any IPR to disclose =
for this document=2E

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

Bron=2E

On Tue, Dec 17, 2019, at 03:58,=
 Raphael OUAZANA wrote:
Tha=
nk you all for your remarks=2E
I uploaded a new version of the dr=
aft=2E I have taken care of all the comments that were made, thank you very=
 much for the suggestions, it was really helpful=2E
Regards,
<=
/p>
Rapha=C3=ABl=2E
Le 22 =
novembre 2019 06:19, de brong@fastmailteam=2Ecom
Raphael,

With my chair hat on - I'm happy for you to either issue dr=
afts with updates during the last call period, or wait until the end and is=
sue another draft containing all the feedback at the end of the last call p=
eriod=2E

Either way, I'm happy to submit to publication a=
fter this last call without doing another last call - so long as those who =
have given feedback during this time agree that it's been addressed in the =
final draft!

Cheers,
=

Bron=2E

On Fri, Nov 22, 2019, at 15:51, Ne=
il Jenkins wrote:
Over=
all I think this doc is good=2E A few nits:

o  forEmailId: "String" Email Id of the receiv=
ed email this MDN is
   relative to=2E

This needs to be nullable, as described in MDN/parse=2E

o  originalMessageID: "=
String|null" (server-set)

I think=
 this should be originalMessageId (lowercase d on the end) for =
consistency=2E

=

2=2E1=2E  M=
DN/set

   Standard "/set" method as described i=
n [RFC8620] where only the
=
   _create_ parameter is supported=2E

=

This is not quite right: the "accountId" and "ifInState" argumen=
ts are fine=2E I think this text should say something like:
<=
br>
Only create is supported; any attem=
pt to update/destroy MUST be rejected with a "forbidden" SetError=2E

And as a general comment, in the final =
versions of RFC8620/8621 we cleaned up the formatting so it worked better i=
n the plain text version of the RFCs; I suggest adopting the same=2E So we =
use "quote" for a property name reference (not _underscore_) and remove the=
 *asterisks* around the property names in the definitions=2E
=

Cheers,
Neil=2E
________________=
_______________________________
Jmap mailing list
Jmap@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/=
jmap


--
  Bron Gondwana, CEO, Fastmail Pty Ltd<=
br>
  brong@fastmailteam=2Ecom


_________________________________________=
______
Jmap mailing list
Jmap@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/jmap


--
&nb=
sp; Bron Gondwana, CEO, Fastmail Pty Ltd
=
  brong@fastmailteam=2Ecom





From nobody Fri Jan 17 00:18:50 2020
Return-Path: 
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E5D120803 for ; Fri, 17 Jan 2020 00:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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=atqpKYAF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ws1+oW2S
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 NT3F6Eh9Llw3 for ; Fri, 17 Jan 2020 00:18:44 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78966120273 for ; Fri, 17 Jan 2020 00:18:44 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E511F834 for ; Fri, 17 Jan 2020 03:18:43 -0500 (EST)
Received: from imap28 ([10.202.2.78]) by compute6.internal (MEProxy); Fri, 17 Jan 2020 03:18:44 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=bYAktN+ tMzZXjGjpOTpB8f+VTfX1JpAvIaYBBlAC+Z4=; b=atqpKYAF0vyaaPX+uU1pTRf mKFbX9CegZwAz/HSG6Klh/5UbH9mwyQBU4/WkP5ansZBEoMep1caL9xI9muz0FSY 0mPfD/UNvh77j0kgheVl8BdROYvT4VvdIpQvTQBAL/QAzOXC0YyfTqRQ7H5WMgHQ M8WRTwsNekDzsB9ixaqwxgY90/X9Elkb9bwJlN3VaDiu1rs/nAtkSz4C+pq8GreS JBCONfUArvSQYVYkb3lK1NyySY3lU0Oc8cl5buApdQs3DPzldXKiGSlc+s/Z1toH dugdci+Zmrve003yXVI/zaPBJF6PY8t5J0Sjbbb09MyN/m99O1KSzBU4Npvk9QQ= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bYAktN +tMzZXjGjpOTpB8f+VTfX1JpAvIaYBBlAC+Z4=; b=Ws1+oW2SZHh8J+pRBxKA5R hkTqgBtEjSt82gAUW1OiE8/+7n6hVLXfYgpDISg4nQWynN+Pp1yvRAiNB14TkqXS derCRVpvG6ZBi11QdHm0zo/TLfVDUIYrADdwwj4Yo+H0GOi2cemqhtndAmXO0aKn BV9BgACAIytUdfb6unMN+5HLdYvZWiaR4EWiHtivpH8bNXsys1hxCjhF1bErlXLk Gh1n1W4ICmBDtq84IduZuwbon0lacGfxF7bvuX8G+JRG0XH/UnP+iJmrG7pbuIoc 6FNTT7bN/Yn2Rg0ytaHq4puaIAAoU6YwMzKcFbBRyAWxUf4nZWoY8zmiiPQfGihQ ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdeigdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgpd hivghtfhdrrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id F14EC24009E; Fri, 17 Jan 2020 03:18:42 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1
Mime-Version: 1.0
Message-Id: <9170aa7e-44ff-4cfa-866b-e4ccfb141521@dogfood.fastmail.com>
In-Reply-To: 
References: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com>   
Date: Fri, 17 Jan 2020 19:18:22 +1100
From: "Bron Gondwana" 
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=ebf8c06b36be418b97545a568f2cc8c2
Archived-At: 
Subject: Re: [Jmap] Working group last call: draft-ietf-jmap-mdn-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: Fri, 17 Jan 2020 08:18:49 -0000

--ebf8c06b36be418b97545a568f2cc8c2
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

If there was IPR, I would hope you'd already filed an IPR notice by now!=
 If there's no IPR covering the material in this document, all I need is=
 your statement to that effect.

Cheers,

Bron.

On Fri, Jan 17, 2020, at 19:13, Raphael OUAZANA wrote:
> Hi Bron,

> What do you mean? Do you need any IPR notice from my company?

> Regards,

> Rapha=C3=ABl.

> Le 17 janvier 2020 05:57, de brong@fastmailteam.com
>> Sorry that I haven't gone ahead with this! It's on my list to write u=
p the Shepherding document and submit it.
>>=20
>> Just to confirm, can you let me know if you have any IPR to disclose =
for this document.
>>=20
>> Thanks,
>>=20
>> Bron.
>>=20
>> On Tue, Dec 17, 2019, at 03:58, Raphael OUAZANA wrote:
>>> Thank you all for your remarks.

>>> I uploaded a new version of the draft. I have taken care of all the =
comments that were made, thank you very much for the suggestions, it was=
 really helpful.

>>> Regards,

>>> Rapha=C3=ABl.

>>> Le 22 novembre 2019 06:19, de brong@fastmailteam.com
>>>> Raphael,
>>>>=20
>>>> With my chair hat on - I'm happy for you to either issue drafts wit=
h updates during the last call period, or wait until the end and issue a=
nother draft containing all the feedback at the end of the last call per=
iod.
>>>>=20
>>>> Either way, I'm happy to submit to publication after this last call=
 without doing another last call - so long as those who have given feedb=
ack during this time agree that it's been addressed in the final draft!
>>>>=20
>>>> Cheers,
>>>>=20
>>>> Bron.
>>>>=20
>>>> On Fri, Nov 22, 2019, at 15:51, Neil Jenkins wrote:
>>>>> Overall I think this doc is good. A few nits:
>>>>>=20
>>>>>> o  forEmailId: "String" Email Id of the received email this MDN i=
s
   relative to.
>>>>>=20
>>>>> This needs to be nullable, as described in MDN/parse.
>>>>>=20
>>>>>> o  originalMessageID: "String|null" (server-set)
>>>>>=20
>>>>> I think this should be *originalMessageId* (lowercase d on the end=
) for consistency.
>>>>>=20
>>>>>> 2.1 .  MDN/set

>>>>>>=20
   Standard "/set" method as described in [RFC8620 ] where only the
   _create_ parameter is supported.
>>>>>=20
>>>>> This is not quite right: the "accountId" and "ifInState" arguments=
 are fine. I think this text should say something like:
>>>>>=20
>>>>>> Only create is supported; any attempt to update/destroy MUST be r=
ejected with a "forbidden" SetError.
>>>>>=20
>>>>> And as a general comment, in the final versions of RFC8620/8621 we=
 cleaned up the formatting so it worked better in the plain text version=
 of the RFCs; I suggest adopting the same. So we use "quote" for a prope=
rty name reference (not _underscore_) and remove the *asterisks* around =
the property names in the definitions.
>>>>>=20
>>>>> Cheers,
>>>>> Neil.
>>>>> _______________________________________________
>>>>> Jmap mailing list
>>>>> Jmap@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/jmap
>>>>>=20
>>>>=20
>>>> --
>>>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>>>  brong@fastmailteam.com
>>>>=20
>>>>=20
>>> _______________________________________________
>>> Jmap mailing list
>>> Jmap@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jmap
>>>=20
>>=20
>> --
>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>  brong@fastmailteam.com
>>=20
>>=20
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap
>=20

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


--ebf8c06b36be418b97545a568f2cc8c2
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable


If there was IPR, I would hope you'd already filed an=
 IPR notice by now!  If there's no IPR covering the material in thi=
s document, all I need is your statement to that effect.

Cheers,

Bron.

On Fri, Jan 17, 2020, at 19:13, Raphael OUAZANA wrote:
Hi Bron,
What do you mean? D=
o you need any IPR notice from my company?
Regards,
=
Rapha=C3=ABl.
Le 17 janvi=
er 2020 05:57, de brong@fastmailteam.com
Sorry that I haven't gone ahead with this=
!  It's on my list to write up the Shepherding document and submit =
it.

Just to confirm, can you let me know if you have any =
IPR to disclose for this document.

Thanks,

Bron.

On Tue,=
 Dec 17, 2019, at 03:58, Raphael OUAZANA wrote:
Thank you all for your remarks.
I upl=
oaded a new version of the draft. I have taken care of all the comments =
that were made, thank you very much for the suggestions, it was really h=
elpful.
Regards,
Rapha=C3=ABl.
Le 22 novembre 2019 06:19, de brong@fastmailte=
am.com
Rap=
hael,

With my chair hat=
 on - I'm happy for you to either issue drafts with updates during the l=
ast call period, or wait until the end and issue another draft containin=
g all the feedback at the end of the last call period.

Either way, I'm happy to submit to publication after this last call =
without doing another last call - so long as those who have given feedba=
ck during this time agree that it's been addressed in the final draft!

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

<=
/div>
Bron.

On Fri, Nov 22, 2019, at 15:51, Neil=
 Jenkins wrote:
=
Overall I think this doc is good. A few nits:

o  forEmailId: "String=
" Email Id of the received email this MDN is
   relative to.

This needs to =
be nullable, as described in MDN/parse.

o  originalMessageID: "=
String|null" (server-set)

I th=
ink this should be originalMessageId (lowercase d on the end=
) for consistency.

2.1.  MDN/set

   Standard "/set" method as described in [RFC8620] where only the
   _create_ parameter is supported.
This is not quite right: the "accountId" and "ifInState" arg= uments are fine. I think this text should say something like:
<= div>
Only create is supported; a= ny attempt to update/destroy MUST be rejected with a "forbidden" SetErro= r.

And as a general comment, i= n the final versions of RFC8620/8621 we cleaned up the formatting so it = worked better in the plain text version of the RFCs; I suggest adopting = the same. So we use "quote" for a property name reference (not _undersco= re_) and remove the *asterisks* around the property names in the definit= ions.

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


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


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


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

=

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


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


--ebf8c06b36be418b97545a568f2cc8c2-- From nobody Fri Jan 17 00:58:27 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F93E120273 for ; Fri, 17 Jan 2020 00:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, 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 (2048-bit key) header.d=linagora.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 pradW5SUjJYD for ; Fri, 17 Jan 2020 00:58:21 -0800 (PST) Received: from outgoing.linagora.com (outgoing.linagora.com [51.75.198.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0497120236 for ; Fri, 17 Jan 2020 00:58:21 -0800 (PST) Received: from linagora.com (unknown [10.233.69.202]) by outgoing.linagora.com (Postfix) with ESMTP id A77623B; Fri, 17 Jan 2020 08:58:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1579251499; bh=Q8m+sY2mbbVdUYybUHZWBwIF0MD04PKUIeAsdvpqe9k=; h=From:Reply-To:To:Subject:Date:References:From; b=NS7slc5xUqntXKRcKXjtvCCaACHk1ljVDuVX1jrOMKEcXD8Ut55T2N7pLu4CJZlN2 D21gv2RxjgvrCWrYBvM4Nw+cDo70C4Um7TVAzemj+lkoAgPWpL9oMom1JcyCDVa8Kx KlmngKhECvW+8MFCmqrIQxk+rR/16Ud+QKy0uv3yHwkA3SpYTPMhpw5rs83mxfgsYQ PFPmKZ3pUd+HN+HzlcWg66yyAOKUJMAyq8HnncOU5nzVyVQHrkVL+cqV3fo0wmKrIr gEERObsU3GzpdfPPR9kOk/I401gt9w2SrmHCT0+zGowyDm7F0n9CAaPGWZFY0R+oxh aN7kpzpM9PYZQ== MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Raphael OUAZANA Sender: Raphael OUAZANA Reply-To: rouazana@linagora.com To: "jmap@ietf.org" , Bron Gondwana Message-ID: Date: Fri, 17 Jan 2020 08:58:17 +0000 References: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com> Archived-At: Subject: Re: [Jmap] Working group last call: draft-ietf-jmap-mdn-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: Fri, 17 Jan 2020 08:58:26 -0000

No, there is no IPR covering the material in this document=2E

Raph= a=C3=ABl=2E

Le 17 janvier 2020 09:18, de brong@fastmailteam=2E= com
If th= ere was IPR, I would hope you'd already filed an IPR notice by now!  I= f there's no IPR covering the material in this document, all I need is your= statement to that effect=2E
Cheers,

Bron=2E

On Fri, Jan 17, 2020, at 19:13, = Raphael OUAZANA wrote:

Hi B= ron,

What do you mean? Do you need any IPR notice from my company= ?

Regards,

Rapha=C3=ABl=2E

Le 17 janvier 2020 05:57, de brong@fastmailteam=2Ecom
Sorry that I ha= ven't gone ahead with this!  It's on my list to write up the Shepherdi= ng document and submit it=2E
Just to confirm, can you let me kn= ow if you have any IPR to disclose for this document=2E

Thanks,=

Bron=2E

<= div>On Tue, Dec 17, 2019, at 03:58, Raphael OUAZANA wrote:

Thank you all for your remarks=2E

I uploaded a new version of the draft=2E I have taken care of all the c= omments that were made, thank you very much for the suggestions, it was rea= lly helpful=2E

Regards,

Rapha=C3=ABl=2E

Le 22 novembre 2019 06:19, de brong@fastmai= lteam=2Ecom
R= aphael,

With my chair hat on = - I'm happy for you to either issue drafts with updates during the last cal= l period, or wait until the end and issue another draft containing all the = feedback at the end of the last call period=2E

Either way= , I'm happy to submit to publication after this last call without doing ano= ther last call - so long as those who have given feedback during this time = agree that it's been addressed in the final draft!

Cheers,

Bron=2E

On Fri, Nov 22, 2019, at 15:51, Neil Jenkins wrote:
Overall I think this doc is good=2E = A few nits:

=
o  forEmailId: "String" Email Id of the received email this MDN is
   relat=
ive to=2E

This needs to be nullab= le, as described in MDN/parse=2E

o  originalMessageID: "String|null" (server-set)<=
br>

I think this should be origina= lMessageId (lowercase d on the end) for consistency=2E

=

2=2E1=2E  MDN/set

   Standard "/set" method as described in [RFC8620] where only the
   _create_ paramete=
r is supported=2E

This is n= ot quite right: the "accountId" and "ifInState" arguments are fine=2E I thi= nk this text should say something like:

Only create is supported; any attempt to update/destroy= MUST be rejected with a "forbidden" SetError=2E

And as a general comment, in the final versions of RFC8620/= 8621 we cleaned up the formatting so it worked better in the plain text ver= sion of the RFCs; I suggest adopting the same=2E So we use "quote" for a pr= operty name reference (not _underscore_) and remove the *asterisks* around = the property names in the definitions=2E

Cheer= s,
Neil=2E
____________________________________= ___________
Jmap mailing list
Jmap@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/jmap
<= br>

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
=
  brong@fastmailteam=2Ecom


____________________________________________= ___
Jmap mailing list
Jmap@ietf=2Eorg
=
https://www=2E=2Eietf=2Eorg/mailman/listinfo/jmap


--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam=2Ecom


_______________________________________________
Jmap= mailing list
Jmap@ietf=2Eorg
https://www=2Eiet= f=2Eorg/mailman/listinfo/jmap


--
  Bron Gondwana, CEO, F= astmail Pty Ltd
  brong@fastmailteam= =2Ecom


From nobody Sun Jan 19 16:29:08 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E77BA120052; Sun, 19 Jan 2020 16:29:06 -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: fenton@bluepopcorn.net, jmap@ietf.org, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157948014688.19749.13385475536506768389.idtracker@ietfa.amsl.com> Date: Sun, 19 Jan 2020 16:29:06 -0800 Archived-At: Subject: [Jmap] jmap - New Meeting Session Request for IETF 107 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, 20 Jan 2020 00:29:07 -0000 A new meeting session request has just been submitted by Jim Fenton, a Chair of the jmap working group. --------------------------------------------------------- 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): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: doh oauth saag iasa2 dmarc artarea uta dispatch extra calext Technology Overlap: tls httpbis ace lamps core t2trg People who must be present: Alexey Melnikov Jim Fenton Neil Jenkins Bron Gondwana Resources Requested: Special Requests: One co-chair is unavailable Thursday PM and Friday, so please avoid those times if possible. Many of the same people attend both JMAP and EXTRA, so please see if they can be placed consecutively. --------------------------------------------------------- From nobody Mon Jan 20 12:02:26 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32307120274; Mon, 20 Jan 2020 12:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=W99jclG7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yFTwaGkv 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 b7fwFkPD6fOR; Mon, 20 Jan 2020 12:02:13 -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 9075F120020; Mon, 20 Jan 2020 12:02:13 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id BD18421F30; Mon, 20 Jan 2020 15:02:12 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 20 Jan 2020 15:02:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=X 9nEWYCycBdKORRDFwaWaPC1xLwi6iXzNzuSDGwAl0k=; b=W99jclG7uhqLHc88C 2Vmzw5+Y9VZI0xN6gn3GQyF7UnzBuFSEvjQpd1VIGfw+VLSSbEYs43rnDsqCcJJN QYJrd8deNdFH94KWL+AzLQrFEN0AvWuSIPunzhSKv0F3ImC4c8A6kCAyEY2UM7Kd Tx5/ohaIybxdlIsQr+nL1dkYr/tTcCmCyRSAIf2uSgyiACG9mkJTsAzxegDA8aP+ 6pCmM6Wk5EaZa0XU+Je/xWq4OtAVzShAiyjXqm41kdwd5DXcbeWRst4XZInU80fC ymlUy3Hy/oByLO3i8bOY9TP+tl3nZ5OMjQHkJ9J/frPUXiFG1/JA+PQldpmACsCa TzMEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=X9nEWYCycBdKORRDFwaWaPC1xLwi6iXzNzuSDGwAl 0k=; b=yFTwaGkvf9n0ZhscBiKWK+87iPLQbpXtjybZzGwnbBPftKT8fpPck2lAF W31cj8eNKSVhVzyykdpzApnLkDBFfMQlF+VaQ0EKwsVpP0gTB73ELqAVxok14LIr GK5/nlpDEl6QMXcHx90ZEi9Xyke6ecCUfZkkUCySmBzl0q12Q4BbUlSjKnqQBHFA 79rT7NyxESW/qmAndCqSl1WEVZaw5eXc/OG8h+bH5fSjB+HDk4rkvlpO7IBtQmio KH73AaIS95YVxxngOCEVylD7jSIJHH1YVRnt9TX00Xoke2up5Z7ZsqeckKPPZcyp JSh2neNXlHxmPZoOuasrBs0f57WWQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeigdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghnucfo uhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucfkphepje egrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id DFE04306098C; Mon, 20 Jan 2020 15:02:11 -0500 (EST) To: Benjamin Kaduk , The IESG Cc: draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, jmap@ietf.org References: <157843131129.21019.4453575321747210277.idtracker@ietfa.amsl.com> From: Ken Murchison Message-ID: Date: Mon, 20 Jan 2020 15:02:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: <157843131129.21019.4453575321747210277.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-websocket-04: (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: Mon, 20 Jan 2020 20:02:20 -0000 Hi Benjamin, Thank you very much for the detailed review.  I believe that I have addressed all of your points in my forthcoming draft, except the one below. On 1/7/20 4:08 PM, Benjamin Kaduk via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The discussion of compression bears some closer scrutiny, as if we allow > the entire websocket frame to be part of the compression state, > then there may be more avenues for an attacker to inject content into > the same compression state as data that we want to keep somewhat > confidential. (This is not as bad as, say, the initial CRIME attack > impact, as the authentication credentials are not being repeatedly sent, > but the general principle of mixing attacker-controlled and confidential > data into the same compression domain is the same.) > > We could say something in the security considerations about the > potential consequences for a client that sends multiple requests in > parallel without request IDs and gets back responses in a different > order. (Or just require unique request IDs, I suppose.) Can you expand on this?  I'm not sure I fully understand the exploit or the way(s) to mitigate it. -- Kenneth Murchison Cyrus Development Team FastMail US LLC From nobody Wed Jan 22 19:36:13 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6294F120018; Wed, 22 Jan 2020 19:36:12 -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.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157975057236.12283.12602452699119577909.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2020 19:36:12 -0800 Archived-At: Subject: [Jmap] jmap - Update to a Meeting Session Request for IETF 107 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, 23 Jan 2020 03:36:12 -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: Chair Conflict: doh oauth saag iasa2 dmarc artarea uta dispatch extra calext Technology Overlap: tls httpbis ace lamps core t2trg txauth People who must be present: Alexey Melnikov Jim Fenton Bron Gondwana Resources Requested: Special Requests: One co-chair is unavailable Thursday PM and Friday, so please avoid those times if possible. Many of the same people attend both JMAP and EXTRA, so please see if they can be placed consecutively. --------------------------------------------------------- From nobody Fri Jan 24 05:16:56 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE3120044 for ; Fri, 24 Jan 2020 05:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtthgn.com header.b=Ml0mjlY3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ssagXgpI 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 AWWkqjmJC6dD for ; Fri, 24 Jan 2020 05:16:53 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BD912003E for ; Fri, 24 Jan 2020 05:16:52 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2F37175C for ; Fri, 24 Jan 2020 08:16:52 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute4.internal (MEProxy); Fri, 24 Jan 2020 08:16:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtthgn.com; h= mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=vSeoIWMX5W2748vJK/OHR5PP8Irf45HCcLmaRrfN1L8=; b=Ml0mjlY3 kVRr6YW5TCxUcreDGEE+h/n0UuXR7K+LgsN91hvxAR1Yll3q5INLoqo6zO4/ptRv jUcjbHOA4MfGr/xwJFfyT6ZBfHA5OiiV5X9Z5PTzukf+7Bid5pk3vjCjxvwTdRny 1806B2njgOjsbAFjsqmVhLME9VHl4aMtAtCBXnVHUWZd/3eLVLF919y9BI907IYU wxGIsrnXaBEaBYyOmNzsJoMDRSzgwqVy7Po1tjH8gHAYd9FqQFyKMir7zPQ1U6Ki weZM3hBlZZ3XEE6bXBFbAa1ZZO7mjTlEn94IliUpta0qTEMR7wcgmm3tXOAdVHTe mvV1/6zeU1Ba+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=vSeoIWMX5W2748vJK/OHR5PP8Irf4 5HCcLmaRrfN1L8=; b=ssagXgpIICeW366Zt9+CqgXFxBK8i7B8c2WVBpOo5odql ESX9lF08fVUeBiTQSQPX1oWGvmgSfZxP+iLjojuRlROEMS4qnHBgjtIEPiUQbEQI GXlzbdtwMaiaxwAMAoTVAzYB8jHAVHXkr4eVGabvJyNEkrS99kzU8eoPIiYwHS5S WSDrYdKXQdR/Nn8R95B+2HAnyzJw1xfjjgg1fmA4VDl61PtLvP3cZEffwqnTSC1j flYcXxNnaf31bAPf2Y4+F1j3z+v4etijHHUO0f8WxQRJSr+65bLs/PZ5BwKaCh+f w+5uiM56BEY4qtzHFjzy1uGZbArYUB0TEE2VhDoQA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvdeggdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdforghtthcujfhoghgrnhdfuceomhgrthhtsehmthhthhhgnhdr tghomheqnecuffhomhgrihhnpegvgigrmhhplhgvuddrtghomhdphhhtthhpshgtrhgrmh hrfhgtjeektdegvgigrghmphhlvgdvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepmhgrthhtsehmthhthhhgnhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 51A34C200A4; Fri, 24 Jan 2020 08:16:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-777-gdb93371-fmstable-20200123v1 Mime-Version: 1.0 Message-Id: <3cd1b3b0-4dd1-4f35-8565-b91a4269bcb8@www.fastmail.com> Date: Fri, 24 Jan 2020 07:16:31 -0600 From: "Matt Hogan" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=be2e147c1aa7415baa084610dd1130e6 Archived-At: Subject: [Jmap] Question about authentication discovery 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, 24 Jan 2020 13:16:54 -0000 --be2e147c1aa7415baa084610dd1130e6 Content-Type: text/plain Hi everyone, I've been following along with the JMAP RFC for a while now, and I'm really excited about it! I have a question about authentication, specifically around how a JMAP client would know which authentication strategy to use for a given domain. Imagine the following JMAP servers: * example1.com, authenticates via HTTP SCRAM (RFC 7804) * example2.com, authenticates via HOBA( RFC 7486) If I want a JMAP client to work with any JMAP server, the client will need to know the form of authentication *before* it can successfully request a session. Are there currently any mechanisms for a client to discover this information, similar to how it can discover the URI for the session endpoint? Is the expectation that a user will have to specify to the client the authentication method and authentication URI? -- Matt --be2e147c1aa7415baa084610dd1130e6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi everyon= e,

I've been following along with the JMAP = RFC for a while now, and I'm really excited about it! I have a question = about authentication, specifically around how a JMAP client would know w= hich authentication strategy to use for a given domain.
Imagine the following JMAP servers:
  • examp= le1.com, authenticates via HTTP SCRAM (RFC 7804)
  • example2.c= om, authenticates via HOBA( RFC 7486)

<= /div>
If I want a JMAP client to work with any JMAP server, the clie= nt will need to know the form of authentication before it can suc= cessfully request a session.

Are there cur= rently any mechanisms for a client to discover this information, similar= to how it can discover the URI for the session endpoint? Is the expecta= tion that a user will have to specify to the client the authentication m= ethod and authentication URI?

-- Matt

--be2e147c1aa7415baa084610dd1130e6-- From nobody Tue Jan 28 21:53:31 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2406A12016E for ; Tue, 28 Jan 2020 21:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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=AIM3jWOa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aFx8Mg+1 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 l0YOHy6CCJmT for ; Tue, 28 Jan 2020 21:53:27 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FE812009C for ; Tue, 28 Jan 2020 21:53:27 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 6F2B2568; Wed, 29 Jan 2020 00:53:24 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute2.internal (MEProxy); Wed, 29 Jan 2020 00:53:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=bNMG U1ImxW/60LsPF6XbiDI1aJZop/fpMWkhylv62Bw=; b=AIM3jWOaMJflb82Q1wo6 gqonEkTwvnwdhK9PjAG5Mn/ymwG/eylYsGJK1+pXHh6mj0kbk+GJmiSC2LNEliVe 5Oq3VI8EVnmbIwka56XNdeDVHM9AjGihHo8XWjZSA+WHIOTLMZeEBSpofYB56ZCF 2UdG9E4fKiEW1QbBSfNanabRAsTVCM894jDba8tR9B56vqp8epdCadiWN4DgCGRl NEqeWsae0Eu7FRw4SuT2PUKkuGHWuLbdukk0axkNWWqs1rSbCt5rSsu/i6W5oqfx noi4Y7kexUU31xo3Nj+CAjtjsYrDcVP4A/pHOchSrLpPMdknpXRmnvm19dLQDGJE +A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=bNMGU1 ImxW/60LsPF6XbiDI1aJZop/fpMWkhylv62Bw=; b=aFx8Mg+1XPO9lGLiurMMel n+d75hOCH1PsBvXdTkI5UCf4V1uciRwNH4IiAyWZDIWLFHVoero0rHehEWi3gLQ8 wQtulIehGtBFda4DqS3rIrpgwJ89+Kwc/vnRUJ5TGiJkV58q7WS9Um3aGNVb4cqu NrrWEsFTUpc7p0qNIVyN6nb1Q3KacbCT4ez3UATF1PzS7lkSTktwSmi/kef8oUlf h5+PuieK6NNIHTv/lDTpjwEb/Y8ZsE6P6sHssTwm5PC5dLnM6jmxR2+34rC4PWQ7 30gl1eaeRlviTbEAaNdF5+ty7x833udPL1wvHd0GwT8Fk2De8oyuRGpi1kOvH41g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrfeehgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 66DEA24009E; Wed, 29 Jan 2020 00:53:23 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-850-ga703523-fmnext-20200128v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1776898c-03ee-4d34-b254-a9c638dd3741@dogfood.fastmail.com> Date: Wed, 29 Jan 2020 16:53:03 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: "Raphael OUAZANA" Content-Type: multipart/alternative; boundary=9e354566f38f48f48f9f62599085dbcd Archived-At: Subject: Re: [Jmap] Working group last call: draft-ietf-jmap-mdn-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: Wed, 29 Jan 2020 05:53:30 -0000 --9e354566f38f48f48f9f62599085dbcd Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Raphael, Sorry for the delay. I've finally actually read the -04 and I have more = comments that I'd like to resolve before submitting. I'll write a separa= te email with that. Bron. On Fri, Jan 17, 2020, at 15:57, Bron Gondwana wrote: > Sorry that I haven't gone ahead with this! It's on my list to write up= the Shepherding document and submit it. >=20 > Just to confirm, can you let me know if you have any IPR to disclose f= or this document. >=20 > Thanks, >=20 > Bron. >=20 > On Tue, Dec 17, 2019, at 03:58, Raphael OUAZANA wrote: >> Thank you all for your remarks. >> I uploaded a new version of the draft. I have taken care of all the c= omments that were made, thank you very much for the suggestions, it was = really helpful. >> Regards, >> Rapha=C3=ABl. >> Le 22 novembre 2019 06:19, de brong@fastmailteam.com >>> Raphael, >>>=20 >>> With my chair hat on - I'm happy for you to either issue drafts with= updates during the last call period, or wait until the end and issue an= other draft containing all the feedback at the end of the last call peri= od. >>>=20 >>> Either way, I'm happy to submit to publication after this last call = without doing another last call - so long as those who have given feedba= ck during this time agree that it's been addressed in the final draft! >>>=20 >>> Cheers, >>>=20 >>> Bron. >>>=20 >>> On Fri, Nov 22, 2019, at 15:51, Neil Jenkins wrote: >>>> Overall I think this doc is good. A few nits: >>>>=20 >>>>> o forEmailId: "String" Email Id of the received email this MDN is= relative to. >>>>=20 >>>> This needs to be nullable, as described in MDN/parse. >>>>=20 >>>>> o originalMessageID: "String|null" (server-set) >>>>=20 >>>> I think this should be *originalMessageId* (lowercase d on the end)= for consistency. >>>>=20 >>>>> 2.1 . MDN/set >>>>>=20 Standard "/set" method as described in [RFC8620 ] where only the _create_ parameter is supported. >>>>=20 >>>> This is not quite right: the "accountId" and "ifInState" arguments = are fine. I think this text should say something like: >>>>=20 >>>>> Only create is supported; any attempt to update/destroy MUST be re= jected with a "forbidden" SetError. >>>>=20 >>>> And as a general comment, in the final versions of RFC8620/8621 we = cleaned up the formatting so it worked better in the plain text version = of the RFCs; I suggest adopting the same. So we use "quote" for a proper= ty name reference (not _underscore_) and remove the *asterisks* around t= he property names in the definitions. >>>>=20 >>>> Cheers, >>>> Neil. >>>> _______________________________________________ >>>> Jmap mailing list >>>> Jmap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jmap >>>>=20 >>>=20 >>> -- >>> Bron Gondwana, CEO, Fastmail Pty Ltd >>> brong@fastmailteam.com >>>=20 >>>=20 >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap >>=20 >=20 > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com >=20 >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --9e354566f38f48f48f9f62599085dbcd Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Raphael,

Sorry for the delay. = I've finally actually read the -04 and I have more comments that I'd li= ke to resolve before submitting.  I'll write a separate email with = that.

Bron.

On Fri, Jan 17, 2020, at 15= :57, Bron Gondwana wrote:
<= div style=3D"font-family:Arial;">Sorry that I haven't gone ahead with th= is!  It's on my list to write up the Shepherding document and submi= t it.

Just to confirm, can you let me know if you have an= y IPR to disclose for this document.

Thanks,

Bron.

On Tu= e, Dec 17, 2019, at 03:58, Raphael OUAZANA wrote:

Thank you all for your remarks.

I= uploaded a new version of the draft. I have taken care of all the comme= nts that were made, thank you very much for the suggestions, it was real= ly helpful.

Regards,

Rapha=C3=ABl.

Le 22 novembre 2019 06:19, de brong@fastma= ilteam.com
Raphael,

With my chair= hat on - I'm happy for you to either issue drafts with updates during t= he last call period, or wait until the end and issue another draft conta= ining all the feedback at the end of the last call period.

Either way, I'm happy to submit to publication after this last c= all without doing another last call - so long as those who have given fe= edback during this time agree that it's been addressed in the final draf= t!

Cheers,
<= br>
Bron.

On Fri, Nov 22, 2019, at 15:51,= Neil Jenkins wrote:
=
Overall I think this doc is good. A few nits:

o  forEmailId: "S=
tring" Email Id of the received email this MDN is
   relative to.

This needs to = be nullable, as described in MDN/parse.

o  originalMessageID: "=
String|null" (server-set)

I th= ink this should be originalMessageId (lowercase d on the end= ) for consistency.

2.1. MDN/set

Standard "/set" method as described in [RFC8620] where only the _create_ parameter is supported.
This is not quite right: the "accountId" and "ifInState" arg= uments are fine. I think this text should say something like:
<= div>
Only create is supported; a= ny attempt to update/destroy MUST be rejected with a "forbidden" SetErro= r.

And as a general comment, i= n the final versions of RFC8620/8621 we cleaned up the formatting so it = worked better in the plain text version of the RFCs; I suggest adopting = the same. So we use "quote" for a property name reference (not _undersco= re_) and remove the *asterisks* around the property names in the definit= ions.

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


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


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


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

=

___________= ____________________________________
Jmap mailing list
=
Jmap@ietf.org
https://www.ietf.org/mailman/list= info/jmap


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


--9e354566f38f48f48f9f62599085dbcd-- From nobody Tue Jan 28 22:22:10 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B84A120130 for ; Tue, 28 Jan 2020 22:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, 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=XXtMSZIf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LpYqYSbR 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 qNaij58y4Jud for ; Tue, 28 Jan 2020 22:22:07 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7EA11200EF for ; Tue, 28 Jan 2020 22:22:07 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 1F7D554F; Wed, 29 Jan 2020 01:22:07 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute2.internal (MEProxy); Wed, 29 Jan 2020 01:22:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm1; bh=nOArtT4yo3ZxoTtZPQPRDORcHOjtsem Iv7xBtea9jmU=; b=XXtMSZIfyxczHu2hUygRwsWlVup71KyKR3KRGwpwJXRSFOj V6Uzd9fKL1Rv8W5awrPVIycJ/PCAEEqrFA5fhfS14Vd+uwqkFmhRRvtKltIzbVSU Fyd8Oda6uRQE7rGkBgzd46xinQpx3tvKhACTPGsgsg8MhdA3gK+as1mOCN4erTUi dYCcJW+AQIn00HjFNyydR9S9Cl0zRneMy0Y3ZkYg6gBcJcRLa5vfiYpY/VyL/qSJ EXTGb2jYKb+1tg4YlJf/lIoiyzIVNmQw5CPK7khWDJEZnGczeIgDC8HYSuFAWMz4 tCHyointa+CHkl6y2CmlcIxPaKLMV6KIGsapx4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=nOArtT4yo3ZxoTtZPQPRDORcHOjts emIv7xBtea9jmU=; b=LpYqYSbRXPOBngP/HxJfRrLP2u19vxdllYZ/gtQusoXHs +gDC8Z3C5i54kRol46KeZIL9c6MylFBpKoLq6opsDAAW3SuLGbU+z/79pPMORE0f o3CkfsB/D/DJum3Tj774y18dkkMpsehvwCBW1KsObUsnUIzDLMSyIMRiLo1ImB4D CQP1gQ56CV0aBWf/5Eogr0EwhB4U8K+wuxkMgh6xWebP6TcvgUgX12lDGxusBypF dBAN7hI1liz+Xm6eitdEtGE+yKUJpIoHlHsKyOWJNPGjkF9zEr3sTmnqKjiayK9R DZm8dexuNIMhLlgQ/hhYx1ToLKRKUMwA5DmTGQgsA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrfeehgdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhnucfi ohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenuc ffohhmrghinheplhhinhgrghhorhgrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrd gtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E3CFC24009E; Wed, 29 Jan 2020 01:22:05 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-850-ga703523-fmnext-20200128v1 Mime-Version: 1.0 Message-Id: <644c56e0-9949-41c1-bed0-621142859788@beta.fastmail.com> Date: Wed, 29 Jan 2020 17:21:45 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: "Raphael OUAZANA" Content-Type: multipart/alternative; boundary=7bc32331057b470491f86f77973366fc Archived-At: Subject: [Jmap] Review: draft-ietf-jmap-mdn-04 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, 29 Jan 2020 06:22:09 -0000 --7bc32331057b470491f86f77973366fc Content-Type: text/plain As promised, a review of the current draft. *2.1 MDN/set* Looking at this some more, it doesn't make sense to call this method /set - it doesn't work the same way as regular set commands. It doesn't create an object which can later be fetched, or return an id. It would be better to rename this so it doesn't create confusion. I suggest something like: [[ "MDN/generate", { "accountId": "ue150411c", "for": { "Md45b47b4877521042cec0938": { "subject": "Read receipt for: World domination", "textBody": "This receipt shows that the email has been displayed on your recipient's computer. There is no guaranty it has been read or understood.", "reportingUA": "linagora.com; OpenPaaS", "disposition": { "actionMode": "manual-action", "sendingMode": "MDN-sent-manually", "type": "displayed" } } } }, "R1" ]] Response: [[ "MDN/generate", { "accountId": "ue150411c", "generated": { "Md45b47b4877521042cec0938": { "finalRecipient": "rfc822; john@example.com", "originalMessageId": "<1521557867.2614.0.camel@apache.org>" } } }, "R1" ], [ "Email/set", { "updated" : [ "Md45b47b4877521042cec0938" ], ... }, "R1" ]] and of course: there's also "notGenerated" : { "emailId" : { ErrorObject }} with probably a specific error code for mdnAlreadySent. [[ "MDN/generate", { "accountId": "ue150411c", "for": { "Md45b47b4877521042cec0938": { "subject": "Read receipt for: World domination", "textBody": "This receipt shows that the email has been displayed on your recipient's computer. There is no guaranty it has been read or understood.", "reportingUA": "linagora.com; OpenPaaS", "disposition": { "actionMode": "manual-action", "sendingMode": "MDN-sent-manually", "type": "displayed" } } } }, "R2" ]] Response: [[ "MDN/generate", { "accountId": "ue150411c", "notGenerated": { "Md45b47b4877521042cec0938": { "type": "mdnAlreadySent", "description" : "$MDNSent keyword is already present" } } }, "R2" ], The emailId makes sense as the key for the object, since it's only legal to do one per email. *NOTE: *I didn't mention oldState and newState here. There's not much point, because the MDN itself doesn't have state. The Email/set response should have state, because email objects have state, but it doesn't make sense to have state for MDN objects, because you can't query or fetch them.* * *3.1. Sending an MDN for a received email * The first example needs to show the Email/set response with the same method call id. There should also be an example (as above) for the error case. *3.2. Asking for MDN * "header:Disposition-Notification-To": "joe@example.com", This doesn't do quite what you expect - default is "asRaw", which doesn't add a leading space. You probably want. "header:Disposition-Notification-To:asText": "joe@example.com", *3.3 Parsing a received MDN* Likewise, this should have an example of what to do when it's called on a blob which doesn't parse as a MDN, or what happens when the blob doesn't exist. *General Comments** * Ideally each method should mention what kinds of errors are likely to be created, e.g this kind of thing from RFC8620. The following SetError types are defined and may be returned for set operations on any record type where appropriate: o "forbidden": The action would violate an ACL or other permissions policy. o "overQuota": The create would exceed a server- defined limit on the number or total size of objects of this type. o "tooLarge": The create would result in an object that exceeds a server-defined limit for the maximum size of a single object of this type. o "rateLimit": Too many objects of this type have been created recently, and a server-defined rate limit has been reached. It may work if tried again later. o "notFound": The id given cannot be found. Obviously, these need to be chosen from the existing error registry, or the IANA section should include registration for any newly added errors. I expect security review might ask you to expand a little on the security considerations as well. Cheers, Bron. * * -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --7bc32331057b470491f86f77973366fc Content-Type: text/html Content-Transfer-Encoding: quoted-printable
As promised, a review of the current draft.

2.1 MDN/set

Looking at this some more, it doesn't= make sense to call this method /set - it doesn't work the same way as r= egular set commands.  It doesn't create an object which can later b= e fetched, or return an id.  It would be better to rename this so i= t doesn't create confusion.
<= br>
I suggest something like:
= 

       [[ "MDN/ge=
nerate", {
         "accountId": "ue150411c",
         "for": {
           "Md45b47b4877521042cec0938": {
             "subject": "Read receipt for: World domination",
             "textBody": "This receipt shows that the email has been
                 displayed on your recipient's computer. There is no
                 guaranty it has been read or understood.",
             "reportingUA": "linagora.com; OpenPaaS",
             "disposition": {
               "actionMode": "manual-action",
               "sendingMode": "MDN-sent-manually",
               "type": "displayed"
             }
           }
         }
       }, "R1" ]]

Response:

=
     [[ "MDN/generate", {
       "accountId": "ue150411c",
       "generated": {
         "Md45b47b4877521042cec0938": {
           "finalRecipient": "rfc822; john@example.com",
           "originalMessageId": "<1521557867.2614.0.camel@apache.org>"
         }
       }
     }, "R1" ],
     [ "Email/set", {
       "updated" : [ "Md45b47b4877521042cec0938" ],
       ...=20
     }, "R1" ]]


and of course: = there's also "notGenerated" : { "emailId" : { ErrorObject }} with probab= ly a specific error code for mdnAlreadySent.


       [[ "MDN/generate", {
         "accountId": "ue150411c",
         "for": {
           "Md45b47b4877521042cec0938": {
             "subject": "Read receipt for: World domination",
             "textBody": "This receipt shows that the email has been
                 displayed on your recipient's computer. There is no
                 guaranty it has been read or understood.",
             "reportingUA": "linagora.com; OpenPaaS",
             "disposition": {
               "actionMode": "manual-action",
               "sendingMode": "MDN-sent-manually",
               "type": "displayed"
             }
           }
         }
       }, "R2" ]]

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

     [[ "MDN/generate", {
       "accountId": "ue150411c",
       "notGenerated": {
         "Md45b47b4877521042cec0938": {
           "type": "mdnAlreadySent",
           "description" : "$MDNSent keyword is already present"
         }
       }
     }, "R2" ],



The= emailId makes sense as the key for the object, since it's only legal to= do one per email.

=
NOTE: I didn't mention oldState= and newState here.  There's not much point, because the MDN itself= doesn't have state.  The Email/set response should have state, bec= ause email objects have state, but it doesn't make sense to have state f= or MDN objects, because you can't query or fetch them.
<= div style=3D"font-family:Arial;">
3.1. Sending an MDN for a received email

The = first example needs to show the Email/set response with the same method = call id.  There should also be an example (as above) for the error = case.

3.2. Asking for MDN

"header:Disposition-Notification-To": =
"joe@example.com",

This doesn't do quite what you expect - default is "asRaw", which doesn= 't add a leading space.  You probably want.

"header:Disposition-Notification-To:a=
sText": "joe@example.com",

3.3 Parsing a received MDN

Lik=
ewise, this should have an example of what to do when it's called on a b=
lob which doesn't parse as a MDN, or what happens when the blob doesn't =
exist.



General Comments
<=
/div>

Ideally each method should mention what kinds of errors are l=
ikely to be created, e.g this kind of thing from RFC8620.

   The fol=
lowing SetError types are defined and may be returned for set
   operations on any record type where appropriate:

   o  "forbidden": The action
      would violate an ACL or other permissions policy.

   o  "overQuota": The create would exceed a server-
      defined limit on the number or total size of objects of this type.=


   o  "tooLarge": The create would result in
      an object that exceeds a server-defined limit for the maximum size=

      of a single object of this type.

   o  "rateLimit": Too many objects of this type have been
      created recently, and a server-defined rate limit has been
      reached.  It may work if tried again later.

   o  "notFound": The id given
      cannot be found.

Obviously, these need to be chosen=
 from the existing error registry, or the IANA section should include re=
gistration for any newly added errors.

I expect security =
review might ask you to expand a little on the security considerations a=
s well.

Cheers,
=

Bron.

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



--7bc32331057b470491f86f77973366fc--


From nobody Wed Jan 29 05:16:55 2020
Return-Path: 
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8491C12011C for ; Wed, 29 Jan 2020 05:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cketti.de
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 rxniKf3sKWJg for ; Wed, 29 Jan 2020 05:16:52 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (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 DB068120108 for ; Wed, 29 Jan 2020 05:16:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1580303809; s=strato-dkim-0002; d=cketti.de; h=Date:Message-ID:Subject:From:To:X-RZG-CLASS-ID:X-RZG-AUTH:From: Subject:Sender; bh=f3xtV8qJUtq4J6Ev42WA/9xH8r1DMp+rIbtCcuxjT4w=; b=oTzDuK8zq9ok1nMdYxcdn0Kac/0lrIrJR8/G8Wjnm9oPkdyV5FajoZqUVucP9JTJ2V QWGkQTPl9JDjGd1JtLwltJtd3X8IImPGY9sK8aiyi+eeiy8d7z0FVQKHQKM5jGY/ONtv pHntm1y4w1qBgD78/qf5k4FBech56ur+axLnLsIP8rDeuPVdykpC+i0LHNuRlpg7OqCg WW3/VBmA0uG9n3H04rYaOY+7hFQrCOsgwLkaFduBko923zeIydblku+36fNjtkwevSW9 Btpft0dQcEXQcaZKQ0RNumV2YHQ50mNmgERnzQjKA7ymed1QpJGzYYGMCmjmDaPBoI3c zXbA==
X-RZG-AUTH: ":L2ckdkutb+sebmQwUUWXIIIYdHNZM+Bv5gC+3oIudZGrZypc/JzmdacuOGa/LyA0YU+4rqavpuxr/QdHxagO2In1vGo="
X-RZG-CLASS-ID: mo00
Received: from [IPv6:2a02:2450:102b:ad9:3454:4b3a:a266:67ce] by smtp.strato.de (RZmta 46.1.7 AUTH) with ESMTPSA id N0a9f8w0TDGnMgd (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Wed, 29 Jan 2020 14:16:49 +0100 (CET)
To: jmap@ietf.org
From: cketti 
Autocrypt: addr=ck@cketti.de; prefer-encrypt=mutual; keydata= xsFNBE49+OsBEADIu2zVIYllkqLYaCZq2d8r80titzegJiXTaW8fRS0FKGE7KmNttWvWdiyL qvWlP4Py9OZPmEBdz8AaPxqCFmVZfJimf28CW0wz2sRCYmmbQqaHFfpDrK+EJofckOu2j81c oaFVLbvkvUNhWU7/DKyv4+EBFt9fjxptbfpNKttwI0aeUVCa+Z/m18+OLpeE33BXd5POrBb4 edAlMCwKk8m4nDXJ3B+KmR0qfCLB79gqEjsDLl+y65NcRk5uxIk53NRXHkmQujX1bsf5VFLh a4KbUaB7BCtcSi1rY99WXfO/PWzTelOhpKDIRq+v3Kl21TipY0t4kco4AUlIx5b1F0EHPpmI Dr0gEheZBali5c9wUR8czc/HaNkRP81hTPeBtUqp1S7GtJfcuWv6dyfBBVlnev98PCKOJo05 meVwf3hkOLrciTfo1yuy/9hF18u3GhL8HLrxMQksLhD6sPzDto4jJQDxKAa7v9aLoR7oIdeW kn1TU61EODR/254BRMoq619hqJwSNt6yOjGT2BBvlwbKdS8Xfw7SsBGGW8WnVJrqFCusfjSm DBdV/KWstRnOMqw4nhAwNFfXmAL2L8a+rLHxalFggfGcvVpzDhJyTg+/R1y3JMCoFfdFuhOT fkMqjGx8FgTmINOt54Wf9Xg6W0hQh3i98Wza3n8NuSPQJtAdqQARAQABzRVja2V0dGkgPGNr QGNrZXR0aS5kZT7CwYEEEwECACsCGyMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheA BQJOPftbAhkBAAoJEO4v7zp9qOKJG+oP/RBN5ahJCpwrk7U05J8x7UOPuP4UElMYoPYZCSp5 5mH6Xmr2C626DvTxhElz1WY7oIOJ7Mgp1RtGqZYV52d6fER10jowGbSkiFTvKb4PhQl4+AcG ODMYLRVBw90rRhDSXzBQMeiyUf7Wse1jPsBfuOe6V1TsAtqjaAzrUDQOcsjQqW5ezvIjGNTF unX6wMUHzSBX6Lh0fLAp5ICp+l3agJ8S41Y4tSuFVil2IRX3o4vqxvU4f0C+KDIeJriLAMHa jUp0V6VdisRHujjoTkZAGogJhNmNg0YH191a7AAKvVePgMQ/fsoW1hm9afwth/HOKvMx8fgK Mwkn004V/to7qHByWDND33rgwlv1LYuvumEFd/paIABhdLhC6o6moVzwlOqhGfoD8DZAIzNC S4q2uCg8ik4temetPbCc5wMFtd+FO+FOb1tO/RahWeBfULreEijnv/zUZPetkJV9jTZXgXqC I9GCf6MTJrOLZ+G3hVxFyyHTKlWtiIzJHlX9rd3oQc7YJbdDFMZA+SdlGqiGdsjBmq0kcRqh hEa5QsnoNm9tuPuFnL5oGG7OFPztj9tr9ViRvsFBlx9jvmjRbRNF3287j1r+4lbGigsA1o8b RkLLXVSK1gCwbOLAPNJYH5bde6O+Qb8bepg9TByiohsFssxYXHwbgu/pcCMU1hCf15t4zsFN BE49+OsBEACxJ8Ocv8y90ALoPcbh5LXVSgm8cAMvENXouVAPxkxp0y3bByDeXtQdmycmWmHD 0yE/sTYMz4cA0E6LBRaYPySz9cSNvJkoZPGot5bO9xISS1BmszmdLo8cjJFg9KyATHnumJED Bs1JCSmhLanlS3Iuu0PECxy3xN99Sck7XdIMJabOhQHez7gpf+dHGsq9MlzMeu4sCpMr12ix 2FI3StdzAtsaHOFa4q83zbV9CbQpgGKCdotmKu74C0GrFI281LC1LsIaJcqMcBOpQeqWgXU4 dXU2uJgjd2PIDPgjL3qkFHGbjshWQ1jbTDzwjXllkZCoH3Pn8B0ogh4Q1rv+0uv8Uqg296no F5unAANlhcSfqBME0kbyv/Pcuk96IhW45mbPrEkY62QLBN6wwtlhUVBQauv1e/njthdX6jSz 81zmlUF/YtwR7+F48QtD0KFRZ76UiZR0llbsOcQN0KmvBrgfNM1hKlQSd9IH6o9QQBK6SsGl SiTrr0bkGtsJKu4lzvyKOEu1EBxTvlPVvOz2jzXX48cRLFZnsXl4RfJec8B2MqiitD3If2A6 FJP/sOyZ93KZqXHopmFRA6/2Kq27y6WpB7hEIg4FmZnBxxFQOw237DlC6qtb56VatE4nLXWd tGfDCdoADD/RwmRz8S2nyN2KkK10d1CB2+PGcMvbXTL+zQARAQABwsFlBBgBAgAPBQJOPfjr AhsMBQkSzAMAAAoJEO4v7zp9qOKJBfgQAJDdCneNOBz8v9+ZggnVpuQx6XMRFEaGNV+pr+g/ qbz0B1DfRinmGE+sI3KbA7Ap9lF/ZqdHtuElzsWaFZSe0+i/0DfjFMJ7diwDvVwmSzIo4Xuy l+dRSY5XdVvV32rqoT5UdS86/XCSN1HYmHLGR91+kn1v4Sy0RDFpv92HwAlVVjZBvT2p4a6D XFa/duZP8ufFkSnSTjoDBhgWMiAL7Vm+ptEJ/e/ABOd6+5rB8GatOrD1yGSaQpegk3sjK6lP dBviSWNwXz/axbFPTi5A0a7ABC5XiPYlz0BsOiMXs3YvdwqmPmOMHgo7WMZv+byscLLIPwC1 ZDP1X7VoFkUp2Zp2cLm4Ac4MMsAcBh8Tx8+wld5QSmX8PFNy+DHd7tWzFLumPo1vt9tg/u/m Wi3SXo5piXBLy2iLXXOtCB0zPxm7Ve0w4qkGkZsi2OSsZ8Bi7YXGFLBiOx2AzahGtfnEXLQf JRFqYE4xyp8HprweXNXz8WqO8NeTtLb0gl9pA+VDKAG71iSb8XFEz0zwRB02FqwJPjcuwm3T APu9a/eNkV6PV3ZuIao3zHA13UJn437XxQda7AXeULovInXkD+8qZZbFgvHyVJFjet5XluYM rC8fTI+m7ulweK2Etcx9pHhrWXuEKpcbLOyT1bCcw/cUqLYPhv1m+xdxyx86XnqpMM1V
Message-ID: 
Date: Wed, 29 Jan 2020 14:16:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------737DF3E94E6126FF0A7424DD"
Content-Language: en-US
Archived-At: 
Subject: [Jmap] draft-ietf-jmap-mdn-04: Require "urn:ietf:params:jmap:mail" capability when calling MDN/set?
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, 29 Jan 2020 13:16:55 -0000

This is a multi-part message in MIME format.
--------------737DF3E94E6126FF0A7424DD
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

[Originally posted as GitHub issue jmapio/jmap#314
, but it's probably more
appropriate here.]

This is similar to "use of EmailSubmission/set#onSuccess* without :mail
capability ".

We could require MDN/set to add the "urn:ietf:params:jmap:mail"
capability in the using property of the request because of the implicit
call to Email/set. Failing to provide the capability would return a
unknownMethod error response for the implicit call.

However, using this approach could allow a client to send multiple MDNs
because the $MDNSent keyword isn't added to the message and that keyword
is used as rejection criterion by the server.

If this is unwanted behavior, I see the following two options to forbid it:

  * require both capabilities for the MDN/set call, i.e. MDN/set will
    fail when the "urn:ietf:params:jmap:mail" capability is missing; not
    only the Email/set call

  * make the "urn:ietf:params:jmap:mail" capability implicit, so we
    can't run into an unknownMethod error

-cketti


--------------737DF3E94E6126FF0A7424DD
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    [Originally posted as GitHub issue jmapio/jmap#314,
    but it's probably more appropriate here.]
    
This is similar to "use of
        EmailSubmission/set#onSuccess* without :mail capability".

      

      We could require MDN/set to add the "urn:ietf:params:jmap:mail"
      capability in the using property of the request because of the
      implicit call to Email/set. Failing to provide the capability
      would return a unknownMethod error response for the implicit call.

      

      However, using this approach could allow a client to send multiple
      MDNs because the $MDNSent keyword isn't added to the message and
      that keyword is used as rejection criterion by the server.

      

      If this is unwanted behavior, I see the following two options to
      forbid it:

    
    
      
  • require both capabilities for the MDN/set call, i.e. MDN/set
        will fail when the "urn:ietf:params:jmap:mail" capability is
        missing; not only the Email/set call
    • 
    

    
    
      
  • make the "urn:ietf:params:jmap:mail" capability implicit, so
        we can't run into an unknownMethod error
    • 
    

    
-cketti

  


--------------737DF3E94E6126FF0A7424DD--


From nobody Wed Jan 29 13:37:15 2020
Return-Path: 
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED612120048 for ; Wed, 29 Jan 2020 13:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level: 
X-Spam-Status: No, score=-2.697 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, 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=IlRird1t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f7FSJkO6
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 puaqj4tPN-wG for ; Wed, 29 Jan 2020 13:37:07 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C14F12004E for ; Wed, 29 Jan 2020 13:37:07 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5072921ADD for ; Wed, 29 Jan 2020 16:37:06 -0500 (EST)
Received: from imap28 ([10.202.2.78]) by compute2.internal (MEProxy); Wed, 29 Jan 2020 16:37:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=1Ec9NOg XvMLqzwQnMU/AQQ5Szg6eAzJB67T8/hILrjM=; b=IlRird1t9Ln0eWc11I3KsCK 3j45VgXrXIzT6nVIUXhCeoDEQWSQ+iHOqyozjW2D0TFKJYO3uhVaT3vFT6Ls9EyC UICMASO/JAJWxomfjFUsn/HCyfUpjD/cn8u/BKJKsQknrn+wVkEOiI7luKP6TPtI mCWGcf/QWstE8A6m12zS3DE15Bkoyg6tJDOyUNEsAb1wZiT3mZFNjoTl01UrX+MR hjdeg/aulj6sX83oHOiAWgcxSNOUSDsjymK26UehBJ1XjArcJW6/uy+rIvdQd+a7 zcic4Vak1X2/j+yZLJvRCjBd+lWVB3ww5tSsFV0jgPLasiI4x/dpxmGNJ8RSb2Q= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=1Ec9NO gXvMLqzwQnMU/AQQ5Szg6eAzJB67T8/hILrjM=; b=f7FSJkO6Zpdzd02K9OyJBc 5bVNPoHcvcnX/Hs6KevlC9ReI+RUYDlV9jQBO4CEqeVTMGtZBFM9StO8I9twfwJD 4Ht/CmbSnjaBRU6zDkZSqc7o3o5gsJ7iKGRFcNsat2xyi0WL6oJ+zjMvepfJn5g3 Iroku3gv0S2pnDOnEU5iyIP3o8Pxq5Y7inwVua6eoP0RoaJGy9kHHh63muAfWyEN gMRBgWAlDCrDnTybjguGmtDyexD6q0U3jAnD94W79Xtanfg3/c+5eG4VOa+NLVwH akTZa5UsaHC/WrXVkTuM78jmvyqcdX8pMuPeAItvJL1e69O8sWuEgkpWEo86Fpdg ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrfeeigddugeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghr ohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id EF98424009E; Wed, 29 Jan 2020 16:37:05 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-850-ga703523-fmnext-20200128v1
Mime-Version: 1.0
Message-Id: <5053957f-2dfb-4f24-afe1-4214399725fb@dogfood.fastmail.com>
In-Reply-To: 
References: 
Date: Thu, 30 Jan 2020 08:36:52 +1100
From: "Bron Gondwana" 
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=d40710facf874a3bb21f404dab7b1510
Archived-At: 
Subject: Re: [Jmap]  =?utf-8?q?draft-ietf-jmap-mdn-04=3A_Require_=22urn=3Aietf?= =?utf-8?q?=3Aparams=3Ajmap=3Amail=22_capability_when_calling_MDN/set=3F?=
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, 29 Jan 2020 21:37:11 -0000

--d40710facf874a3bb21f404dab7b1510
Content-Type: text/plain

On Thu, Jan 30, 2020, at 00:16, cketti wrote:
> [Originally posted as GitHub issue jmapio/jmap#314 , but it's probably more appropriate here.] 

> This is similar to "use of EmailSubmission/set#onSuccess* without :mail capability ".
> 
>  We could require MDN/set to add the "urn:ietf:params:jmap:mail" capability in the using property of the request because of the implicit call to Email/set. Failing to provide the capability would return a unknownMethod error response for the implicit call.
> 
>  However, using this approach could allow a client to send multiple MDNs because the $MDNSent keyword isn't added to the message and that keyword is used as rejection criterion by the server. 


I'm kinda "meh" about this. A client that wants to send multiple MDNs can always do it by removing the $MDNSent keyword.


>  If this is unwanted behavior, I see the following two options to forbid it:

>  * require both capabilities for the MDN/set call, i.e. MDN/set will fail when the "urn:ietf:params:jmap:mail" capability is missing; not only the Email/set call
>  * make the "urn:ietf:params:jmap:mail" capability implicit, so we can't run into an unknownMethod error

I'm not a fan of implicit, but I'd be OK with MDN/set (or whatever it winds up being called) requiring the :mail capability, because the MDN is an email really, so you need the ability to process emails!

Bron.

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


--d40710facf874a3bb21f404dab7b1510
Content-Type: text/html


On Thu, Jan 30, 2020, at 00:16, cketti wrote:
[Originally posted as GitHub issue jmapio/jmap#314,
    but it's probably more appropriate here.] 
 
 We could require MDN/set to add the "urn:ietf:params:jmap:mail"
      capability in the using property of the request because of the
      implicit call to Email/set. Failing to provide the capability
      would return a unknownMethod error response for the implicit call.
 
 However, using this approach could allow a client to send multiple
      MDNs because the $MDNSent keyword isn't added to the message and
      that keyword is used as rejection criterion by the server. 

I'm kinda "meh" about this.  A client that wants to send multiple MDNs can always do it by removing the $MDNSent keyword.

 If this is unwanted behavior, I see the following two options to
      forbid it:
  • require both capabilities for the MDN/set call, i.e. MDN/set
        will fail when the "urn:ietf:params:jmap:mail" capability is
        missing; not only the Email/set call
  • make the "urn:ietf:params:jmap:mail" capability implicit, so
        we can't run into an unknownMethod error

I'm not a fan of implicit, but I'd be OK with MDN/set (or whatever it winds up being called) requiring the :mail capability, because the MDN is an email really, so you need the ability to process emails!

Bron.

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



--d40710facf874a3bb21f404dab7b1510--


From nobody Fri Jan 31 07:37:56 2020
Return-Path: 
X-Original-To: jmap@ietf.org
Delivered-To: jmap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E65120120; Fri, 31 Jan 2020 07:37:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: jmap@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: jmap@ietf.org
Message-ID: <158048507210.21150.12198577645686699617@ietfa.amsl.com>
Date: Fri, 31 Jan 2020 07:37:52 -0800
Archived-At: 
Subject: [Jmap] I-D Action: draft-ietf-jmap-websocket-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: Fri, 31 Jan 2020 15:37: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           : A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket
        Author          : Kenneth Murchison
	Filename        : draft-ietf-jmap-websocket-05.txt
	Pages           : 16
	Date            : 2020-01-31

Abstract:
   This document defines a binding for the JSON Meta Application
   Protocol (JMAP) over a WebSocket transport layer.  The WebSocket
   binding for JMAP provides higher performance than the current HTTP
   binding for JMAP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-jmap-websocket/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-jmap-websocket-05
https://datatracker.ietf.org/doc/html/draft-ietf-jmap-websocket-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-websocket-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/