From nobody Tue Mar 3 22:35:17 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 7F7623A0FF3; Tue, 3 Mar 2020 22:35:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <158330371043.7793.6830462956573674911@ietfa.amsl.com> Date: Tue, 03 Mar 2020 22:35:10 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-quotas-01.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2020 06:35:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Quotas Authors : René Cordier Michael Bailly Filename : draft-ietf-jmap-quotas-01.txt Pages : 10 Date : 2020-03-03 Abstract: This document specifies a data model for handling quotas on accounts with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-quotas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-quotas-01 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-quotas-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-quotas-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 3 22:42: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 39CE33A1003 for ; Tue, 3 Mar 2020 22:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 Q3ez9xhCfBQJ for ; Tue, 3 Mar 2020 22:41:56 -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 9CF3A3A1002 for ; Tue, 3 Mar 2020 22:41:55 -0800 (PST) Received: from linagora.com (unknown [10.233.69.48]) by outgoing.linagora.com (Postfix) with ESMTP id 93CEB3B for ; Wed, 4 Mar 2020 06:41:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1583304113; bh=qp8WlVf7uVxOvVTvC5wEdYSOPAp5uJGUSDeURpqPsww=; h=From:Reply-To:To:Subject:Date:References:From; b=ltELKqsFSrxf5+Xp6jE+w7jFJxeer34i+5pCenXur8yzfTBeyLhSbQ9+YpkGVzau4 wK/OW3WFosxDBsn21j9P4muT/SgTpqbm5gsi1omn+DHlyKs2ewrFOz4ksc8jRZxkol XiHQno93YH4JLNlMwZZeaWQtqVHdiBruk88+WG4ylLg1uCOQovA9WM0uQEwUO/mdaj fA92hHTDN5dsohARwuBWV95FbwM9Te2sVtf+Mo3Zh97qkOT0rJIs/6s2b12DLM3xbR 92IrTUM7PlgKFwYj2613T7n4ZZZInvLddGHwOID9X0HeT5VeahJ4ocBoRx07+lfuov 3lAzx93CYUcLA== 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: Wed, 4 Mar 2020 06:41:52 +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: Wed, 04 Mar 2020 06:41:59 -0000

Hi all,

First of all, I would like to apologize for the time spent= on this=2E I will try to fix comments faster in the future=2E

Then, = I am happy to say that I finally released the new draft version of JMAP quo= tas specs=2E Please have a look at the ietf tracker: https://datatracker=2E= ietf=2Eorg/doc/draft-ietf-jmap-quotas

I also did a github PR with the= code change: https://github=2Ecom/jmapio/jmap/pull/318

I tried to an= swer inline below as well to the feedback mashup generously made by Bron la= st time=2E Please don't hesitate to have a look=2E

I would like to ad= d an extra note as well, regarding the "quotaIds", it made little sense to = add a field in "Mailbox" object indeed=2E I moved it as a property of the a= dditional account's capability "urn::ietf::params::jmap::quota", as I think= it makes more sense to have the quotas bounded to the account=2E

I w= ould like to discuss an other idea as well (that is not represented in this= draft)=2E Some properties seem likely to be repeated many times=2E I thoug= ht of adding a new Object for that, called "QuotaResource", that would be d= efined by a "name", "resourceType", "warnLimit", "softLimit", "limit" and "= scope"=2E Probably we want those to be the same for a group of users or all= users, repeating it for each Quota sounds redundant? Something like that:<= /p>

"QuotaResource": {
  "id": "re01",
  "name": "normal = user quota resource",
  "resourceType": "count",
  "warnLim= it": 1600,
  "softLimit": 1800,
  "limit": 2000,
  = "scope": "account"
}

"Quota": {
  "id": "qu01",
  = "quotaResourceId": "re01",
  "used": 1056,
  "name": "bob@e= xample=2Ecom",
  "description": "Personal account usage",
 = "datatypes": [ "Mail", "Calendar" ]
}

With maybe methods like /ge= t, /set, /query ?

Do you feel like it could be a good idea? Or do= es it make the all thing too complex and unnecessary?

Cheers,

R= ene=2E

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

Hi,

This is a combination of feedback collected from the meeti= ng yesterday as well as my own suggestions!  These suggestions only co= me with my own personal weight, and are not a "you must", they are an "I su= ggest" - please feel free to offer counter proposals or even outright rejec= tions of my suggestions, there is no "chair weight" attached=2E

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 n= ull (which might be the same thing as "account") then I don't see a pro= blem in having it available for those who want it=2E

I would ju= st call the key "scope" rather than "usedScope"=2E  I don't see the po= int of putting different scopes on it, that seems unworkable=2E  Inste= ad, 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 your domain is using 34Gb of 100Gb allocate= d to the domain" - there's no point having "you're using 400Mb of your doma= in's 100Gb", 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 using to be meaningful for calculating what you can do=2E


Agreed, one scope is simpler and more logical=2E


Datatypes

At the moment there's no way to tie dat= atypes to quotas=2E  I would like to add an array of datatypes to each= object (example below)=2E  As an example, you may have a different qu= ota for Calendars than for Mail - or they may be shared=2E  This is so= mewhat different from scope (server, domain, user, =2E=2E=2E)=2E


I liked that idea=2E Allows to apply Quota to more than just= mails, so to other defined jmap objects defined by the specs, or even cust= om server ones=2E


=
Quota/query

At t= he moment 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 canCalculateChang= es; false, but we could allow that too if a server finds it easy with their= general model)=2E


I did add the "/query", and als= o the "/queryChanges"=2E I don't have a strong opinion on this but maybe it= can be useful for a server to have "/queryChanges" too=2E


Quota/changes

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

[["Quota/changes", { = "sinceState": =2E=2E=2E }, "1"],
 ["Quota/get", {
   "#ids": { "resu= ltOf": "1", "name": "Quota/changes", = "path": "/updated" },
<= /div>
   "#properties" : { "resu= ltOf": "1", "Quota/changes", "path": "/update= dProperties" },
"2"]]

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


I agree that "used" is probably gon= na changed a lot compared to other fields, and that we are probably most in= terested by this field on a regular basis=2E


Push=

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

<= br>+1


Description

Do we need to pr= ovide for both a short "name" and a longer "description" field on each quot= a?


+1


Soft limits
=

Does anybody care about soft vs hard limits?  Soft limit bein= g "you won't be blocked, but you'll be told off any maybe charged more", ha= rd 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 Kamp - in fact he talked of 3 l= evels=2E  Perhaps they could be something like:

warnLimit<= br>
softLimit
limit

<= /div>
Where obviously warnLimit and softLi= mit are optional (and must each be lower than the next level up)=2E  T= his is more complexity, but it's optional complexity at both ends: servers = don't need to set them, and clients don't need to display them=2E


+1

Resource Types

= The IMAP quota draft defines three types of resources for quotas, and also = a registry where more can be described=2E  The initial types are "STOR= AGE" (units 1024 octets), "MESSAGE" (number of individual emails) and "MAIL= BOX" (number of mailboxes)=2E  It maybe viable to use the same registr= y=2E

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

Also: should w= e 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 registry?


I would agree to Neil's comment on that one, that suggested = that if we have the "datatypes" property, then we just need to have types l= ike "count" or "size"=2E Then for the "what do we count or calculate the si= ze of?" question, the answer would be in the declared data types=2E 

Regarding the size, I put it in bytes by default, but still precised t= hat it's up to the server to choose (maybe some server wants octets?)=2E Bu= t that might be confusing for the client=2E=2E=2E Or should we have more gr= anular resource types here, like "bytes" and "octets", or "sizeBytes" and "= sizeOctets"?


EXAMPLE:

As promised,= a Quota object for my example:
=
{
     "id": "2a0=
6df0d-9865-4e74-a92f-74dcc814270e",
     "type": "storage",
     "used": 10=
5645,
     "scope": "account",
     "limit": 200000,
     "description": "P=
ersonal account usage",
     "name": "=
brong@brong=2Enet",
     "datatypes" : [ "Mail", "Calendar", "Contact",=
 "Todo" ],
}

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



From nobody Wed Mar 4 02:44:58 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 066883A0C16 for ; Wed, 4 Mar 2020 02:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=TeO6Iwpa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nJs6+tgq 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 5SWQa20kPkjr for ; Wed, 4 Mar 2020 02:44:53 -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 986243A0C20 for ; Wed, 4 Mar 2020 02:44:52 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id CD96F5FA for ; Wed, 4 Mar 2020 05:44:48 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 04 Mar 2020 05:44:48 -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=fm2; bh=dhjcWzt KqRJjTWOHlOhQlL5TYM0oTy79X086j0Ukf0A=; b=TeO6IwpaxeREOWz1yJBJtY8 191DX42R8U5LMZkggENw4JsTGsDzurjeEw53aie5LhpP92oL0wpY55+TfolgKFVn akzm1Ap8y7wkI+4F1DKKmjtmMFNia4moQ31gPzNfyd1oaY6zgIbho9T9RglOocTC 5xKM4eNobESnhSAVEu9PQUVabQndyR2IYgcezvC7x5a05OpEfQVCbJC9ZuNV4qWi e5Ao2JU9tu9+kAgaPFyqhFUHQvxohrewaWYXJ3d1NlPDQoRBwiDMqhE2nIBo9M9F HqioTYEte64QMu4oQWKOQbI0/1U61Lg01gTuuJlFu3hWIV4oJGjac2o2Ots8s1Q= = 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=fm2; bh=dhjcWz tKqRJjTWOHlOhQlL5TYM0oTy79X086j0Ukf0A=; b=nJs6+tgqthUkCkBl8ziFxt qX300tP5SAq5X0v9ZkskiFtGP7LuZbtGRU+qOMiltZ0wcBcI4sPOMPwjdkezvGSq AQ8oo6vtPAGcsYI8f1NrW+lEAmafe9FvLTG3+lI51zLCANVDISukME5v9YWMnTyD xWTCd+iz0xYyH9LqtSzt35H/ykOPCn6KDKQcHIF1iLuDP2nLufi/14kV9DisdY3l e3ptChj9AARZf/BnhQq1eQdel4HDWWeQMWvLygcVNUqbgz97yZwMhJm1fZiX5Q1A Imjhcr3ui4WWoFIknewy9mHmUd0dnd4PSgxiZWm4jvCSLzXlz52vqfjd5yfs8/JQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtkedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgpd hgihhthhhusgdrtghomhdpfihikhhiphgvughirgdrohhrghenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3727A180091; Wed, 4 Mar 2020 05:44:48 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-986-gfc2d493-fmstable-20200304v3 Mime-Version: 1.0 Message-Id: <03a055f8-7ab3-44c8-b1cd-ccd51ed967fe@dogfood.fastmail.com> In-Reply-To: References: Date: Wed, 04 Mar 2020 21:44:53 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=bab3457cbd3d4ab9aa161ec3a1f46890 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: Wed, 04 Mar 2020 10:44:57 -0000 --bab3457cbd3d4ab9aa161ec3a1f46890 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ren=C3=A9, Thanks for updating the draft! I'm about to hop on a plane and then I'll= be on holiday for a couple of weeks - so just brief responses now! I've= flagged this message to get back to when I'm working again. Responses inline. On Wed, Mar 4, 2020, at 17:41, Ren=C3=A9 CORDIER wrote: > Hi all, > First of all, I would like to apologize for the time spent on this. I = will try to fix comments faster in the future. > Then, I am happy to say that I finally released the new draft version = of JMAP quotas specs. Please have a look at the ietf tracker: https://da= tatracker.ietf.org/doc/draft-ietf-jmap-quotas > I also did a github PR with the code change: https://github.com/jmapio= /jmap/pull/318 > I tried to answer inline below as well to the feedback mashup generous= ly made by Bron last time. Please don't hesitate to have a look. > I would like to add an extra note as well, regarding the "quotaIds", i= t made little sense to add a field in "Mailbox" object indeed. I moved i= t as a property of the additional account's capability "urn::ietf::param= s::jmap::quota", as I think it makes more sense to have the quotas bound= ed to the account. > I would like to discuss an other idea as well (that is not represented= in this draft). Some properties seem likely to be repeated many times. = I thought of adding a new Object for that, called "QuotaResource", that = would be defined by a "name", "resourceType", "warnLimit", "softLimit", = "limit" and "scope". Probably we want those to be the same for a group o= f users or all users, repeating it for each Quota sounds redundant? Some= thing like that: > "QuotaResource": { > "id": "re01", > "name": "normal user quota resource", > "resourceType": "count", > "warnLimit": 1600, > "softLimit": 1800, > "limit": 2000, > "scope": "account" > } > "Quota": { > "id": "qu01", > "quotaResourceId": "re01", > "used": 1056, > "name": "bob@example.com", > "description": "Personal account usage", > "datatypes": [ "Mail", "Calendar" ] > } > With maybe methods like /get, /set, /query ? > Do you feel like it could be a good idea? Or does it make the all thin= g too complex and unnecessary? I think it's probably too complex - but maybe others disagree. I don't f= eel super strongly about it so long as there's clear guidance on how to = use it. > 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 > Agreed, one scope is simpler and more logical. >>=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 > I liked that idea. Allows to apply Quota to more than just mails, so t= o other defined jmap objects defined by the specs, or even custom server= ones. >>=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 > I did add the "/query", and also the "/queryChanges". I don't have a s= trong opinion on this but maybe it can be useful for a server to have "/= queryChanges" too. >>=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 > I agree that "used" is probably gonna changed a lot compared to other = fields, and that we are probably most interested by this field on a regu= lar basis.=20 >>=20 >> *Push* >>=20 >> There should be a nod towards Push and mention that Quota state chang= es are pushed like other state changes. >=20 > +1 >>=20 >> *Description* >>=20 >> Do we need to provide for both a short "name" and a longer "descripti= on" field on each quota? >=20 > +1 >>=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 > +1 >>=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 > I would agree to Neil's comment on that one, that suggested that if we= have the "datatypes" property, then we just need to have types like "co= unt" or "size". Then for the "what do we count or calculate the size of?= " question, the answer would be in the declared data types.=20 > Regarding the size, I put it in bytes by default, but still precised t= hat it's up to the server to choose (maybe some server wants octets?). B= ut that might be confusing for the client... Or should we have more gran= ular resource types here, like "bytes" and "octets", or "sizeBytes" and = "sizeOctets"? Bytes and Octets are the same thing, to a reasonable approximation: https://en.wikipedia.org/wiki/Octet_(computing) Byte has historically been used for other sizes, but it always means 8 b= its these days. I see no reason to allow any other unit - if we're doing 64 bit values t= here's plenty of room, and unit conversions at the low level suck and ar= e grounds for confusion. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --bab3457cbd3d4ab9aa161ec3a1f46890 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Ren=C3=A9,

Thanks for updating the = draft!  I'm about to hop on a plane and then I'll be on holiday for= a couple of weeks - so just brief responses now!  I've flagged thi= s message to get back to when I'm working again.

Response= s inline.

On W= ed, Mar 4, 2020, at 17:41, Ren=C3=A9 CORDIER wrote:

Hi all,

First of all, I would like= to apologize for the time spent on this. I will try to fix comments fas= ter in the future.

Then, I am happy to say that I finally rele= ased the new draft version of JMAP quotas specs. Please have a look at t= he ietf tracker: https://datatracker.ietf.org/doc/draft-ietf-jmap-quotas=

I also did a github PR with the code change: https://github.c= om/jmapio/jmap/pull/318

I tried to answer inline below as well= to the feedback mashup generously made by Bron last time. Please don't = hesitate to have a look.

I would like to add an extra note as = well, regarding the "quotaIds", it made little sense to add a field in "= Mailbox" object indeed. I moved it as a property of the additional accou= nt's capability "urn::ietf::params::jmap::quota", as I think it makes mo= re sense to have the quotas bounded to the account.

I would li= ke to discuss an other idea as well (that is not represented in this dra= ft). Some properties seem likely to be repeated many times. I thought of= adding a new Object for that, called "QuotaResource", that would be def= ined by a "name", "resourceType", "warnLimit", "softLimit", "limit" and = "scope". Probably we want those to be the same for a group of users or a= ll users, repeating it for each Quota sounds redundant? Something like t= hat:

"QuotaResource": {
  "id": "r= e01",
  "name": "normal user quota resource",
  "resourceType": "count",
  "warnLimit":= 1600,
  "softLimit": 1800,
  "lim= it": 2000,
  "scope": "account"
}

"Quota": {
  "id": "qu01",
=
  "quotaResourceId": "re01",
  "used"= : 1056,
  "name": "bob@example.com",
&n= bsp; "description": "Personal account usage",
  "data= types": [ "Mail", "Calendar" ]
}

With m= aybe methods like /get, /set, /query ?

Do you feel like it cou= ld be a good idea? Or does it make the all thing too complex and unneces= sary?


I think it's probably too complex - but = maybe others disagree.  I don't feel super strongly about it so lon= g as there's clear guidance on how to use it.

Cheers= ,

Rene.

Le 20 novembre 2019 = 18:20, de brong@fastmailteam.com

Hi,

=
This is a combination of feedbac= k collected from the meeting yesterday as well as my own suggestions!&nb= sp; 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 count= er proposals or even outright rejections of my suggestions, there is no = "chair weight" attached.

=
With that said, here's the sugge= stions :)

Scope

I'm not sure if the= re'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.

I would just call the ke= y "scope" rather than "usedScope".  I don't see the point of puttin= g different scopes on it, that seems unworkable.  Instead, if you h= ave quotas in multiple scopes I would expect a quota entry per scope wit= h the amount that was used and the limit - e.g. "you're using 400Mb of 1= Gb 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= 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.


Agreed, one scope is simpler and mor= e logical.


Datatypes
<= div style=3D"font-family:Arial;">
At the moment there's no way to tie datatypes to quotas.  I wo= uld like to add an array of datatypes to each object (example below).&nb= sp; As an example, you may have a different quota for Calendars than for= Mail - or they may be shared.  This is somewhat different from sco= pe (server, domain, user, ...).


I liked that idea. Allows to apply Quota to more than just mail= s, so to other defined jmap objects defined by the specs, or even custom= server ones.


Quota/query

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 /query as well (probably don't need a /queryChanges, just have = a canCalculateChanges; false, but we could allow that too if a server fi= nds it easy with their general model).


I did add the "/query", and also the "/queryChanges". I = don't have a strong opinion on this but maybe it can be useful for a ser= ver to have "/queryChanges" too.


Quot= a/changes

Like with Mailbox/changes - I could see val= ue in having a updatedProperties which can be either null or a list of p= roperties, such that you could issue:

[["Quota/changes", = { "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.


I agree that "= used" is probably gonna changed a lot compared to other fields, and that= we are probably most interested by this field on a regular basis.
<= /div>


Push

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


+= 1


Description

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


+1<= br>


=
Soft limits

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 limi= ts being "your changes will be rejected".  Should we have an option= al second 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 levels.  Perhaps they could be something like:

war= nLimit
softLimit
limit

Where obviously warn= Limit and softLimit are optional (and must each be lower than the next l= evel up).  This is more complexity, but it's optional complexity at= both ends: servers don't need to set them, and clients don't need to di= splay them.


+1


Resource Types

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

Of course, then you get issues like what should you cal= l it for Calendar or Addressbook?  Should the limits be given DAVis= h names like "COLLECTION" and "RESOURCE" such that MESSAGE becomes "RESO= URCE" 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= registry?


I would agre= e to Neil's comment on that one, that suggested that if we have the "dat= atypes" property, then we just need to have types like "count" or "size"= . Then for the "what do we count or calculate the size of?" question, th= e answer would be in the declared data types. 

R= egarding the size, I put it in bytes by default, but still precised that= it's up to the server to choose (maybe some server wants octets?). But = that might be confusing for the client... Or should we have more granula= r resource types here, like "bytes" and "octets", or "sizeBytes" and "si= zeOctets"?


Bytes and Octets are the same thing= , to a reasonable approximation:


Byte has historically been used for other= sizes, but it always means 8 bits these days.

I see no r= eason to allow any other unit - if we're doing 64 bit values there's ple= nty of room, and unit conversions at the low level suck and are grounds = for confusion.

Bron.

--
  Br= on Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailte= am.com

<= br>
--bab3457cbd3d4ab9aa161ec3a1f46890-- From nobody Thu Mar 5 16:40: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 0B6A23A0FB4 for ; Thu, 5 Mar 2020 16:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=ivECRWLv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o7ndcxb4 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 bP2RmjCrqDMo for ; Thu, 5 Mar 2020 16:40:03 -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 887703A0F83 for ; Thu, 5 Mar 2020 16:40:03 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2133E22247 for ; Thu, 5 Mar 2020 19:40:01 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 05 Mar 2020 19:40:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= to:from:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=fm2; bh=b33RUK4hxP1B39PWmLjCzNQ1UM 5jBVH1QsOo6Y8NJr4=; b=ivECRWLvlmaZm+VfqZjbRKxGS/Uvs67yjoEnOAztcD rqvwbx9wgz9R//f7bvJL9PGvEJJ22JtRN5F1klSRVtT0iRpmVbveQG5tIyAZutcR og0ZFYznm2im2+MtbaFar9p8E1+98duGRGQXKjF79hQvLL3/JWCzkX8nnL1jEReQ t/9GUA/TTIbiDFzFj69S3jlpTbo1AxEjXVWMz3thrUJXaF6iHYvHG+WASvtmCW84 BROo1lDNRbMK19jsOWmcheqF7zgDI/II0VZNN4vEavB30MOKd5YXYMuFGw9n0dif TywKbu2IY8Y47L+EN0zfDpUKQXCYideGmK+ELKz/06yg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=b33RUK 4hxP1B39PWmLjCzNQ1UM5jBVH1QsOo6Y8NJr4=; b=o7ndcxb49ay/kLT+CYAreI BD/bi7alYRnmChbb2isx97J0NgsTutkoka9TX0NnJbfYx4DGt48+vq2pD69HBMUX S6ZsVYitc/zzEeXBafyvG122bw3qCQPCfbo9hkGnpOpFJvNI2BaQNoWBaVwEP+zp 65lHrXCW8XzSCuAX6vVfoy/dItMwCDlMshkDCNoVtCo3YtTKP5P578tAl3CxlnRL oQc1c06aiUOKgi4bhL3mqFukx4rTv7hKWZNHemsw/ONVWQxwBqUSs5zNg+sJoLb9 76RTJrzxB6HmJqkqDXxlJecsAVUzOh8SKF/xE/Cg5wItsaV0AE7Wav2Wr2GhiF8w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudduuddgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefvhffuohfkffgfgggtgfesthekre dttdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhm rghilhdrtghomh 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 D2EF43061393 for ; Thu, 5 Mar 2020 19:40:00 -0500 (EST) To: jmap@ietf.org From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Thu, 5 Mar 2020 19:40:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Jmap] draft-ietf-jmap-mdn-06 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, 06 Mar 2020 00:40:14 -0000 A few questions as I implement this in Cyrus: - forEmailId is allowed to be null, presumably just for MDN/parse responses.  Should we mandate that it be non-null for MDN/send, because otherwise, what's the point? - subject and textBody are both allowed to be null.  Should we recommend default text for both? - The JMAP server may not be able to determine the Final-Recipient of the original message was Bcc'd or sent to an alias.  Should the MDN object include a 'from' property? -- Ken Murchison Cyrus Development Team Fastmail US LLC From nobody Fri Mar 6 11:35: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 9C6213A090B for ; Fri, 6 Mar 2020 11:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=lvhYmmqp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NWeePuWU 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 X5fbtoSwtuBs for ; Fri, 6 Mar 2020 11:35:48 -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 636FB3A08E8 for ; Fri, 6 Mar 2020 11:35:48 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id CF743572 for ; Fri, 6 Mar 2020 14:35:47 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 06 Mar 2020 14:35:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:from:to:references:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=t 4ZLWgSsdKb5ygFJkR2/rzfNbeh4sB6vII0Ey51XAvU=; b=lvhYmmqpJUKZ9u2x9 sa1zjopEYX8MJddMH3S2XgP2YQ6Udq51lnXNWGXgotd1d5n6MIdCJPnnx48pReH6 0pkwbBmc+iecuqOheW1R31hY1eKy4jFKZ4koUHmKFhe9DMGu4f42//xVu6D5SKZm aiy0NP+1qtMOVjQPxft/Q1IaM4RbYVMlFlmw6ZY7EyB0KJSUQrUKPOJobIaAMrfy Kyjy9S2L+V5cwxXWQurDnV4cBHUd8Gexomek6uf4IYKaIa4lqWbIs/dGlGb/jaJz nCReKJvdWwF0QGSyRmv2oiCCenr/wrioC1dJX71xs+PCJASDQKgpdohZogY+gXgZ go3YA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm2; bh=t4ZLWgSsdKb5ygFJkR2/rzfNbeh4sB6vII0Ey51XA vU=; b=NWeePuWUEVO2Y0Jj9Ev6ErIaWN5Ubnp9l0nOiPwqzz+gJbm11SNnuLJXt cVlfb9oVsvvFx1MAxk/ssBIn0anrR1cwaatd78B1CiNiKlL6sNQdHGpY9PJMAp8L XkkI+nHf8jMm3gynHaMdeDa9Bi9jgKSD7bSmILlE6LhSQLlUvWsLwsufkDzSrJSg 2Q0IWkAfzInrOUlqwiKbHZ0olGVg4s3gXNPJaHBUIIDJdYuxDLT3+QLlaZmx/EUn KTnrUos22hLzuwZPHOUZU4RmDsnUnH1mCV1WXlnVwuN8hs9MPP0wAisjENy478yc iAcELHpy5PXu/0x0ePmfj/4c1nlXw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudduvddgudeftdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffhvfhfohfkffgfgggjtgfgse htkeertddtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhes fhgrshhtmhgrihhlrdgtohhmqeenucfkphepjeegrdejjedrkeehrddvhedtnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgr shhtmhgrihhlrdgtohhm 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 3557D3060BD1 for ; Fri, 6 Mar 2020 14:35:47 -0500 (EST) From: Ken Murchison To: jmap@ietf.org References: Organization: FastMail US LLC Message-ID: Date: Fri, 6 Mar 2020 14:35:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] draft-ietf-jmap-mdn-06 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, 06 Mar 2020 19:35:56 -0000 On 3/5/20 7:40 PM, Ken Murchison wrote: > A few questions as I implement this in Cyrus: > > - forEmailId is allowed to be null, presumably just for MDN/parse > responses.  Should we mandate that it be non-null for MDN/send, > because otherwise, what's the point? > > - subject and textBody are both allowed to be null.  Should we > recommend default text for both? > > - The JMAP server may not be able to determine the Final-Recipient of > the original message was Bcc'd or sent to an alias.  Should the MDN > object include a 'from' property? Also, do we need a specific error type if the email corresponding to fromEmailId does NOT have a Disposition-Notification-To header?  Or do we use invalidProperties, forbidden, invalidEmail, noRecipients? -- Ken Murchison Cyrus Development Team Fastmail US LLC From nobody Sun Mar 8 12:17: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 81CB53A07E1 for ; Sun, 8 Mar 2020 12:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=BsSCz9oL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LTDXLzZ6 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 5Lj1NJHllfcZ for ; Sun, 8 Mar 2020 12:16:59 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A259A3A07BC for ; Sun, 8 Mar 2020 12:16:59 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A0B6B21CC3; Sun, 8 Mar 2020 15:16:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 08 Mar 2020 15:16:58 -0400 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; s=fm2; bh=FbUQKMO8qYDHss8mukOiW05RnQf W2lZMYAVLSvay4cs=; b=BsSCz9oLz3xTk65w+yDpPwB0hVixAKqtnEjXdibWzR+ gW5ahbXOG/TPsarxWD3TjqNiQxSJqeF0Q1iJyaEIrlVYVF4LMPcFhPeD+S2+EG3n wG3opCn0yAnntS5gvKHMvDVkxksaktRLgvfs3PaZ0hn4A3sO3pNYhRs1IUrGvVbX f7DVa3I+BcEzIOjmrf/j+MV3Bh57uy33y7TQgYW8FAyzwdK0p943HfMslZigifIl hiNpAE76yczxB9IF4cjnGA4x2v3wjPdRQbErMMh2NG+wFP+M1FCsgky7yAfi0wMp DKy5+MQazv0SeTc1IUXwxd5crbD+anvV7Fgh5G/mNZg== 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=fm2; bh=FbUQKM O8qYDHss8mukOiW05RnQfW2lZMYAVLSvay4cs=; b=LTDXLzZ6q9Ozrs5lhd6PfA 08lQY3BXvULyNm8luDjyiPURtysW2qbuFZat1L9GJiizdCOb6KwEPr+fx8unorm9 MsQUBWiMgO77AVIHtjvAZwl4/YHj9Hu0R3mT7ASEP1E7jFECo4zPV6aV6IXdCVvA ZzoyhJLibjPaXQPpWShWOcsR12dH4zwe+7HgDidOT4ASIK6XJutpTatlfgS8uirq WL5JLziwmZeoxP93XIfAQvRhSyNuiStM7r6jEIGoawQCHaipGZe6K1d4OvpdMM/l j3ibyPttMoKOdiB/RpzvTxj+cY9kT+jstyDbcFPcPWQkyEB97RNtvpDXWrcSUT/w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudduiedguddvhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefuvfhfhfhokffffgggjggtsegrtderredtfeejnecuhfhrohhmpefmvghn ucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucffoh hmrghinhepihgvthhfrdhorhhgnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrg hsthhmrghilhdrtghomh 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 2D7E13280059; Sun, 8 Mar 2020 15:16:57 -0400 (EDT) To: Alexey Melnikov , Benjamin Schwartz Cc: jmap@ietf.org References: <0f7388d8-b420-469f-8d5a-da5fb0bcf27a@www.fastmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <2cc03bd6-48e3-3953-f9ba-59fbc26054a7@fastmail.com> Date: Sun, 8 Mar 2020 15:16:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <0f7388d8-b420-469f-8d5a-da5fb0bcf27a@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------25223F1EEBA4FDE59F893AAC" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Benjamin Schwartz comments on draft-ietf-jmap-websocket-05 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 19:17:02 -0000 This is a multi-part message in MIME format. --------------25223F1EEBA4FDE59F893AAC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/21/20 7:45 AM, Alexey Melnikov wrote: > Hi, > > ********************************************************************** > * Note, that I am conducting an experiment when people aspiring to be* > * Area Directors get exposed to AD work ("AD shadowing experiment"). * > * As a part of this experiment they get to review documents on IESG * > * telechats according to IESG Discuss criteria document and their * > * comments get relayed pretty much verbatim to relevant editors/WGs. * > * As an AD I retain responsibility in defending their position when * > * I agree with it. * > * Recipients of these reviews are encouraged to reply to me directly * > * about perceived successes or failures of this experiment. * > ********************************************************************** > > I also have some comments on Benjamin's comments below marked with "[[Alexey]]:" > > > The following comments were provided by Benjamin Schwartz : > > Benjamin would have balloted *YES* on this document. He wrote: > > ## Section 3 > > > Consider removing “webSocket” from the parameter names.  It is redundant within this context. Done. > ## Section 4 > > >    Binary data MUST NOT be uploaded or downloaded >    through a WebSocket JMAP connection. > > > Please provide a motivation for this restriction. > > [[Alexey: In standard JMAP these operations are performed on special HTTPS endpoints, so no JMAP objects are exchanged there. This document just does the same.]] To Alexey's point, the very next sentence states "Binary data is handled per Section 6 of [RFC8620] via a separate HTTP connection or stream." > ## Section 4.1 > > > I would suggest replacing this MUST with a simple reference to Section 8.2, which can contain its own normative language. > > [[Alexey: Ben, can you clarify why you suggest pointing to Section 8.2? Is this in another RFC?]] Same question as Alexey.  To which Section 8.2 are you referring? > ## Section 4.3.2 > > > Is “@type” now required on all Request/Response/Problem Details objects everywhere?  Does this update RFC 8620? Alexey, I'll let you decide is this document updates RFC 8620. -- Ken Murchison Cyrus Development Team Fastmail US LLC --------------25223F1EEBA4FDE59F893AAC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 2/21/20 7:45 AM, Alexey Melnikov wrote:
Hi,

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly * 
* about perceived successes or failures of this experiment.          *
**********************************************************************

I also have some comments on Benjamin's comments below marked with "[[Alexey]]:"


The following comments were provided by Benjamin Schwartz <bemasc@google.com>:

Benjamin would have balloted *YES* on this document. He wrote:

## Section 3


Consider removing “webSocket” from the parameter names.  It is redundant within this context.


Done.



## Section 4


   Binary data MUST NOT be uploaded or downloaded
   through a WebSocket JMAP connection.


Please provide a motivation for this restriction.

[[Alexey: In standard JMAP these operations are performed on special HTTPS endpoints, so no JMAP objects are exchanged there. This document just does the same.]]


To Alexey's point, the very next sentence states "Binary data is handled per Section 6 of [RFC8620] via a separate HTTP connection or stream."


## Section 4.1


I would suggest replacing this MUST with a simple reference to Section 8.2, which can contain its own normative language.

[[Alexey: Ben, can you clarify why you suggest pointing to Section 8.2? Is this in another RFC?]]


Same question as Alexey.  To which Section 8.2 are you referring?


## Section 4.3.2


Is “@type” now required on all Request/Response/Problem Details objects everywhere?  Does this update RFC 8620?


Alexey, I'll let you decide is this document updates RFC 8620.


-- 

Ken Murchison
Cyrus Development Team
Fastmail US LLC
--------------25223F1EEBA4FDE59F893AAC-- From nobody Sun Mar 8 17:41:42 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 693423A0CA7; Sun, 8 Mar 2020 17:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=doehUBGB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k/TEZsTF 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 umZ0HUkrM4D9; Sun, 8 Mar 2020 17:41:35 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED5F73A0CA6; Sun, 8 Mar 2020 17:41:34 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4C9B521FAE; Sun, 8 Mar 2020 20:41:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 08 Mar 2020 20:41:34 -0400 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=fm2; bh=m tDgNM7nIrtp0oaiiJ5+B3JrlGymVFfBDTsip2p0PVw=; b=doehUBGB2EoLvfFMm oCX/A0ahDrFAYjXzU8iruOScScFWZk66FkOjp7Y5qSSNKISnaZ1bxP5X4hRmcSJt Gms1uR4dNO0rDX7+MQA4enDWYP7UIZnRR7+sJFHHAfHD4xI+eops2+h6O0hb5wSw gcmd2B7ie6bkJ+sFRw/fk92Udhr2GTFnpwf3Q3bImbquz6EyZ3f8ro73ewp5YnSZ 46Ns9UweZxYI2Oxz0E4U35ZBdtCT+PmwrGRIOi+Ela0TqDQ+7LBbkRqe354y3RJd vO1zUOGNBIPVRQgF7taVByC6S+u4myGAVzQ8pGkVUUgtM2aK3FJsX6v9MnsaPIgA GyV8g== 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=fm2; bh=mtDgNM7nIrtp0oaiiJ5+B3JrlGymVFfBDTsip2p0P Vw=; b=k/TEZsTF3DHufEHV5g64UsE1fJpMnbsp120Rq4IPg1/+o3F6WgLb+fAYE aZ8+mi/cFZUl8wwwTXtsqC0WWcnwtQVlA9ftqfyTGGJcFqHWDcxRSiTjwHfD/36S rxx4yTHFK160Km2IISGPaLS5gRZuLBeN532OPHzAxOh50u+Pl/2TIkQ1JaYHtt4c 24VsibmKJvcQ1b06MWPA5SLPP5rC94DSgAjpDVDuDUkVMjHKeDWzfXNDdwkCdmCp KysTNiDuflp/Esx/+3yHMjcveHPpWNvLl/bajJJT+J/TTEaxHlxvCVM5Fua9cfLR +sw2ABkjwxjZcCZigz20pgGNFiVnQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddujedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghn ucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucfkph epjeegrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm 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 73AB030612AF; Sun, 8 Mar 2020 20:41:33 -0400 (EDT) To: Benjamin Kaduk Cc: The IESG , draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, jmap@ietf.org References: <157843131129.21019.4453575321747210277.idtracker@ietfa.amsl.com> <20200218001446.GB43614@kduck.mit.edu> From: Ken Murchison Organization: FastMail US LLC Message-ID: <892091b3-1aa9-5aef-2cf8-c076962f5812@fastmail.com> Date: Sun, 8 Mar 2020 20:41:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200218001446.GB43614@kduck.mit.edu> 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, 09 Mar 2020 00:41:37 -0000 Hi Benjamin, Is the scenario that you outline below related to just use of compression where an attacker is injecting content? And are you suggesting that including IDs in each request can help detect and mitigate such an attack? On 2/17/20 7:14 PM, Benjamin Kaduk wrote: > Hi Ken, > > Sorry for the slow response time: I tried a few times to dig into things > but each time had failed to allocate a large enough time slot to pull up > the needed state. > > On Mon, Jan 20, 2020 at 03:02:11PM -0500, Ken Murchison wrote: >> 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. > Thanks for the updates in the -05; they help quite a lot. (I will have > some more comments under separate cover, but respond here on the > "out-of-order" topic.) > >> 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. > I must apologize for the handwaviness of the following, as I seem to have > forgotten a fair amount of how JMAP works. > > At a very high level, the idea is that in JMAP, each request has an > associated response, and the basic response object is just a JSON object > with methodResponses, sessionState, and optional createdIds. The concern > would be if a naive client could make two requests with similar enough > methodCalls that the corresponding methodResponses could be matched up to > the "wrong" requests. It's not exactly trivial to construct an example of > how this would happen, though, given how the response object is roughly the > request object with additional outputs appended. That said, if the method > in question was something weird and side-effect-ful like "return an element > from an array of names, without replacement, obtained by using the next > number from the fibonnacci sequence (modulo the size of the array) as index > into the array", it seems likely that the client could get confused about > which response came when the array of names was size N and which when it > was size N-1. (Yes, this is a ridiculously contrived example, but this is > a general protocol that needs to handle whatever we throw at it.) I guess > it may be enough to just note that when a client is making "identical > requests" in parallel it needs to use request IDs to associate the > responses. > > Does that help? > > -Ben -- Ken Murchison Cyrus Development Team Fastmail US LLC From nobody Mon Mar 9 13:03:13 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2139B3A16AA for ; Mon, 9 Mar 2020 13:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 wWGhcmytAYhq for ; Mon, 9 Mar 2020 13:03:05 -0700 (PDT) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EF63A16A1 for ; Mon, 9 Mar 2020 13:03:04 -0700 (PDT) Received: by mail-yw1-xc31.google.com with SMTP id x184so11420230ywd.6 for ; Mon, 09 Mar 2020 13:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=it+SP14Mfj9tjzXvNJc6bKx0zquNU35af9X4QYc5OJU=; b=MDFzJmwSy3FVDLgsKDF03QkwFRIbb9toIvmzIWR6rMcMlGcmlbT/+NmnuTxKBYAE6R cEqpUWeJFbX4YymURETCJhaGNS3VinujN5BYXM30PS1XKIo07gmD8Sb5p1DpZa6OBSWD eFl9GxYLopqcwbXqi6INWXWM+lzrzbacAT/6RmPIHGu/jqRH0DJGOqAqj9GvwerU0mCV uBiyxHdCO6d3NEaFiWpwgJt2u0CzgHqeMdpNFdp9wpMyHPBdMgPG3M3nU3ZZ1Vp/9wqE GettXua6QIMKl+F85LjEXI+KGHNBfKipWQaYPj+AoKUbFSzLnQlEXCrUdRgXaBa0Nq80 epOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=it+SP14Mfj9tjzXvNJc6bKx0zquNU35af9X4QYc5OJU=; b=tCMw209vrJy5xIGfn5l/6w6YDC8UHCIuJrNIKfTKz2AZcyoCYXSq9l3sxVjw8BNxdo 5r2HR2wuhMavpAbe0AXIM60ufLYtQax+inE5PFiCVzKrTMsTnCehKgoJswCuSf8gQZ1a b8WQGm+Le7FoGEGoYsqrYGEYydz5bQgKis/WKoFQugSMnMYI24kJTeqTXse0TpHdVAkO u0W7XrAXHEPh4SzK5SLwhWJxuWMfKPm9EnuSs9zKOSTfCO4Ygtpbm3HspBjeW30YJdAd s0lcXTN2XAhixMIZjZqSG4Rh8GMiUPFfCu9JpwaSAXqkNCVFoL8a5iAPVkZOY9VPsFNk 2Q4A== X-Gm-Message-State: ANhLgQ1OuIrHGQ8lmTrkIwjSslIQP4QP/8G74SdHWyX6WmAaHeVUPMX0 86vUZ8Z3HsYUJRJNqTmkDFihfuwR5n+1nrltbyRrHg== X-Google-Smtp-Source: ADFU+vvzf9t3rvg94LiIVDIgaOhlaC70F1JX/iwkmzWXWs89AgfI0g2+b3BAgX44ZN8PFJiqdyYFp67gdsFCynuC+lY= X-Received: by 2002:a25:234f:: with SMTP id j76mr17435428ybj.502.1583784183627; Mon, 09 Mar 2020 13:03:03 -0700 (PDT) MIME-Version: 1.0 References: <0f7388d8-b420-469f-8d5a-da5fb0bcf27a@www.fastmail.com> <2cc03bd6-48e3-3953-f9ba-59fbc26054a7@fastmail.com> In-Reply-To: <2cc03bd6-48e3-3953-f9ba-59fbc26054a7@fastmail.com> From: Ben Schwartz Date: Mon, 9 Mar 2020 16:02:52 -0400 Message-ID: To: Ken Murchison Cc: Alexey Melnikov , jmap@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b51e3705a0717d7a" Archived-At: Subject: Re: [Jmap] Benjamin Schwartz comments on draft-ietf-jmap-websocket-05 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, 09 Mar 2020 20:03:12 -0000 --000000000000b51e3705a0717d7a Content-Type: multipart/alternative; boundary="000000000000aafca505a0717dbd" --000000000000aafca505a0717dbd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 8, 2020 at 3:16 PM Ken Murchison wrote: > > On 2/21/20 7:45 AM, Alexey Melnikov wrote: > > Hi, > > ********************************************************************** > * Note, that I am conducting an experiment when people aspiring to be* > * Area Directors get exposed to AD work ("AD shadowing experiment"). * > * As a part of this experiment they get to review documents on IESG * > * telechats according to IESG Discuss criteria document and their * > * comments get relayed pretty much verbatim to relevant editors/WGs. * > * As an AD I retain responsibility in defending their position when * > * I agree with it. * > * Recipients of these reviews are encouraged to reply to me directly * > * about perceived successes or failures of this experiment. * > ********************************************************************** > > I also have some comments on Benjamin's comments below marked with "[[Ale= xey]]:" > > > The following comments were provided by Benjamin Schwartz : > > Benjamin would have balloted *YES* on this document. He wrote: > > ## Section 3 > > > Consider removing =E2=80=9CwebSocket=E2=80=9D from the parameter names. = It is redundant within this context. > > > Done. > > > > ## Section 4 > > > Binary data MUST NOT be uploaded or downloaded > through a WebSocket JMAP connection. > > > Please provide a motivation for this restriction. > > [[Alexey: In standard JMAP these operations are performed on special HTTP= S endpoints, so no JMAP objects are exchanged there. This document just doe= s the same.]] > > > To Alexey's point, the very next sentence states "Binary data is handled > per Section 6 of [RFC8620] > via a > separate HTTP connection or stream." > Yes, the text is perfectly clear as to what you're supposed to do, but it's not at all clear as to why this restriction is necessary. If the restriction is "intrinsic" to the protocol then it's not a normative requirement, because the forbidden action is inexpressible. Otherwise, the restriction must have been imposed for some reason, but the text doesn't say why. Uploading binary data through the WebSocket seems potentially useful (e.g. to gain the benefits of compression, as mentioned elsewhere in the draft). If there's a good reason to forbid it, I suggest mentioning that. Otherwise, I would remove the requirement. ## Section 4.1 > > > I would suggest replacing this MUST with a simple reference to Section 8.= 2, which can contain its own normative language. > > [[Alexey: Ben, can you clarify why you suggest pointing to Section 8.2? I= s this in another RFC?]] > > > Same question as Alexey. To which Section 8.2 are you referring? > RFC 8620. This text is attempting to use "MUST" to regulate not the software's behavior, but the implementor's state of mind. In my view, this is not good use of RFC 2119 language. I recommend simply reminding the reader to review Section 8.2 of RFC 8620, or perhaps explaining why those recommendations are especially important in this context. > > ## Section 4.3.2 > > > Is =E2=80=9C@type=E2=80=9D now required on all Request/Response/Problem D= etails objects everywhere? Does this update RFC 8620? > > > Alexey, I'll let you decide is this document updates RFC 8620. > My point is that the text is unclear. I presume that the line "This specification adds two extra arguments to the Request object" doesn't apply to all Request objects, but only to Request objects that are sent over a WebSocket. However, the text doesn't say that. I would suggest noting that this specification uses an extended object encoding from RFC 8620, so that the distinction can be described explicitly. > > -- > > Ken Murchison > Cyrus Development Team > Fastmail US LLC > > --000000000000aafca505a0717dbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Mar 8, 2020 at 3:16 PM Ken Mu= rchison <murch@fastmail.com>= ; wrote:
=20 =20 =20


On 2/21/20 7:45 AM, Alexey Melnikov wrote:
Hi,

**********************************************************************
* Note, that I am conducting an experiment when people aspiring to be*
* Area Directors get exposed to AD work ("AD shadowing experiment"=
;). *
* As a part of this experiment they get to review documents on IESG  *
* telechats according to IESG Discuss criteria document and their    *
* comments get relayed pretty much verbatim to relevant editors/WGs. *
* As an AD I retain responsibility in defending their position when  *
* I agree with it.                                                   *
* Recipients of these reviews are encouraged to reply to me directly *=20
* about perceived successes or failures of this experiment.          *
**********************************************************************

I also have some comments on Benjamin's comments below marked with &quo=
t;[[Alexey]]:"


The following comments were provided by Benjamin Schwartz <bemasc@google.com>:

Benjamin would have balloted *YES* on this document. He wrote:

## Section 3


Consider removing =E2=80=9CwebSocket=E2=80=9D from the parameter names.=C2=
=A0 It is redundant within this context.


Done.



## Section 4


=C2=A0 =C2=A0Binary data MUST NOT be uploaded or downloaded
=C2=A0 =C2=A0through a WebSocket JMAP connection.


Please provide a motivation for this restriction.

[[Alexey: In standard JMAP these operations are performed on special HTTPS =
endpoints, so no JMAP objects are exchanged there. This document just does =
the same.]]


To Alexey's point, the very next sentence states "Binary da= ta is handled per Section 6 of [RFC8620] via a separate H= TTP connection or stream."

Yes, the text is perfectly c= lear as to what you're supposed to do, but it's not at all clear as= to why this restriction is necessary.=C2=A0 If the restriction is "in= trinsic" to the protocol then it's not a normative requirement, be= cause the forbidden action is inexpressible.=C2=A0 Otherwise, the restricti= on must have been imposed for some reason, but the text doesn't say why= .

Uploading binary data through the WebSocket seem= s potentially useful (e.g. to gain the benefits of compression, as mentione= d elsewhere in the draft).=C2=A0 If there's a good reason to forbid it,= I suggest mentioning that.=C2=A0 Otherwise, I would remove the requirement= .

## Section 4.1


I would suggest replacing this MUST with a simple reference to Section 8.2,=
 which can contain its own normative language.

[[Alexey: Ben, can you clarify why you suggest pointing to Section 8.2? Is =
this in another RFC?]]


Same question as Alexey.=C2=A0 To which Section 8.2 are you referrin= g?

RFC 8620.=C2=A0 This text is attempting to us= e "MUST" to regulate not the software's behavior, but the imp= lementor's state of mind.=C2=A0 In my view, this is not good use of RFC= 2119 language.=C2=A0 I recommend=C2=A0simply reminding the reader to revie= w Section 8.2 of RFC 8620, or perhaps explaining why those recommendations = are especially important in this context.


## Section 4.3.2


Is =E2=80=9C@type=E2=80=9D now required on all Request/Response/Problem Det=
ails objects everywhere?=C2=A0 Does this update RFC 8620?


Alexey, I'll let you decide is this document updates RFC 8620.

My point is that the text is unclear.=C2=A0 I pre= sume that the line "This specification adds two extra arguments to the= Request object" doesn't apply to all Request objects, but only to= Request objects that are sent over a WebSocket.=C2=A0 However, the text do= esn't say that.=C2=A0 I would suggest noting that this specification us= es an extended object encoding from RFC 8620, so that the distinction can b= e described explicitly.


-- 

Ken Murchison
Cyrus Development Team
Fastmail US LLC
--000000000000aafca505a0717dbd-- --000000000000b51e3705a0717d7a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1 V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCBUiAbsgmFRWxWuTS6FkX9o+WjubIg1XxtvGyLvvGMuZjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDAzMDkyMDAzMDRaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEATcBQ5t5rDwTdlk6Zp8tlDJylKXwxoyiAZcy4ZPNJMhO157KUO5pS/ONRjQ6jHEEZC8thcCV7 s9wWWRYBGEJC8c8xL8eSxtS7eZUitc1P1pFro2xI6eant8vAvDeqhUkFH57dDoW2FhZDo+8Wj3wq oPYjsWIFV0tW3gAfMN7MeZzaGJ/33IbwItFBy1uwczNlIyf30i/HzWt2ihLeN4CvSVWhgk3rWplW lkU0CSOkCze6Jc1x/G84tP/FSUJSuCQalTcyshfRLWXT3ftNP4atiGuPLeDnAQhl2hIdmTAkUDVY d3RtB52NE8PpQSR6T0SEp83Aw+CcNYRz+/0ynxcIxw== --000000000000b51e3705a0717d7a-- From nobody Mon Mar 9 16:24:09 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 43C393A0924; Mon, 9 Mar 2020 16:24:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <158379624821.5446.11844161405344108630@ietfa.amsl.com> Date: Mon, 09 Mar 2020 16:24:08 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-websocket-06.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 23:24:08 -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-06.txt Pages : 16 Date : 2020-03-09 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. Open Issues o Still need to craft some text to discuss/address potential security risks of using WebSocket compression. 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-websocket-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-websocket-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 16:55:22 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 27DAE3A0A4E; Mon, 9 Mar 2020 16:54:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <158379809610.5477.17387147726957749154@ietfa.amsl.com> Date: Mon, 09 Mar 2020 16:54:56 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-calendars-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 23:55:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Calendars Authors : Neil Jenkins Michael Douglass Filename : draft-ietf-jmap-calendars-02.txt Pages : 38 Date : 2020-03-09 Abstract: This document specifies a data model for synchronizing calendar data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-calendars-02 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-calendars-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-calendars-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 18 10:23:59 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 22B603A1907 for ; Wed, 18 Mar 2020 10:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=j8Tsu4U5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bJ0J6fmF 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 RIWNNj9Mn69j for ; Wed, 18 Mar 2020 10:23:55 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD46C3A1906 for ; Wed, 18 Mar 2020 10:23:55 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id D7E3549D; Wed, 18 Mar 2020 13:23:54 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute3.internal (MEProxy); Wed, 18 Mar 2020 13:23:55 -0400 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=yGSLK6CdZVzSl4dDXUdUKFfNerumIkW rwIqkAhlQiwg=; b=j8Tsu4U55tVAThq9l7ZuLUVVWJS0Id+snieX1F6wbsDfTK/ TffXy+CuoImu22tB6hVF+JzW6fa7G440k3IGzyyHXrV8Jj7dE0ejy2BBo3Gg+DGC hLWx5MEPhdYKRBex/8jV4xXuUHGLZ5ievyPx1t83PpGicyrQnXPz4yEn/HAvNo/n SEqxQEvRvDoIm5FR9/PAeMrpEYF+Z656dSptsXAYplX41ybaZW4lGbxVQCEvt2lm 9jj0le03eNXrJFS90V8KQ43N70w6ach1UFZWWWXyudAZyDxBwv+tiUtnBAIOmzmR zcxmIS1eEBc5UPWTJ4P3zEv3+hyoYZOcGCPR47A== 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=fm2; bh=yGSLK6 CdZVzSl4dDXUdUKFfNerumIkWrwIqkAhlQiwg=; b=bJ0J6fmF5NMKmcRStRAcSz ILooFOc9FKU1ArqqfRMYxRVL+KIUV3G0lgAA77dGqcn4QF3BRv64q+I0qFAVgcTf a1z21iGZEOkl6sTSvsy5QUGbUXH/rB/4rxg94+fHQJmXJuJWgYzBy1qTpiR/vuwW p0739Dnkcw1ONgNgcnwK6EZ4F/OeXf1gYRqzuzM3R8gXdcZNmx5BYI6XDz+kH8Yz p4utbIb44dA6I6/tocNA2/Wc6kW6hxnmeLApXklf4ir/rlQeW7zq7hf5YMH/3Zv2 l9Ee9dfCwTBMgVbmP0tDx4uJ3XnznyqhycMiB8qLX5CafbPNc6gCVr7WxNyGQqxQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 47D46660069; Wed, 18 Mar 2020 13:23:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: <533b2c05-eda9-48df-8564-50e14e43acc3@www.fastmail.com> In-Reply-To: References: <0f7388d8-b420-469f-8d5a-da5fb0bcf27a@www.fastmail.com> <2cc03bd6-48e3-3953-f9ba-59fbc26054a7@fastmail.com> Date: Wed, 18 Mar 2020 17:23:27 +0000 From: "Alexey Melnikov" To: "Benjamin Schwartz" , "Ken Murchison" Cc: jmap@ietf.org Content-Type: multipart/alternative; boundary=8d73a3d9df374c8c8663380fa88f3564 Archived-At: Subject: Re: [Jmap] Benjamin Schwartz comments on draft-ietf-jmap-websocket-05 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, 18 Mar 2020 17:23:57 -0000 --8d73a3d9df374c8c8663380fa88f3564 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ken, On Mon, Mar 9, 2020, at 8:02 PM, Ben Schwartz wrote: > On Sun, Mar 8, 2020 at 3:16 PM Ken Murchison wrot= e: >> On 2/21/20 7:45 AM, Alexey Melnikov wrote: >>> ## Section 4.3.2 Is =E2=80=9C@type=E2=80=9D now required on all Request/Response/Problem = Details objects everywhere?=C2=A0 Does this update RFC 8620? >>=20 >> Alexey, I'll let you decide is this document updates RFC 8620. > My point is that the text is unclear. I presume that the line "This sp= ecification adds two extra arguments to the Request object" doesn't appl= y to all Request objects, but only to Request objects that are sent over= a WebSocket. However, the text doesn't say that. I would suggest noting= that this specification uses an extended object encoding from RFC 8620,= so that the distinction can be described explicitly. I think clarifying whether this is a generic extension or WebSocket spec= ific, would be useful. Best Regards, Alexey --8d73a3d9df374c8c8663380fa88f3564 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Ken,

On Mon, Mar 9, 2020, at 8:02 PM, Ben Schwartz wrot= e:
On Sun, = Mar 8, 2020 at 3:16 PM Ken Murchison <murch@fastmail.com> wrote:
On 2/21/20 7= :45 AM, Alexey Melnikov wrote:
<= br>
## Section 4.3.2=



Is =E2=80=9C@type=E2=80=9D now required on all Request/Response/Problem =
Details objects everywhere?  Does this update RFC 8620?


Alexey, I'll let you decide is this document up= dates RFC 8620.

My point is that the text= is unclear.  I presume that the line "This specification adds two = extra arguments to the Request object" doesn't apply to all Request obje= cts, but only to Request objects that are sent over a WebSocket.  H= owever, the text doesn't say that.  I would suggest noting that thi= s specification uses an extended object encoding from RFC 8620, so that = the distinction can be described explicitly.
I think clarifying whether this is a generic extension or We= bSocket specific, would be useful.

Best Reg= ards,
Alexey
--8d73a3d9df374c8c8663380fa88f3564-- From nobody Wed Mar 18 10:43: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 821653A1992 for ; Wed, 18 Mar 2020 10:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 wJEG2M7xfXJo for ; Wed, 18 Mar 2020 10:42:54 -0700 (PDT) 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 216B53A195F for ; Wed, 18 Mar 2020 10:42:53 -0700 (PDT) Received: from linagora.com (unknown [10.233.69.48]) by outgoing.linagora.com (Postfix) with ESMTP id 16F443B; Wed, 18 Mar 2020 17:42:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1584553372; bh=J+xtD/QgjRJLNw0q1aKFyIgTQaBV0ZNmA/TYi5SMjF8=; h=From:Reply-To:To:Subject:Date:References:In-Reply-To:From; b=GBpclY9ifv+U4zsfZaJCzzWx0BS9ZY+iYhz2Zbnl3kES12yOQf1Pa1awbM46/ES94 1nDGYrmqMgyV6o5OL+Ab5AeCn6UTeCrjChCnzqhzMaysO/Xt7k4EeEyz6QanbXpxhK tmbnUM6GC0IqPxxzO4m9EqmXw6ekBTDt/wTGBDDqEpHqgY19d7o8wlC8GR230wlzyv NyhdNYW241MGbt6ITbie9MNFKQJnpzmZHK1O6QYTl5MnLPJ6zjl/Ywlnen3pxUo3J/ WnbcqUHLqofDOZ/8MAUFRvXV2u67Qlkd3mDuxYNNyNJbpNbCpMYCgQlKseFcTW8D6a oNb+0axCHXXVg== 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" , Ken Murchison Message-ID: Date: Wed, 18 Mar 2020 17:42:46 +0000 References: In-Reply-To: Archived-At: Subject: Re: [Jmap] draft-ietf-jmap-mdn-06 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, 18 Mar 2020 17:43:02 -0000

Hello,

Le 6 mars 2020 20:35, de murch@fastmail=2Ecom

On 3/5/20 7:40 PM, Ken Murchison wrote:
> A few que= stions as I implement this in Cyrus:
>
> - forEmailId is allowe= d to be null, presumably just for MDN/parse
> responses=2E  Sho= uld we mandate that it be non-null for MDN/send,
> because otherwise= , what's the point?


Exactly=2E I'm adding a w= ord about this=2E


> - subject and textB= ody are both allowed to be null=2E  Should we
> recommend defau= lt text for both?


I think it asks more questi= ons than it solves an issue=2E How the server can choose the good language = to send the notification?


> - The JMAP = server may not be able to determine the Final-Recipient of
> the ori= ginal message was Bcc'd or sent to an alias=2E  Should the MDN
>= ; object include a 'from' property?


It sh= ould match the email of the account, no?

Or maybe we should ask for a= n identity when sending an MDN, so that the user can choose which email app= ears in this field?



Also, do we need a specif= ic error type if the email corresponding to
fromEmailId does NOT have a= Disposition-Notification-To header?  Or do
we use invalidProperti= es, forbidden, invalidEmail, noRecipients?



I= t seems I missed the notFound error, I'm adding it=2E


Rega= rds,

Rapha=C3=ABl Ouazana=2E

From nobody Wed Mar 18 10:49:46 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 3781F3A1970; Wed, 18 Mar 2020 10:49:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <158455378410.30024.7731600544146950337@ietfa.amsl.com> Date: Wed, 18 Mar 2020 10:49:44 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-07.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 17:49:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : Handling Message Disposition Notification with JMAP Author : Raphaël Ouazana Filename : draft-ietf-jmap-mdn-07.txt Pages : 12 Date : 2020-03-18 Abstract: This document specifies a data model for handling [RFC8098] MDN messages with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mdn-07 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mdn-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 18 11:04:09 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9F13A19A3 for ; Wed, 18 Mar 2020 11:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=SSPVo72s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jJF+lmnc 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 7mFaF8G0kfLn for ; Wed, 18 Mar 2020 11:04:01 -0700 (PDT) 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 A30783A199D for ; Wed, 18 Mar 2020 11:03:56 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 229305C01C5; Wed, 18 Mar 2020 14:03:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 18 Mar 2020 14:03:52 -0400 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; s=fm2; bh=jqIh3p09Y/FdKz4Q2WTxKkM1mOn 2CdEE/YRW7JvDx/M=; b=SSPVo72sUq5ukM27OcblCs56vRxK4PfM988vYxIFv2r kfMQFFcIJeKhBmAvZ2TEC6bPE690QdPBZTOyvcw89yZ9YjsmdcTGmLHIEvD5UBaw 7BQ/2PrtUCs5V13PgxWgWWAkqfcWqX3vhfpgkrP5hORfSEu2BjZDCd8loTqWi93u llENWIpZETRWsNEdZt63hrVnBc16NUN0xkccsSHQuvzEdbWbhKLSYq4iPHIKh4lI A7sAA2rPwdaKYJmJwMm1YV9MoC4rOZLiTQhnn+b5ZbDL4exCIlXzy4tn1GMpx+eJ FuadR8xrReq73XdWG5Ojm9YBTJd1JGQZD4R+2gOxIKg== 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=fm2; bh=jqIh3p 09Y/FdKz4Q2WTxKkM1mOn2CdEE/YRW7JvDx/M=; b=jJF+lmncYB4yvnhcVXYvG7 obk5QvbK8T8j4qrfgsfgg4HNFZxrUyydZc1ytZdTHSJwtFsgF3iLdFbKISWnSqC+ THRNzUZFb7revdDkAzjHcw/3hgy7atHyVOYRANxGDpKjJDQfVjK89y4BNvvQxIxY vyf65Z5RG8Z1/abyI4CHOXohCRynE7VOXznbZ1CfdGgIFFBcC8edcDuZlKN+/dff hSNBDi9AkJXoC0ByedrTQTAz3Lea67GZluc4CW6wFAMWS0IqmBSQF1nRkMl50eUA B3bEpbN0WVzXmipL4/EqauDxhV/CeYS7uvaeHhiDOeTHHEtZ7XhZacx03WfbWirA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefuvfhfhfhokffffgggjggtsegrtderredtfeejnecuhfhrohhmpefmvghn ucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucfkph epjeegrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm 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 39B5730618C1; Wed, 18 Mar 2020 14:03:51 -0400 (EDT) To: Alexey Melnikov , Benjamin Schwartz Cc: jmap@ietf.org References: <0f7388d8-b420-469f-8d5a-da5fb0bcf27a@www.fastmail.com> <2cc03bd6-48e3-3953-f9ba-59fbc26054a7@fastmail.com> <533b2c05-eda9-48df-8564-50e14e43acc3@www.fastmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <7b28083d-a8ad-c7bb-838b-bd2cef6173d5@fastmail.com> Date: Wed, 18 Mar 2020 14:03:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <533b2c05-eda9-48df-8564-50e14e43acc3@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------79A927E493CED632D1FA87F6" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Benjamin Schwartz comments on draft-ietf-jmap-websocket-05 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, 18 Mar 2020 18:04:08 -0000 This is a multi-part message in MIME format. --------------79A927E493CED632D1FA87F6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/18/20 1:23 PM, Alexey Melnikov wrote: > Hi Ken, > > On Mon, Mar 9, 2020, at 8:02 PM, Ben Schwartz wrote: >> On Sun, Mar 8, 2020 at 3:16 PM Ken Murchison > > wrote: >> >> On 2/21/20 7:45 AM, Alexey Melnikov wrote: >> > >>> ## Section 4.3.2 >>> >>> >>> Is “@type” now required on all Request/Response/Problem Details objects everywhere?  Does this update RFC 8620? >> >> >> Alexey, I'll let you decide is this document updates RFC 8620. >> >> My point is that the text is unclear.  I presume that the line "This >> specification adds two extra arguments to the Request object" doesn't >> apply to all Request objects, but only to Request objects that are >> sent over a WebSocket.  However, the text doesn't say that.  I would >> suggest noting that this specification uses an extended object >> encoding from RFC 8620, so that the distinction can be described >> explicitly. > I think clarifying whether this is a generic extension or WebSocket > specific, would be useful. draft -06 has language like the following for each object type: The specification extends the Request object with two additional arguments when used over a WebSocket: Is that sufficient or do you have some alternative text that you'd like to suggest? -- Ken Murchison Cyrus Development Team Fastmail US LLC --------------79A927E493CED632D1FA87F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 3/18/20 1:23 PM, Alexey Melnikov wrote:
Hi Ken,

On Mon, Mar 9, 2020, at 8:02 PM, Ben Schwartz wrote:
On Sun, Mar 8, 2020 at 3:16 PM Ken Murchison <murch@fastmail.com> wrote:
On 2/21/20 7:45 AM, Alexey Melnikov wrote:

## Section 4.3.2


Is “@type” now required on all Request/Response/Problem Details objects everywhere?  Does this update RFC 8620?


Alexey, I'll let you decide is this document updates RFC 8620.

My point is that the text is unclear.  I presume that the line "This specification adds two extra arguments to the Request object" doesn't apply to all Request objects, but only to Request objects that are sent over a WebSocket.  However, the text doesn't say that.  I would suggest noting that this specification uses an extended object encoding from RFC 8620, so that the distinction can be described explicitly.
I think clarifying whether this is a generic extension or WebSocket specific, would be useful.


draft -06 has language like the following for each object type:

The specification extends the Request object with two additional
   arguments when used over a WebSocket:


Is that sufficient or do you have some alternative text that you'd like to suggest?

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC
--------------79A927E493CED632D1FA87F6-- From nobody Wed Mar 18 11:11:06 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 EB7BE3A19A1 for ; Wed, 18 Mar 2020 11:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=r9fdNp/i; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JQu+CVUK 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 MdMycMIqyz9a for ; Wed, 18 Mar 2020 11:10:52 -0700 (PDT) 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 35C223A19B4 for ; Wed, 18 Mar 2020 11:09:47 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 949305C01D1; Wed, 18 Mar 2020 14:09:44 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 18 Mar 2020 14:09:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm2; bh=grVr171c2e8NzidUOF/LTao0RxA r8ZTvoOW3jeBRRx8=; b=r9fdNp/iqN1uiQcr08yxUmCbpyaZXBFZG+Z4gH2U5VB W7Bovp5y4UBGUd9UByPtUYIFZiY0ERIMNJilAL2EYDkihHB+bCcWnoqX55q5s7Xo gMnoEBz9Uq0lYTDa2EMxl8SYLSH1FimaFpjIu6DJfEY0owwoeoXocP/KUaHI3Gm1 CzANoo/1n98EDwNZDupZNFXeAOTwV8IR+GiBgurd2MCiWA4TRfaByjLx0tWTAvrY AHjTIBLqoua3Vx+XjnB03SkNCSrDBxnjbQ5ZKoZ1enFSl29pDXrkqO/jeetkUdeQ 8AFDLXDdA+5sBUh7QIY+DtbQiWU2zQ3wuUXMjQOevzw== 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=fm2; bh=grVr17 1c2e8NzidUOF/LTao0RxAr8ZTvoOW3jeBRRx8=; b=JQu+CVUK3k1uDOVKvqVYIL 7n71Vx4lRGyCGF5CZk8Wg0EG9JYC5r19mzZLiWNsOfsDCBJqyarxlmM2Su0tPYLp FFNrws2h/t11WfAzENYmo4v1rGUyeHq/dVBNRHFC88DnFJ8dP7KW80MHSSZQ/DCv +Bzko/NjxeVjVd+vHwj92aTpPjjZJfJgD5O5vkafPQ1sJkaQh0tNxgsZyySeLn9A 2vw4aDcod/kHrCGWyQ2FPa40Ecq2ftxz+rPuHjsiTWaREyfatbDtYVo7ADA7p3uo AASNI5Zlq6dZE/9SEH2QtshtyncP0WMEZd8Qn7RJUvfZ/NkgzG2fnVpxgLYK2trg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhohfkffgfgggjtgesrg dtreertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehf rghsthhmrghilhdrtghomheqnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghs thhmrghilhdrtghomh 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 04C1830618C1; Wed, 18 Mar 2020 14:09:43 -0400 (EDT) To: rouazana@linagora.com, "jmap@ietf.org" References: From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Wed, 18 Mar 2020 14:09:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2D72674EA14F791BCADC9AEB" Content-Language: en-US Archived-At: Subject: Re: [Jmap] draft-ietf-jmap-mdn-06 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, 18 Mar 2020 18:11:03 -0000 This is a multi-part message in MIME format. --------------2D72674EA14F791BCADC9AEB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/18/20 1:42 PM, Raphael OUAZANA wrote: > > Hello, > > Le 6 mars 2020 20:35, de murch@fastmail.com > > On 3/5/20 7:40 PM, Ken Murchison wrote: > > A few questions as I implement this in Cyrus: > > > - The JMAP server may not be able to determine the > Final-Recipient of > > the original message was Bcc'd or sent to an alias. Should the MDN > > object include a 'from' property? > > > It should match the email of the account, no? > If the email was sent to an email alias and eventually delivered to the underlying account, the sender of the MDN might want to have the MDN use the alias so as not to leak the real address of the account. > Or maybe we should ask for an identity when sending an MDN, so that > the user can choose which email appears in this field? > Yes, that is what I was thinking.  If the user doesn't provide a from address, then we can default to the email of the account. -- Ken Murchison Cyrus Development Team Fastmail US LLC --------------2D72674EA14F791BCADC9AEB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 3/18/20 1:42 PM, Raphael OUAZANA wrote:

Hello,

Le 6 mars 2020 20:35, de murch@fastmail.com

On 3/5/20 7:40 PM, Ken Murchison wrote:
> A few questions as I implement this in Cyrus:

> - The JMAP server may not be able to determine the Final-Recipient of
> the original message was Bcc'd or sent to an alias.  Should the MDN
> object include a 'from' property?


It should match the email of the account, no?


If the email was sent to an email alias and eventually delivered to the underlying account, the sender of the MDN might want to have the MDN use the alias so as not to leak the real address of the account.


Or maybe we should ask for an identity when sending an MDN, so that the user can choose which email appears in this field?


Yes, that is what I was thinking.  If the user doesn't provide a from address, then we can default to the email of the account.

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC
--------------2D72674EA14F791BCADC9AEB-- From nobody Wed Mar 18 11:19:14 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 DB16F3A19CD for ; Wed, 18 Mar 2020 11:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=S9gvGI1o; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Fx/MuOv5 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 XpXRcCacF1kh for ; Wed, 18 Mar 2020 11:19:04 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FBBA3A19CA for ; Wed, 18 Mar 2020 11:19:04 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 20FD65CA; Wed, 18 Mar 2020 14:18:58 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute3.internal (MEProxy); Wed, 18 Mar 2020 14:18:58 -0400 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=3/sMYjNl5frIXm6rbai1NqzdZ9FVilD uQdse7KirlHI=; b=S9gvGI1oMpEzxnW7Iyy0MIDQCxrE+01CJ2w/KN7M5KqMQjn Ri0cneXTWO5jVWB3QOtzEGDJKtS3ZgQC9vsQ7tKUk0jkEq9zEKvltqNpQDEzCa4G 2jAq96nqqSFt8bp7YfnYtDcyWxVyqEZj0OqXs5YUpJNcY3FhPs64ovS2MQqzUfKs 2UURgE4jYXhhDtexJOZMybXXQdbPCdfMAgPw5pzZObmI6mNkip5qJ5F7tOyum5xc iZNEb3A6InVK4FY+qZ7LEn7jABJUFD1nZss/CVD2TXnRmAHPga5XNmhNXp2UUeOF sZx/2/n8lA5eqEL/2Hg6gnCxoc/wSgWpfgI+sdw== 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=fm2; bh=3/sMYj Nl5frIXm6rbai1NqzdZ9FVilDuQdse7KirlHI=; b=Fx/MuOv5mLAN4pOj0Cowh9 +6vn6ujKnmw8VezpLAsolRH68YREBXDQxO2bjOlhj//9U37NcLaInK36P5GXATDm UadZ30F6MBPcGiiUxDY2jxEZPjSCbga+c4ydV7vuh2z8TjuFaMqL+fxNbPZM+ril QuJq0VKtXPScqB2IPkI7Eftam12xtSr5hPDuhcG4j5dnU+cs+5bPJGT5nnWYFC8m lgo3hQ3zqaDydEOhPk6WsR0rrkUU2VReUhTWpT3it4FiPFgr2ox5Lueuvoh6iJa+ QeS+cADNBouKpmHISmdsUJZyYGB+wRSi/UNpELh6jPYwFh+75CPsS9Cx4ABD6g2g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudefjedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedftehl vgigvgihucfovghlnhhikhhovhdfuceorggrmhgvlhhnihhkohhvsehfrghsthhmrghilh drfhhmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2DEFC660069; Wed, 18 Mar 2020 14:18:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: In-Reply-To: <7b28083d-a8ad-c7bb-838b-bd2cef6173d5@fastmail.com> References: <0f7388d8-b420-469f-8d5a-da5fb0bcf27a@www.fastmail.com> <2cc03bd6-48e3-3953-f9ba-59fbc26054a7@fastmail.com> <533b2c05-eda9-48df-8564-50e14e43acc3@www.fastmail.com> <7b28083d-a8ad-c7bb-838b-bd2cef6173d5@fastmail.com> Date: Wed, 18 Mar 2020 18:18:36 +0000 From: "Alexey Melnikov" To: "Ken Murchison" , "Benjamin Schwartz" Cc: jmap@ietf.org Content-Type: multipart/alternative; boundary=a439a0fc38d04d16994468de68a48b68 Archived-At: Subject: Re: [Jmap] Benjamin Schwartz comments on draft-ietf-jmap-websocket-05 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, 18 Mar 2020 18:19:13 -0000 --a439a0fc38d04d16994468de68a48b68 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ken, On Wed, Mar 18, 2020, at 6:03 PM, Ken Murchison wrote: > On 3/18/20 1:23 PM, Alexey Melnikov wrote: >> Hi Ken, >>=20 >> On Mon, Mar 9, 2020, at 8:02 PM, Ben Schwartz wrote: >>> On Sun, Mar 8, 2020 at 3:16 PM Ken Murchison wr= ote: >>>> On 2/21/20 7:45 AM, Alexey Melnikov wrote: >>=20 >>>>> ## Section 4.3.2 Is =E2=80=9C@type=E2=80=9D now required on all Request/Response/Problem = Details objects everywhere?=C2=A0 Does this update RFC 8620? >>>>>=20 >>>>=20 >>>> Alexey, I'll let you decide is this document updates RFC 8620. >>> My point is that the text is unclear. I presume that the line "This = specification adds two extra arguments to the Request object" doesn't ap= ply to all Request objects, but only to Request objects that are sent ov= er a WebSocket. However, the text doesn't say that. I would suggest noti= ng that this specification uses an extended object encoding from RFC 862= 0, so that the distinction can be described explicitly. >> I think clarifying whether this is a generic extension or WebSocket s= pecific, would be useful. >=20 > draft -06 has language like the following for each object type: > The specification extends the Request object with two additional arguments when used over a WebSocket: This is sufficient. Thank you for checking. Best Regards, Alexey --a439a0fc38d04d16994468de68a48b68 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Ken,

On Wed, Mar 18, 2020, at 6:03 PM, Ken Murchison w= rote:
On 3/18/20 1:23 PM, Alexey Melnikov wrote:
Hi Ken,
On Mon, Mar 9, 2020, at 8:02 PM, Ben Schwartz wrote:
On Sun, = Mar 8, 2020 at 3:16 PM Ken Murchison <murch@fastmail.com> wrote:
On 2/21/20 7:45 AM, Alexey Me= lnikov wrote:
= 
## Sec=
tion 4.3.2


Is =E2=80=9C@type=E2=80=9D now required on all Request/Response/Problem =
Details objects everywhere?  Does this update RFC 8620?


Alexey, I'll let you decide is this= document updates RFC 8620.

My point is t= hat the text is unclear.  I presume that the line "This specification adds two extra arguments to the Request object" doesn't apply to all Request objects, but only to Request objects that are sent over a WebSocket.  However, the text doesn't say that. = I would suggest noting that this specification uses an extended object encoding from RFC 8620, so that the distinction can= be described explicitly.
I think clarifying whether this is a generic extension or WebSocket specific, would be useful.

draft -06 has language like the following for each object type:= 

The specification extends the Request =
object with two additional
   arguments when used over a WebSocket:
This= is sufficient. Thank you for checking.

Bes= t Regards,
Alexey

--a439a0fc38d04d16994468de68a48b68-- From nobody Thu Mar 19 03:17:59 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 4F61F3A2671 for ; Thu, 19 Mar 2020 03:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 nsQDX8C3tDpT for ; Thu, 19 Mar 2020 03:17:56 -0700 (PDT) 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 E36E53A108F for ; Thu, 19 Mar 2020 03:17:55 -0700 (PDT) Received: from linagora.com (unknown [10.233.69.48]) by outgoing.linagora.com (Postfix) with ESMTP id 5EC1D3B; Thu, 19 Mar 2020 10:17:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1584613073; bh=XQvOzEzIVNfbvdscpsxiWzqA6Ba+bJan5LHQRE5uqU0=; h=From:Reply-To:To:Subject:Date:References:In-Reply-To:From; b=laaVXGAiGJnZ4lLPmuXSS/Si6YUytfn2Hqf0/Dyx+WUi1+awZN4gU3pMe8ffjBBxi RJ6+ZKQTXnTYxz2/q8F3XJZqikqdNO76URD5FNh5mM4v4Cdf7AH8Qj3iun9kg14b82 Qg9m0RCdZQKfmiDUuj6suIZhO9zWqh15QlMYVVCT0vfcTN/Pp+9ybKsieVsR63d/E0 J9DHDaOZedUsLAl9T8XB27/lFvNphITllsa0zb6KJtUvYDQGWfg74RlHl+FFnLahHb /JAtyYBxnYWT1SjTbhDRRDY61NEMF/XpavjommShhB0ClmOwTvB9wjhz06t/dg+2SR bkob0OzheEa8A== MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Raphael OUAZANA Sender: Raphael OUAZANA Reply-To: rouazana@linagora.com To: "jmap@ietf.org" , Ken Murchison Message-ID: Date: Thu, 19 Mar 2020 10:17:18 +0000 References: In-Reply-To: Archived-At: Subject: Re: [Jmap] draft-ietf-jmap-mdn-06 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, 19 Mar 2020 10:17:58 -0000


Le 18 mars 2020 19:09, de murch@fastmail.com


On 3/18/20 1:42 PM, Raphael OUAZANA wrote:

Hello,

Le 6 mars 2020 20:35, de murch@fastmail.com

On 3/5/20 7:40 PM, Ken Murchison wrote:
> A few questions as I implement this in Cyrus:

> - The JMAP server may not be able to determine the Final-Recipient of
> the original message was Bcc'd or sent to an alias.  Should the MDN
> object include a 'from' property?


It should match the email of the account, no?


If the email was sent to an email alias and eventually delivered to the underlying account, the sender of the MDN might want to have the MDN use the alias so as not to leak the real address of the account.


Or maybe we should ask for an identity when sending an MDN, so that the user can choose which email appears in this field?


Yes, that is what I was thinking.  If the user doesn't provide a from address, then we can default to the email of the account.


I will add an identity parameter, like in MessageSubmission. I will make it mandatory because for me it's not clear how we can get an email address from an account.

Regards,

Raphaël.

From nobody Thu Mar 19 04:11: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 B56D33A274F; Thu, 19 Mar 2020 04:11:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <158461626647.13591.17307228886771580985@ietfa.amsl.com> Date: Thu, 19 Mar 2020 04:11:06 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-08.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 11:11:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : Handling Message Disposition Notification with JMAP Author : Raphaël Ouazana Filename : draft-ietf-jmap-mdn-08.txt Pages : 12 Date : 2020-03-19 Abstract: This document specifies a data model for handling [RFC8098] MDN messages with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mdn-08 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mdn-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 19 10:07:17 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 068523A0983; Thu, 19 Mar 2020 10:07:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <158463763092.15698.7584154542529725968@ietfa.amsl.com> Date: Thu, 19 Mar 2020 10:07:11 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-websocket-07.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 17:07:11 -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-07.txt Pages : 17 Date : 2020-03-19 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-websocket-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-websocket-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 19 11:45: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 9107B3A0D1C; Thu, 19 Mar 2020 11:45:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Cc: fenton@bluepopcorn.net, The IESG , rfc-editor@rfc-editor.org, Jim Fenton , alexey.melnikov@isode.com, draft-ietf-jmap-websocket@ietf.org, jmap@ietf.org, jmap-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158464352757.15886.9459465794736162970@ietfa.amsl.com> Date: Thu, 19 Mar 2020 11:45:27 -0700 Archived-At: Subject: [Jmap] Protocol Action: 'A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket' to Proposed Standard (draft-ietf-jmap-websocket-07.txt) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 18:45:28 -0000 The IESG has approved the following document: - 'A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket' (draft-ietf-jmap-websocket-07.txt) as Proposed Standard This document is the product of the JSON Mail Access Protocol Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-websocket/ Technical Summary: JMAP [RFC8620] defines a synchronization protocol that assumes that it is used over a secure transport protocol. The current HTTP binding for JMAP would require that each request be authenticated, which introduces significant overhead. The WebSocket binding defined in this document provides higher performance by allowing the connection to be authenticated once with subsequent requests taking advantage of the WebSocket state. Working Group Summary: This document represents the consensus of the JMAP working group. Given the small size of the working group, the number of comments on the draft was limited, and the primary interest was from participants from FastMail. This draft was generally uncontroversial in the working group. Document Quality: One known implementation of this draft exists for Cyrus. Personnel: The Document Shepherd for this document is Jim Fenton. The responsible Area Director is Alexey Melnikov. From nobody Thu Mar 19 22:43:37 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 CC2E13A15DE for ; Thu, 19 Mar 2020 22:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=BvQFcQWB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zZk7TYKV 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 URTPG607d7Oo for ; Thu, 19 Mar 2020 22:43:34 -0700 (PDT) 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 0F6493A1589 for ; Thu, 19 Mar 2020 22:43:33 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3201A681 for ; Fri, 20 Mar 2020 01:43:33 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 20 Mar 2020 01:43:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=dRR+y9Y iu02uA4KolNmxIkxPLMlb0VmlYQX0xe81eV0=; b=BvQFcQWB4fnGVFhEQcqgOL+ luAuZycadAW2haNhA4rO+fhvW4XlgK1weIiRX3dCd/te8bLBeb73Q4ojiMLILqvD Rj+7PYQqp8IR2xDDWojmM+zX93IKAK2oAooxd39qY6CMowMMCZVceankJ/3xIXWr it9riBrMVzNDhNtYmZCmzg0YBx4oTh1A6s0epJiuDi6DcWcjPKNz/xYscoIQBjTV QsULj/8ia1L+J9Z9jCNCFmtYU0FfGCvuVcMfN+ASHIDNzQNLvzJHqC+FDO/lY+76 npSJJeJ+hiLZRXw5cH2xUhEJBwVEREWDO4YeJCJAHTE2e+tcmUVlgb4J+rKShvQ= = 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=fm2; bh=dRR+y9 Yiu02uA4KolNmxIkxPLMlb0VmlYQX0xe81eV0=; b=zZk7TYKVe2qgA7n7luvsYf ix3b2Fbj8z1+smayT5bkLg9rOslg0xm4xknZubwl0L8PZBVWVz0MYVDPSzGgbVhM jIbTHCLRLmkvW527g2GSKROMbAyNR4Nrm4n6Pe6hDC3dBGsdOBDKph+6nngAIrcS ZmFJ+eCqqENWVd0hBKORTWoxfI3VM7wyXAhc0xcxpawSJy5Nc3TSNKhJD0L+vaa6 vqYU4xqyPnnq+ScAZpE/jox8qM/fV/kM8ABQZchhApUck/VW0SeUpzXco/4IGiVc t6kSVC4mP3eDyUG7KvIUqpklTzNeFhZr0YpiRFf95ohrrawJe533JVsgRxUloLDA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudegtddgledtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhn ghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 411E8180090; Fri, 20 Mar 2020 01:43:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1021-g152deaf-fmstable-20200319v1 Mime-Version: 1.0 Message-Id: <60961b0e-7909-477f-b646-14aaae5902ad@dogfood.fastmail.com> In-Reply-To: References: Date: Fri, 20 Mar 2020 16:43:49 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=f565b9eb60344f559874153e0dc4f2f8 Archived-At: Subject: Re: [Jmap] draft-ietf-jmap-mdn-06 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, 20 Mar 2020 05:43:36 -0000 --f565b9eb60344f559874153e0dc4f2f8 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for that.=20 With that done, I BELIEVE that we -08 resolves every issue outstanding. = Do you agree? I'll go ahead and do the shepherd writeup if so. Cheers, Bron. On Thu, Mar 19, 2020, at 21:17, Raphael OUAZANA wrote: >=20 > Le 18 mars 2020 19:09, de murch@fastmail.com >>=20 >> On 3/18/20 1:42 PM, Raphael OUAZANA wrote: >>> Hello, >>> Le 6 mars 2020 20:35, de murch@fastmail.com=20 >>>> On 3/5/20 7:40 PM, Ken Murchison wrote: >>>> > A few questions as I implement this in Cyrus: >>>> > - The JMAP server may not be able to determine the Final-Recipien= t of=20 >>>> > the original message was Bcc'd or sent to an alias. Should the M= DN=20 >>>> > object include a 'from' property? >>>=20 >>> It should match the email of the account, no? >>=20 >> If the email was sent to an email alias and eventually delivered to t= he underlying account, the sender of the MDN might want to have the MDN = use the alias so as not to leak the real address of the account. >>=20 >>> Or maybe we should ask for an identity when sending an MDN, so that = the user can choose which email appears in this field? >>=20 >> Yes, that is what I was thinking. If the user doesn't provide a from = address, then we can default to the email of the account. >=20 > I will add an identity parameter, like in MessageSubmission. I will ma= ke it mandatory because for me it's not clear how we can get an email ad= dress from an account. > Regards, > Rapha=C3=ABl. >>=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --f565b9eb60344f559874153e0dc4f2f8 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks for that.

With that done, I BELIEVE= that we -08 resolves every issue outstanding.  Do you agree? = I'll go ahead and do the shepherd writeup if so.

Cheers,=

Bron.

On Thu, Mar 19, 2020, at 21:17, Raphael OUAZANA wrote:
=


Le 18 mars 202= 0 19:09, de murch@fastmail.com


On 3/18/20 1:42 PM, Raphael OUAZANA wrote:

Hello,

Le = 6 mars 2020 20:35, de murch@fastmail.com

On 3/5/20 7:40 PM, Ken Murchison wrote:
= > A few questions as I implement this in Cyrus:

> - The JMAP server may not be able = to determine the Final-Recipient of
> the original message w= as Bcc'd or sent to an alias.  Should the MDN
> object include a 'from' pr= operty?


It should match the e= mail of the account, no?


If the email = was sent to an email alias and eventually delivered to the underlying account, the sender of the MDN might want to have the MDN use the alias so as not to leak the real address of the account.


Or maybe we s= hould ask for an identity when sending an MDN, so that the user can choose which email appears in this field?
<= /p>


Yes, that is what I was thinking.  If= the user doesn't provide a from address, then we can default to the email of the account.
=


I will add an identity parameter, like in= MessageSubmission. I will make it mandatory because for me it's not cle= ar how we can get an email address from an account.

Regards,

Rapha=C3=ABl.


_= ______________________________________________
Jmap mailin= g list
Jmap@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jmap


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


--f565b9eb60344f559874153e0dc4f2f8-- From nobody Fri Mar 20 01:25:28 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3314F3A170E for ; Fri, 20 Mar 2020 01:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 QSSwqcm1lz00 for ; Fri, 20 Mar 2020 01:25:05 -0700 (PDT) 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 64B2F3A16A0 for ; Fri, 20 Mar 2020 01:24:59 -0700 (PDT) Received: from linagora.com (unknown [10.233.69.48]) by outgoing.linagora.com (Postfix) with ESMTP id 6592E3B; Fri, 20 Mar 2020 08:24:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1584692697; bh=sspnKbgU2bwfptL9SeLrAfe854mD/dRaIEYmLkjQHZk=; h=From:Reply-To:To:Subject:Date:References:From; b=B8u3ROZ724DQzGJ9pp/dr1YoK55uPXhlhXRRqde8vfVc0kbpTTEGDFa3WwdmYuril hOnDB4bj4Cmjbt4RH4kF0u6c3Qmq1kJF9tFXgWSVi8UIsnIMnEjUMRV/6WZYSOYaUE 8EBMZLJeI2BtMHojzs0XNfGgsOrTP70DFxwUjLxa3mzH4tWT38NDAK3GqNpl3SgEU+ +1LCZhUJ8JvSBeJru1Ac+oP8cy3xlZQSEWuXvvL20herthcFmWWXzIom4VvCLJ7zua 1EyVJAPmWf2x82sfTsFXMbh+uz0gdixMRHOo+a001l4lnyJSOQmW8c/iTx+IVajpv8 NtYCqtOZFcjAg== 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, 20 Mar 2020 08:24:55 +0000 References: Archived-At: Subject: Re: [Jmap] draft-ietf-jmap-mdn-06 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, 20 Mar 2020 08:25:21 -0000

I agree, I think I've fixed every comments with -08=2E

Thanks,

=

Rapha=C3=ABl=2E

Le 20 mars 2020 06:43, de brong@fastmailtea= m=2Ecom
Th= anks for that=2E

With that done, I BELIEVE that we -08 resolve= s every issue outstanding=2E  Do you agree?  I'll go ahead and do= the shepherd writeup if so=2E
<= br>
Cheers,

Bron=2E
<= /div>

On Thu, Mar 19, 2020,= at 21:17, Raphael OUAZANA wrote:


Le 18 mars 2020 19:09, de murch@fastmail=2Ecom


On 3= /18/20 1:42 PM, Raphael OUAZANA wrote:

Hello,

Le 6 mars 2020 20:35, de murch@fastmail= =2Ecom

On 3/5/20 7:40 PM, Ken = Murchison wrote:
> A few questions as I implement this in= Cyrus:

> - The JMA= P server may not be able to determine the Final-Recipient of
=
> the original message was Bcc'd or sent to an alias=2E = ; Should the MDN
> object include a 'from' pro= perty?


It should match the email= of the account, no?


If the email was sen= t to an email alias and eventually delivered to the underlying accoun= t, the sender of the MDN might want to have the MDN use the alias so = as not to leak the real address of the account=2E


<= blockquote type=3D"cite" cite=3D"mid:Mime4j=2E45=2Eb5134222dd4c80fb=2E170ee= bd92f8@linagora=2Ecom">

Or maybe we should ask for an identity when sendi= ng an MDN, so that the user can choose which email appears in this = field?


Yes, that is what I was thinking= =2E  If the user doesn't provide a from address, then we can def= ault to the email of the account=2E


I wil= l add an identity parameter, like in MessageSubmission=2E I will make it ma= ndatory because for me it's not clear how we can get an email address from = an account=2E

Regards,

Rapha=C3=ABl=2E


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


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

=