From nobody Thu Feb 6 20:07:30 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 48D13120903 for ; Thu, 6 Feb 2020 20:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=FULzlbqv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1m6Vomzt 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 boKfCWjUWmmX for ; Thu, 6 Feb 2020 20:07:22 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77A01208A8 for ; Thu, 6 Feb 2020 20:07:21 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3857022023; Thu, 6 Feb 2020 23:07:21 -0500 (EST) Received: from imap28 ([10.202.2.78]) by compute6.internal (MEProxy); Thu, 06 Feb 2020 23:07:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=hivj F2rAxPX0ESXSS8NZ1kCW8i4iXOoFj3PcUaW3Xz8=; b=FULzlbqv85gxgR5F0/ve kArV67gWHWmGGlm7x9AqAjgvU3yjVl0qE/6oHSJP5xODFF1RhrNZFqiUX2CLqdgo /ttpS7A3wueLUPFSxouZjQK13d4nW3ZIslhsznzTXu1hEMyeQ9LjgN8/GyB9JnAG iSdZsb8tKBpSUGhzUJX6vKcMMZi6zWT2QoTMXvK/SPtPrMX2ZwjKg0ok24lIgaBH j+J680y1vbrwP5WUtCleuzX1B7hcJO5ETcGYqrBfSb/hxpyurSeicmZt/QlKza9x 1pY8v6B9ZeLQqRD4NFLV6qnyg9RtRyFFu67izi99evWQ22BhzhifYWI6sDdOiBNb AA== 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=hivjF2 rAxPX0ESXSS8NZ1kCW8i4iXOoFj3PcUaW3Xz8=; b=1m6VomztMosWKzjRPNuicT 08XX822w9/6iDa8ip4ZaBVncaNo6FYQUrJQbeZ0BnluJ4di4rfZJMa7KyNRONYIt xeUQ9W9o1JFwxV6XuUCrA1mjMFgBGLAa2K2B4mibisylolmbSOYHgraPW/Y61vEa e5TooI/Vm+j8BE1caRNTobE5JrA9Ag7Nm8yWI92r8fwVim2vsnORWJBzuMUNuaf+ oI5JXLqJMrcsvK1BHQx269o+ciKRtv82hJeQT3NbjSEUSouwQN0BKtWVsnGeiiPc ZMPcEqNixRy335T/jtF9FEDeuGg2rvmtLO0SghGX7FLrcxMgMUkBrfXqA6RlHvqg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheeggdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinheplhhinhgrghhorhgrrdgtohhmpdhivghtfhdrohhrghenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrg hsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 790ED24009E; Thu, 6 Feb 2020 23:07:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-871-gf1112c6-fmnext-20200202v1 Mime-Version: 1.0 Message-Id: <9c095bdb-b09b-49af-aab4-a53fb743d3de@beta.fastmail.com> In-Reply-To: <644c56e0-9949-41c1-bed0-621142859788@beta.fastmail.com> References: <644c56e0-9949-41c1-bed0-621142859788@beta.fastmail.com> Date: Fri, 07 Feb 2020 15:07:00 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: "Raphael OUAZANA" , "Ken Murchison" Content-Type: multipart/alternative; boundary=3ca48f9cdf564ea2a526c60811b6ee58 Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-mdn-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 04:07:29 -0000 --3ca48f9cdf564ea2a526c60811b6ee58 Content-Type: text/plain HI Raphael - sorry for the late review and then being pushy! I'm keen to submit this for publication, but waiting for your response on the review. FYI Ken has been working on an implementation for Cyrus IMAPd, so hopefully we'll have our own copy to test against soon :) Cheers, Bron. On Wed, Jan 29, 2020, at 17:21, Bron Gondwana wrote: > As promised, a review of the current draft. > > *2.1 MDN/set* > > Looking at this some more, it doesn't make sense to call this method /set - it doesn't work the same way as regular set commands. It doesn't create an object which can later be fetched, or return an id. It would be better to rename this so it doesn't create confusion. > > I suggest something like: > > [[ "MDN/generate", { "accountId": "ue150411c", "for": { "Md45b47b4877521042cec0938": { "subject": "Read receipt for: World domination", "textBody": "This receipt shows that the email has been displayed on your recipient's computer. There is no guaranty it has been read or understood.", "reportingUA": "linagora.com; OpenPaaS", "disposition": { "actionMode": "manual-action", "sendingMode": "MDN-sent-manually", "type": "displayed" } } } }, "R1" ]] > > Response: > > [[ "MDN/generate", { "accountId": "ue150411c", "generated": { "Md45b47b4877521042cec0938": { "finalRecipient": "rfc822; john@example.com", "originalMessageId": "<1521557867.2614.0.camel@apache.org >" } } }, "R1" ], > [ "Email/set", { "updated" : [ "Md45b47b4877521042cec0938" ], ... }, "R1" ]] > > > and of course: there's also "notGenerated" : { "emailId" : { ErrorObject }} with probably a specific error code for mdnAlreadySent. > > > [[ "MDN/generate", { "accountId": "ue150411c", "for": { "Md45b47b4877521042cec0938": { "subject": "Read receipt for: World domination", "textBody": "This receipt shows that the email has been displayed on your recipient's computer. There is no guaranty it has been read or understood.", "reportingUA": "linagora.com; OpenPaaS", "disposition": { "actionMode": "manual-action", "sendingMode": "MDN-sent-manually", "type": "displayed" } } } }, "R2" ]] > > Response: > > [[ "MDN/generate", { "accountId": "ue150411c", "notGenerated": { "Md45b47b4877521042cec0938": { "type": "mdnAlreadySent", "description" : "$MDNSent keyword is already present" } } }, "R2" ], > > > > The emailId makes sense as the key for the object, since it's only legal to do one per email. > > *NOTE: *I didn't mention oldState and newState here. There's not much point, because the MDN itself doesn't have state. The Email/set response should have state, because email objects have state, but it doesn't make sense to have state for MDN objects, because you can't query or fetch them.** > > *3.1. Sending an MDN for a received email* > > The first example needs to show the Email/set response with the same method call id. There should also be an example (as above) for the error case. > > *3.2. Asking for MDN* > > "header:Disposition-Notification-To": "joe@example.com", > > This doesn't do quite what you expect - default is "asRaw", which doesn't add a leading space. You probably want. > > "header:Disposition-Notification-To:asText": "joe@example.com", > > *3.3 Parsing a received MDN* > > Likewise, this should have an example of what to do when it's called on a blob which doesn't parse as a MDN, or what happens when the blob doesn't exist. > > > > *General Comments*** > > Ideally each method should mention what kinds of errors are likely to be created, e.g this kind of thing from RFC8620. > > The following SetError types are defined and may be returned for set operations on any record type where appropriate: o "forbidden": The action would violate an ACL or other permissions policy. o "overQuota": The create would exceed a server- defined limit on the number or total size of objects of this type. o "tooLarge": The create would result in an object that exceeds a server-defined limit for the maximum size of a single object of this type. o "rateLimit": Too many objects of this type have been created recently, and a server-defined rate limit has been reached. It may work if tried again later. o "notFound": The id given cannot be found. > > Obviously, these need to be chosen from the existing error registry, or the IANA section should include registration for any newly added errors. > > I expect security review might ask you to expand a little on the security considerations as well. > > Cheers, > > Bron. > ** > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --3ca48f9cdf564ea2a526c60811b6ee58 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
HI Raphael - sorry for the late review and then being= pushy!  I'm keen to submit this for publication, but waiting for y= our response on the review.
<= br>
FYI Ken has been working on a= n implementation for Cyrus IMAPd, so hopefully we'll have our own copy t= o test against soon :)

Cheers,

Bron.

On Wed, Jan 29, 202= 0, at 17:21, Bron Gondwana wrote:
As promised, a review of the curr= ent draft.

2.1 MDN/set

Looking at t= his some more, it doesn't make sense to call this method /set - it doesn= 't work the same way as regular set commands.  It doesn't create an= object which can later be fetched, or return an id.  It would be b= etter to rename this so it doesn't create confusion.

I su= ggest something like:

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

Response:

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


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


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

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

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



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

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

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

3.2. Asking for MDN

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

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

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

3.3 Parsing a received MDN

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



General Comments
<=
/div>

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

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

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

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


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

      of a single object of this type.

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

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

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

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

Cheers,
=

Bron.

-- 
  Bro=
n Gondwana, CEO, Fastmail Pty Ltd
&=
nbsp; brong@fastmailteam.com


_____________=
__________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listin=
fo/jmap


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


--3ca48f9cdf564ea2a526c60811b6ee58-- From nobody Thu Feb 6 20:17:54 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 E08FE120072 for ; Thu, 6 Feb 2020 20:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=tMiD7T2x; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RNs0u+5O 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 XcxhW3qSpqUJ for ; Thu, 6 Feb 2020 20:17:50 -0800 (PST) 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 15AF412001B for ; Thu, 6 Feb 2020 20:17:50 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 42FE7357; Thu, 6 Feb 2020 23:17:49 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 06 Feb 2020 23:17:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=subject:to:cc:references:from:message-id :date:mime-version:in-reply-to:content-type; s=fm1; bh=EQslHOc/a QBptvsXaxeA8JJMcJztn8k+eWWIL7i4kEY=; b=tMiD7T2x23ASiDQiRcEPRixfB 4drjZ2ZAOb0PH8mT61gaDD2KP0J5r/TfITJ6MGmr9gJ5tw0BL33vWv9VeaCgtyic ggutpmFodvKNrlT8Wn8ELOJRBH+956oZr4LAxDaZgUm2lAmN8xraFjaSI/1TxtvV /yFAPs1rxzSqwdDQm92F1WP3fUTNJ0A6HNc6l+iaHnzYMluUBiklfJI28OB/+1P0 89hDQdFdc6tktbs8zVSHWsNDXyXcCD/zOlqM3Z20/7R+IKAQvvx2O/99rJx5gX0/ Y665pNMZUfAi6dIJBhzf0BeC0HM17blELw5BygCzfAtd7jeqcVEJa5Z9gRunw== 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=EQslHO c/aQBptvsXaxeA8JJMcJztn8k+eWWIL7i4kEY=; b=RNs0u+5OvzH6mWqstD+zdu ZF+u7U+oPhNwq787O65opzfe13TyzJibDcI7S40bRQoBKp2BQDGn1ykUEUHS52sD 2Bs1QWhTbAPvE6lHUA/7OjuAOa08WQ+wrJn3RH2ODubjizPcB1oMKk6XBWt2vJZd KtjCYMAqMN31oZRoM8R3IOq32GaRh/vnCtNPhL0VfSt+aO6ympCt9kUx1L91YF5u IqRFr4g3hOFyJx5XDHoiFYFSiKNGtcQBzYMWyRpxrvYkn7ZXz+F/tlktLmjRj1Xs v5aevbw/1ZZNb76/AhQVF2wHueNxlbrQokIkp96YWAnuEAjrsLWI8OAloG7+uC8Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheeggdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtsegrtderredtfeejnecuhfhrohhmpefmvghnucfo uhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenuc ffohhmrghinheplhhinhgrghhorhgrrdgtohhmnecukfhppeejgedrjeejrdekhedrvdeh tdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuh hrtghhsehfrghsthhmrghilhhtvggrmhdrtghomh 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 BB0AD328005A; Thu, 6 Feb 2020 23:17:47 -0500 (EST) To: Bron Gondwana , jmap@ietf.org Cc: Raphael OUAZANA References: <644c56e0-9949-41c1-bed0-621142859788@beta.fastmail.com> <9c095bdb-b09b-49af-aab4-a53fb743d3de@beta.fastmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Thu, 6 Feb 2020 23:17:45 -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: <9c095bdb-b09b-49af-aab4-a53fb743d3de@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------420E732FF2B6DB8C01350001" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-mdn-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 04:17:52 -0000 This is a multi-part message in MIME format. --------------420E732FF2B6DB8C01350001 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/6/20 11:07 PM, Bron Gondwana wrote: > HI Raphael - sorry for the late review and then being pushy!  I'm keen > to submit this for publication, but waiting for your response on the > review. > > FYI Ken has been working on an implementation for Cyrus IMAPd, so > hopefully we'll have our own copy to test against soon :) > > Cheers, > > Bron. > > On Wed, Jan 29, 2020, at 17:21, Bron Gondwana wrote: >> As promised, a review of the current draft. >> >> *2.1 MDN/set* >> >> Looking at this some more, it doesn't make sense to call this method >> /set - it doesn't work the same way as regular set commands.  It >> doesn't create an object which can later be fetched, or return an >> id.  It would be better to rename this so it doesn't create confusion. >> >> I suggest something like: >> >> [[ "MDN/generate", { >> "accountId": "ue150411c", >> "for": { >> "Md45b47b4877521042cec0938": { >> "subject": "Read receipt for: World domination", >> "textBody": "This receipt shows that the email has been >> displayed on your recipient's computer. There is no >> guaranty it has been read or understood.", >> "reportingUA": "linagora.com; OpenPaaS", >> "disposition": { >> "actionMode": "manual-action", >> "sendingMode": "MDN-sent-manually", >> "type": "displayed" >> } >> } >> } >> }, "R1" ]] Or call the method /send or /submit, since it both generates the MDN and submits it to an MSA. Also, should the request have an additional boolean argument which dictates whether the original message should be included in the MDN? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------420E732FF2B6DB8C01350001 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/6/20 11:07 PM, Bron Gondwana wrote:
HI Raphael - sorry for the late review and then being pushy!  I'm keen to submit this for publication, but waiting for your response on the review.

FYI Ken has been working on an implementation for Cyrus IMAPd, so hopefully we'll have our own copy to test against soon :)

Cheers,

Bron.

On Wed, Jan 29, 2020, at 17:21, Bron Gondwana wrote:
As promised, a review of the current draft.

2.1 MDN/set

Looking at this some more, it doesn't make sense to call this method /set - it doesn't work the same way as regular set commands.  It doesn't create an object which can later be fetched, or return an id.  It would be better to rename this so it doesn't create confusion.

I suggest something like:

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


Or call the method /send or /submit, since it both generates the MDN and submits it to an MSA.

Also, should the request have an additional boolean argument which dictates whether the original message should be included in the MDN?


-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------420E732FF2B6DB8C01350001-- From nobody Fri Feb 7 01:48:39 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 768371201C6; Fri, 7 Feb 2020 01:48:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <158106891440.11678.4191094112964494910@ietfa.amsl.com> Date: Fri, 07 Feb 2020 01:48:34 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 09:48:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSContact: A JSON representation of contact data Authors : Robert Stepanek Mario Loffredo Filename : draft-ietf-jmap-jscontact-00.txt Pages : 17 Date : 2020-02-07 Abstract: This specification defines a data model and JSON representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-jscontact-00 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-00 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 Fri Feb 7 05:28: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 E4B6A12013C for ; Fri, 7 Feb 2020 05:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 Dra7NIj_15UI for ; Fri, 7 Feb 2020 05:27:58 -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 C452E12002E for ; Fri, 7 Feb 2020 05:27:56 -0800 (PST) Received: from linagora.com (unknown [10.233.69.202]) by outgoing.linagora.com (Postfix) with ESMTP id 21DA43B; Fri, 7 Feb 2020 13:27:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1581082075; bh=nH3aKi+u/YNUVZWY6yzoTTKqraZr6kxCbTGrgfNJQZc=; h=From:Reply-To:To:Cc:Subject:Date:References:From; b=UF/Oj6p2zmd0p1jf5OZONutA9euCRCIZKZbd4JU8JTJ0r9+tPW3qOOUb4lwgln5Ng bZ5Y5Y2KCHPKu/XcRo2quJR8KI7qLjgcUP8HXCtSdi/i0sKy36XCkKckVxQW/v9c4e Q42yuJrZLya0AHHrZIcOHESoEbBy0l4MlxPFg+RwAoIPbyghNs6QoeLf4Q+i1NNMoQ 492HI/+k6Y9UBSfLyPrpfl32SZVTdBM1dO6smH0C75VrijpghzclN8xFw0vhOi/iqm j8te0AwKXEZqRRF58TvT4yRNmexKe74Xpogwgokt9iar2vxFHPSxrBOp6rzJM4SXJt wYHS9LKUXRXbw== 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 Cc: Raphael OUAZANA , Ken Murchison Message-ID: Date: Fri, 7 Feb 2020 13:27:49 +0000 References: <644c56e0-9949-41c1-bed0-621142859788@beta.fastmail.com> Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-mdn-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 13:28:00 -0000

Hi Bron,

Sorry too, I don't have much time to dig into this now=2E=

Anyway I already proposed a version where the method was not called = set, and I received some remarks telling me it should be a "set" method to = be more uniform=2E So I'm waiting for a consensus on this subject before up= dating again the specification=2E

Else I generally agree on your rema= rks, just need time to update the doc=2E

Regards,

Rapha=C3=ABl= =2E

Le 7 f=C3=A9vrier 2020 05:07, de brong@fastmailteam=2Ecom<= /cite>
HI Rapha= el - sorry for the late review and then being pushy!  I'm keen to subm= it this for publication, but waiting for your response on the review=2E
=

FYI Ken has been working on an implementation for Cyrus IMAPd, so = hopefully we'll have our own copy to test against soon :)

Cheer= s,

Bron=2E

On Wed, Jan 29, 2020, at 17:21, Bron Gondwana wrote:
As promised,= a review of the current draft=2E

2=2E1 MDN/set

Looking at this some more, it doesn't make sense to call this method /s= et - it doesn't work the same way as regular set commands=2E  It doesn= 't create an object which can later be fetched, or return an id=2E  It= would be better to rename this so it doesn't create confusion=2E
=

I suggest something like:
       [[ "MDN/generate", {
         "accountId": "ue150411c",
=
         "for": {
           "Md45b47b4877521042cec0938": {
             "s=
ubject": "Read receipt for: World domination",
             "textBody": "Th=
is receipt shows that the email has been
                 displayed on your=
 recipient's computer=2E There is no
                 guaranty it has been =
read or understood=2E",
             "reportingUA": "linagora=2Ecom; OpenPa=
aS",
             "disposition": {
               "actionMode": "manual-act=
ion",
               "sendingMode": "MDN-sent-manually",
               "ty=
pe": "displayed"
             }
           }
         }
       }, "R1" ]]

Response:

     [[ "MDN/generate", {=

       "accountId": "ue150411c",
       "generated": {
         "Md45b47b4=
877521042cec0938": {
           "finalRecipient": "rfc822; john@example=2Ecom",
           "originalMessageI=
d": "<1521557867=2E2614=2E0=2Ecamel@apache=2Eorg>"
         }
       }
 =
    }, "R1" ],
     [ "Email/set", {
       "updated" : [ "Md=
45b47b4877521042cec0938" ],
       =2E=2E=2E 
     }, "R1" ]]


and of course: there's also "notGenerated" : { "em= ailId" : { ErrorObject }} with probably a specific error code for mdnAlread= ySent=2E


       [[ "MDN/generate", {
=
         "accountId": "ue150411c",
         "for": {
           "Md45b47b48=
77521042cec0938": {
             "subject": "Read receipt for: World domina=
tion",
             "textBody": "This receipt shows that the email has been=

                 displayed on your recipient's computer=2E There is no
   =
              guaranty it has been read or understood=2E",
             "re=
portingUA": "linagora=2Ecom; OpenPaaS",
             "disposition": {
     =
          "actionMode": "manual-action",
               "sendingMode": "MDN=
-sent-manually",
               "type": "displayed"
             }
        =
   }
         }
       }, "R2" ]]

Response:

     [[ "MDN/generate", {=

       "accountId": "ue150411c",
       "notGenerated": {
         "Md45b4=
7b4877521042cec0938": {
           "type": "mdnAlreadySent",
           "de=
scription" : "$MDNSent keyword is already present"
         }
       }
    =
 }, "R2" ],



The emailId make= s sense as the key for the object, since it's only legal to do one per emai= l=2E

NOTE: I didn't mention oldState and newState here= =2E  There's not much point, because the MDN itself doesn't have state= =2E  The Email/set response should have state, because email objects h= ave state, but it doesn't make sense to have state for MDN objects, because= you can't query or fetch them=2E

3=2E1=2E Sending an= MDN for a received email
The first example needs to show t= he Email/set response with the same method call id=2E  There should al= so be an example (as above) for the error case=2E

3=2E2=2E A= sking for MDN

"header:Disposition-Notification-To": "joe@example=2Ecom",

This doesn't do quite what you expect= - default is "asRaw", which doesn't add a leading space=2E  You proba= bly want=2E

"head=
er:Disposition-Notification-To:asText": "joe@example=2Ecom",
=
3=2E3 Parsing a receiv= ed MDN

Likewise, this should have an example of what to do= when it's called on a blob which doesn't parse as a MDN, or what happens w= hen the blob doesn't exist=2E


General Comments<= /b>

Ideally each method should mention what kinds of er= rors are likely to be created, e=2Eg this kind of thing from RFC8620=2E
= 

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

   o  "forbidden": The a=
ction
      would violate an ACL or other permissions policy=2E

   o  "ove=
rQuota": The create would exceed a server-
      defined limit on the numbe=
r or total size of objects of this type=2E

   o  "tooLarge": The create wo=
uld result in
      an object that exceeds a server-defined limit for the m=
aximum size
      of a single object of this type=2E

   o  "rateLimit": To=
o many objects of this type have been
      created recently, and a server-=
defined rate limit has been
      reached=2E  It may work if tried again la=
ter=2E

   o  "notFound": The id given
      cannot be found=2E

Obviously, these need to be chosen from the existing error registry, or th= e IANA section should include registration for any newly added errors=2E

I expect security review might ask you to expand a little on the = security considerations as well=2E

Cheers,

Bron=2E=

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


___= ____________________________________________
Jmap mailing lis= t
Jmap@ietf=2Eorg
https://www=2Eietf=2Eorg/mail= man/listinfo/jmap


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


From nobody Fri Feb 7 05:54: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 8F9E812087C for ; Fri, 7 Feb 2020 05:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 CjU8YL92Y0aj for ; Fri, 7 Feb 2020 05:54:54 -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 EA1D9120879 for ; Fri, 7 Feb 2020 05:54:53 -0800 (PST) Received: from linagora.com (unknown [10.233.69.202]) by outgoing.linagora.com (Postfix) with ESMTP id 8E85D3B; Fri, 7 Feb 2020 13:54:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1581083691; bh=nIZF/4+wblFNzf5KVkexqOTkHworuqMZ/WQLMAGvYMo=; h=From:Reply-To:To:Cc:Subject:Date:References:In-Reply-To:From; b=iMR/W0z0/xjV/nWAupv8U5L8SkpqufIsfIqObewRPS39bCUARWakJ76Gjr+o5/FId DBGtALfquxW0UdP+OuXmB0Azh6rSGYy4sIk7Mgc5VvH0jK5UUEL6XlrBk2PAG9FqNg zm7eYFIUZYnHgyKmwKLFMjLgSYPRMaNE6c+V2lF8hrw5gtcl6lF3/NqnNJJcmfLqIh u5qJZgMZQ3aPEH1m7Yg2Wp04gUJn5dw54RaORs72DQ6ns4Khr/OwAC7rsCBEpB+sIh 4brM22CxU9V2nka6Bupim1FAjUR3RukkJj+mSwm5a3BdBxx9oTqgsgHzLX8bL3Exbd 62w12oA2DcW8w== 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: Bron Gondwana , "jmap@ietf.org" , Ken Murchison Cc: Raphael OUAZANA Message-ID: Date: Fri, 7 Feb 2020 13:54:49 +0000 References: <644c56e0-9949-41c1-bed0-621142859788@beta.fastmail.com> <9c095bdb-b09b-49af-aab4-a53fb743d3de@beta.fastmail.com> In-Reply-To: Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-mdn-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 13:54:56 -0000


Le 7 février 2020 05:17, de murch@fastmailteam.com

Or call the method /send or /submit, since it both generates the MDN and submits it to an MSA.


Yes, /send seems a better naming for me, it was one of my first proposal (in fact I put it in MessageSubmission so it was MessageSubmission/sendMDN).

Also, should the request have an additional boolean argument which dictates whether the original message should be included in the MDN?


For me MDN are lightweight notifications with almost, and we tend to use them only for automatic handling, where the original message is ignored.

But you are right, being part of the specification it could be an added option.

Regards,

Raphaël.

From nobody Fri Feb 7 06:45:43 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9351112010C; Fri, 7 Feb 2020 06:45:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, fenton@bluepopcorn.net, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158108673659.11678.11933938262192034208.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 06:45:36 -0800 Archived-At: Subject: [Jmap] Alissa Cooper's No Objection on draft-ietf-jmap-websocket-05: (with COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 14:45:37 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-jmap-websocket-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-jmap-websocket/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. From nobody Mon Feb 10 08:02:56 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F08120096 for ; Sun, 9 Feb 2020 19:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=gu4MDNQz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=acVb2H8p 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 oi6niXqlRBCt for ; Sun, 9 Feb 2020 19:55:56 -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 8466512008C for ; Sun, 9 Feb 2020 19:55:56 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 87590591 for ; Sun, 9 Feb 2020 22:55:55 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 09 Feb 2020 22:55:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=FgMjc/G 1RJ18LzxcCBGWrsZx66fbEYwBIZkzDNuXEjY=; b=gu4MDNQzIkHGfT/LNWC0KA4 o4hbE9CsELh5efdN6g8pFsl8n0QLPseao058btKEbC8zicTuJXrERKxV2WbdKig8 qsJmW9O7HITM1cEqPodk52PeivpVHFR1osLk2E+VX5TW+1LNAI5YM3k8mhZxMtPe 62bqbORKFhi0booQMUTfdHTzBzyPUkWMNh8zbowIW70z7NjeDVabnMwTgbykZkDd hJ1rwjeqAflfIphuVrUdsA7a2yjAjMY7s9iHk1N5nNeaTXNSOobgEU7Zf/tM5V+k qWsEFUweKA7Klh2T1oBJS2egJfJkwNtJzW9K2HE6D7ckUOyLMQhlB1a685UuynA= = 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=FgMjc/ G1RJ18LzxcCBGWrsZx66fbEYwBIZkzDNuXEjY=; b=acVb2H8pDvixSLA+QPGj49 Uu8omrWEfPnFJW6LHFh35X4ZSqxChBqj5YmxD28HMeRbXLYNAk//+yuSYKVGVzRF YmQy/HGLXmvzy6sFXzimnDdvhWQvMf4yJJDuUnMYsDU2ieAJJcIZPh8K0V+jZMUF ok3BGytbMmsDFsj+mggjpCsusCJuTr4cynp9GFEyY2YewKh74KTE0T2tElQ9G33Y 0QCpxgoqexr3pCJP7RbTO/aP25dSv3A3EeGzJ1x8tiyC0rJRZrehIhoxWNDrVOjN bq/lQjAqwWYFl8UtwUmKa24jonoS5Ly4CnOP8weZ6yxnloI1YgFsRBzjBZvMaC+g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedriedtgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhl jhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9B0CA180094; Sun, 9 Feb 2020 22:55:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-871-gf1112c6-fmnext-20200202v1 Mime-Version: 1.0 Message-Id: <0c1cd9d6-0127-4112-802c-9e2c90b34321@beta.fastmail.com> In-Reply-To: References: <644c56e0-9949-41c1-bed0-621142859788@beta.fastmail.com> <9c095bdb-b09b-49af-aab4-a53fb743d3de@beta.fastmail.com> Date: Mon, 10 Feb 2020 14:55:33 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=ad78531520164bf5bf618242e1298eec Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-mdn-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2020 03:55:58 -0000 --ad78531520164bf5bf618242e1298eec Content-Type: text/plain On Sat, 8 Feb 2020, at 00:54, Raphael OUAZANA wrote: > Yes, /send seems a better naming for me, it was one of my first proposal (in fact I put it in MessageSubmission so it was MessageSubmission/sendMDN). The main issue with the original proposal was that this was not an action on MessageSubmission objects, so this wasn't the right noun to be on the left. We definitely want `MDN/`. While I originally thought this was a `/set`, having thought about this more I agree this is different enough that it should be called something different, so I agree with Bron it should be something like `MDN/send`. Neil. --ad78531520164bf5bf618242e1298eec Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sat, 8 Feb 2= 020, at 00:54, Raphael OUAZANA wrote:
Yes, /send seems a better naming for me, it was one of my first pr= oposal (in fact I put it in MessageSubmission so it was MessageSubmissio= n/sendMDN).

The main issue wit= h the original proposal was that this was not an action on MessageSubmis= sion objects, so this wasn't the right noun to be on the left. We defini= tely want MDN/. While I originally thought this was a /set, ha= ving thought about this more I agree this is different enough that it sh= ould be called something different, so I agree with Bron it should be so= mething like MDN/send.

Neil.
--ad78531520164bf5bf618242e1298eec-- From nobody Mon Feb 10 08:09:52 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 0F035120255; Mon, 10 Feb 2020 07:11:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <158134748295.4179.9164262983340718758@ietfa.amsl.com> Date: Mon, 10 Feb 2020 07:11:23 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-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: Mon, 10 Feb 2020 15:11:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSContact: A JSON representation of contact data Authors : Robert Stepanek Mario Loffredo Filename : draft-ietf-jmap-jscontact-01.txt Pages : 17 Date : 2020-02-10 Abstract: This specification defines a data model and JSON representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-jscontact-01 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-jscontact-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 Mon Feb 10 09:47:50 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0785E12001A; Mon, 10 Feb 2020 09:47:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <158135686686.4249.11866019542950736612@ietfa.amsl.com> Date: Mon, 10 Feb 2020 09:47:46 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-smime-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: Mon, 10 Feb 2020 17:47:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : S/MIME signature verification extension to JMAP Author : Alexey Melnikov Filename : draft-ietf-jmap-smime-01.txt Pages : 6 Date : 2020-02-10 Abstract: This document specifies an extension to JMAP for returning S/MIME signature verification status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-smime-01 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-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 Mon Feb 17 18:53:21 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 4634C120866; Mon, 17 Feb 2020 16:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b2V5VqEOfmw; Mon, 17 Feb 2020 16:15:04 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D0712002E; Mon, 17 Feb 2020 16:15:03 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01I0EkFO014964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Feb 2020 19:14:49 -0500 Date: Mon, 17 Feb 2020 16:14:46 -0800 From: Benjamin Kaduk To: Ken Murchison Cc: The IESG , draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, jmap@ietf.org Message-ID: <20200218001446.GB43614@kduck.mit.edu> References: <157843131129.21019.4453575321747210277.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) 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: Tue, 18 Feb 2020 00:15:05 -0000 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 From nobody Mon Feb 17 18:53:59 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 D539E12002E; Mon, 17 Feb 2020 16:23:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, fenton@bluepopcorn.net, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158198543786.24029.15031679428277039203.idtracker@ietfa.amsl.com> Date: Mon, 17 Feb 2020 16:23:57 -0800 Archived-At: Subject: [Jmap] Benjamin Kaduk's No Objection on draft-ietf-jmap-websocket-05: (with COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 00:23:58 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-jmap-websocket-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-jmap-websocket/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss points (and comments!) on the -04! I do want to have a bit more discussion in light of the late-breaking secdir review, though. Specifically, RFC 6455's security considerations have significant discussion of the web's "Origin" concept and how it applies both in the case of trusted browsers running untrusted javascript, and potentially untrusted native applications. I did not see any follow-up discussion in response to the secdir reviewer's comments, and wonder if we need to say anything about the relationship between the Origin of the JMAP API endpoint and the websocket endpoint. I'd also like to have a bit of discussion about the risks of compression, which I mentioned in my comments on the -04 but don't remember seeing any follow-up on. Section 4.3.1 What's the difference between an unsupported JMAP vs. unsupported JSON object? E.g., what would make something "well-formed JMAP" but still unsupported? Section 5 It's best to refer to RFC 7525 as BCP 195, to incorporate any future updates. From nobody Wed Feb 19 14:18:18 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 1159712022E; Wed, 19 Feb 2020 14:18:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-jmap-websocket@ietf.org, Jim Fenton , jmap-chairs@ietf.org, fenton@bluepopcorn.net, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158215068906.17564.17300091640996443622.idtracker@ietfa.amsl.com> Date: Wed, 19 Feb 2020 14:18:09 -0800 Archived-At: Subject: [Jmap] Barry Leiba's No Objection on draft-ietf-jmap-websocket-05: (with COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 22:18:09 -0000 Barry Leiba has entered the following ballot position for draft-ietf-jmap-websocket-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-jmap-websocket/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the DISCUSS positions that suggest explicit text to require encryption. I think that RFC 7692 needs to be a normative reference. The IESG statement about references ( https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ ) says this: Note 1: Even references that are relevant only for optional features must be classified as normative if they meet the above conditions for normative references. + + + + + + + + + + + + + + + + + + + + The following are comments from Murray Kucherawy, incoming ART AD. Murray is getting an early start on doing reviews, and I’m including his comments into my ballots during the overlap period before he’s officially an Area Director. - - - - - - - - - - - - - - - - - - - - Section 4.1, I don't know what interoperability assertion is being made by saying I "MUST" consider something. I think the reference to the other document is appropriate, however. Section 4.2's use of MUSTard also has me flinching, and can hear Pete Resnick's voice asking me why there's "MUST close" instead of simply "closes", etc. Section 4.3.1's SHOULDs have me wondering under what conditions an implementation would deviate legitimately from that advice. The "@type" line in Section 4.3.5.2 looks like it's run together with its description line. From nobody Thu Feb 20 08:43:22 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44561200F4 for ; Thu, 20 Feb 2020 08:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=iMnUyq1u; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OIDSRs9Q 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 KcXGQurSYgZO for ; Thu, 20 Feb 2020 08:43:18 -0800 (PST) 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 40BF212012D for ; Thu, 20 Feb 2020 08:43:18 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 686853EC for ; Thu, 20 Feb 2020 11:43:17 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 20 Feb 2020 11:43:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=subject:references:to:from:message-id:date :mime-version:in-reply-to:content-type; s=fm2; bh=E0PoAJ7pjnFf0N N7ZbYOf81GqLI0pqwEtCd/uwps5HE=; b=iMnUyq1u3g6lQcQYKszEZC1FqVJ3VU kXthKC61/0GxYw+o7BdhP3tuCBuNv8uY27TVvZAuLiZccRhICexw/YOzWDXoSqHC TXo7NOJEaPpzAE8F7u1xPXDgb136jKhy5+kQBuxXd2u2vAFpLWPAp/8ajhVF20c6 yPqA6+wygdy5u+W1VQ0wD1n+bXap3S27lwrpgclrfowgRCfc6Id78gMaVGcOFIiq HALZDUTV9GFnI9qYJtnFOmAjudJv39mVa9uEDqufk/jZc2bRZdMCCtFOn+xuq0t8 nh7Vs+WmLuNKWQ2ADY2pTiZpFxDHq9vFNiVyWiok0ZBQIegUx21KTw8w== 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=E0PoAJ 7pjnFf0NN7ZbYOf81GqLI0pqwEtCd/uwps5HE=; b=OIDSRs9QyN1XkCDTGvx4In Fk5c9fb1FgvUIa5YRslM31VUXi5yH7Bun5kHa8a2i1m6fMyCgSxY2XVCCviNLOth l8l+bt7bmXwAmv23StbbttjclGPizsWJLYLp7ybTLSj0zxrnBJe/7IPW+MVney1k oi3Er9ev82Fh9dy+JXKec4cTEb5GsUljD43JOembRhfBjkjjhPyzFHS4VUyaBZ/C TnCjRuzWD/k968oP9ncjyCO18YGUEkunMv5d+r6EDpAgdEFEaj5UgIpOw8dXSP7K C6jXU/CUiKUKpNOnZ/5Jk/BkxVb5MIlCELV9Jb5e8u0/rE11sAJ3bAL55qgU9nQQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkedvgdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefufhfvhfhokffffgggjggtsegrtderredtfeejnecuhfhrohhmpefmvghnucfo uhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenuc ffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejgedrjeejrdekhedrvdehtdenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhse hfrghsthhmrghilhhtvggrmhdrtghomh 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 BB3793060F09 for ; Thu, 20 Feb 2020 11:43:16 -0500 (EST) References: <158221682566.12492.14060662168465827611.idtracker@ietfa.amsl.com> To: IETF JMAP Mailing List From: Ken Murchison Organization: FastMail US LLC X-Forwarded-Message-Id: <158221682566.12492.14060662168465827611.idtracker@ietfa.amsl.com> Message-ID: <5419c701-67c1-d7cb-ccfb-06ed10997481@fastmailteam.com> Date: Thu, 20 Feb 2020 11:43:16 -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: <158221682566.12492.14060662168465827611.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------A6AB3DA6DE361A7CF5075091" Content-Language: en-US Archived-At: Subject: [Jmap] Fwd: New Version Notification for draft-murchison-jmap-sieve-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 16:43:21 -0000 This is a multi-part message in MIME format. --------------A6AB3DA6DE361A7CF5075091 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit All, Fastmail is considering transitioning from ManageSieve to JMAP for managing user's Sieve scripts. I submitted this draft thinking that the concept might be of interest to others.  If so, we could ask the WG to adopt this document as a starting point. -------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-jmap-sieve-00.txt Date: Thu, 20 Feb 2020 08:40:25 -0800 From: internet-drafts@ietf.org To: Ken Murchison , Kenneth Murchison A new version of I-D, draft-murchison-jmap-sieve-00.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository. Name: draft-murchison-jmap-sieve Revision: 00 Title: JMAP for Sieve Scripts Document date: 2020-02-20 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-murchison-jmap-sieve-00.txt Status: https://datatracker.ietf.org/doc/draft-murchison-jmap-sieve/ Htmlized: https://tools.ietf.org/html/draft-murchison-jmap-sieve-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-jmap-sieve Abstract: This document specifies a data model for managing Sieve scripts on a server using JMAP. Open Issues o Should setting isActive==true on a script automatically deactivate any other existing active script, or should the client have to do so itself (as is currently documented)? o Do we want/need a SieveScript/copy method? o Do we want to leverage draft-ietf-jmap-quotas to query Sieve script storage quotas? 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. The IETF Secretariat --------------A6AB3DA6DE361A7CF5075091 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

All,

Fastmail is considering transitioning from ManageSieve to JMAP for managing user's Sieve scripts.

I submitted this draft thinking that the concept might be of interest to others.  If so, we could ask the WG to adopt this document as a starting point.



-------- Forwarded Message --------
Subject: New Version Notification for draft-murchison-jmap-sieve-00.txt
Date: Thu, 20 Feb 2020 08:40:25 -0800
From: internet-drafts@ietf.org
To: Ken Murchison <murch@fastmailteam.com>, Kenneth Murchison <murch@fastmailteam.com>



A new version of I-D, draft-murchison-jmap-sieve-00.txt
has been successfully submitted by Kenneth Murchison and posted to the
IETF repository.

Name: draft-murchison-jmap-sieve
Revision: 00
Title: JMAP for Sieve Scripts
Document date: 2020-02-20
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/internet-drafts/draft-murchison-jmap-sieve-00.txt
Status: https://datatracker.ietf.org/doc/draft-murchison-jmap-sieve/
Htmlized: https://tools.ietf.org/html/draft-murchison-jmap-sieve-00
Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-jmap-sieve


Abstract:
This document specifies a data model for managing Sieve scripts on a
server using JMAP.

Open Issues

o Should setting isActive==true on a script automatically deactivate
any other existing active script, or should the client have to do
so itself (as is currently documented)?

o Do we want/need a SieveScript/copy method?

o Do we want to leverage draft-ietf-jmap-quotas to query Sieve
script storage quotas?



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.

The IETF Secretariat

--------------A6AB3DA6DE361A7CF5075091-- From nobody Fri Feb 21 04:46:18 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 34F7D120828 for ; Fri, 21 Feb 2020 04:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Ep4oDM+Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S4bl+UoO 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 n4hLZ63JsTbn for ; Fri, 21 Feb 2020 04:46:01 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F631200D6 for ; Fri, 21 Feb 2020 04:46:01 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A414921EC3; Fri, 21 Feb 2020 07:46:00 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute7.internal (MEProxy); Fri, 21 Feb 2020 07:46:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:date:from:to:cc:subject:content-type :content-transfer-encoding; s=fm2; bh=C0obK5UvuqDhtzM+EaUT9z7xBu ZVhyixN4wdAiiRJn4=; b=Ep4oDM+YfFc6jGLW+AGaC6xzUmPHF9+cpDeRlfTzB/ B7r7p2EwpSn1HJw+5hbU+WBtNtKIuVrxm+3qKhn4F9TOyA7wCp7vCwC2mNkuLaXr L5qQiYJc0JBdZXoHupbG8fXa8LNuIZ4RGFogXIMaTaoEHeeSLaK4GGM5jpvXU73o PbCjHD1ZAJ8JnEahNoA4ODLU7Q23s6Z9dgnvNTKYZPdmfxg1/IhW90/Pc6c8DVrX rf4/sub3RGe/hKB5DcPODTKQnMaevuwfd0yfOUnJhjHycsiZEI5+InpTOT0uT/Xf vUWxy77RK6uSuOCGOP9bvEBfDzV5C7PuNWMuOqHMW86A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=C0obK5 UvuqDhtzM+EaUT9z7xBuZVhyixN4wdAiiRJn4=; b=S4bl+UoOTZF/etzU24Ted+ 0/g8kYR/c2PZ0MObdnnA40hl88nyX+o7aj1NvgGVS4tSqixodbnb794gI7q+CS3Q h1QVJ6MkHVHqqXAwD8htDj8sTK4iEUkcGXag012HgJ988S14JJrflE+OOuZKzYb8 gdSXlLVXz7TwNcsVFEcAGlp3SmuEvHrTUa0mWTWdrUiZ90sX71kMEuTuiolxzSmS lSSUabqt5t+bWr/iizBSZgGZ5DOPGQhePDiSSOfYAWpLm0A5EDmlMMx8UeHzBUBu GbHB1AOGDQXtqFl9NtkXRgdRDN++nhx+Di5kLy2fijHq/OF31UAkjQLrztvHPacQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeeggdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgvgigv hicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmh eqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggr mhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6659B660069; Fri, 21 Feb 2020 07:46:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1 Mime-Version: 1.0 Message-Id: <0f7388d8-b420-469f-8d5a-da5fb0bcf27a@www.fastmail.com> Date: Fri, 21 Feb 2020 12:45:20 +0000 From: "Alexey Melnikov" To: "Ken Murchison" , "Benjamin Schwartz" Cc: jmap@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [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: Fri, 21 Feb 2020 12:46:11 -0000 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 "[[Al= exey]]:" 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.=C2= =A0 It is redundant within this context. ## 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 HTT= PS endpoints, so no JMAP objects are exchanged there. This document just= does the same.]] ## 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?]] ## 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? --------------------- Best Regards, Alexey From nobody Mon Feb 24 13:10:05 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 9F2763A1342 for ; Mon, 24 Feb 2020 13:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=kZBFD6X3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ks0tmUwl 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 4fvyw65kUf3t for ; Mon, 24 Feb 2020 13:10:02 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA283A1341 for ; Mon, 24 Feb 2020 13:10:01 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 28D0721470; Mon, 24 Feb 2020 16:10:01 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 24 Feb 2020 16:10:01 -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=i0Dfl8A qBcD/DgHuTzbjOAGsS/Rj7tU10qSpJenuKsc=; b=kZBFD6X35F6o7PsqWY0TDRl MtywgYmQ1gyilGXQOEikzrdu1azSq8oVQnvlh5s529Amx4CI9+1S/7zjeWwjp16I pfGdcfNuZwVx6jUKL0Yk01SKKS71E8LbnE18dBR9rBsYYgQnCYlnBy8ZtvV6Ja0r 8tKAGLz10z3nMAUJbtngWlksQSsNhzAQlNDh3pmMl3PCNBjHOQqnpx5B4GMzxttf YBnNOOoMUvIsrQjw4nDqD4AOOY0HQdrL00FWquVkqi+KZNYyr8cIqpRucM021C5s dPU0Hh+D51cIla6SeZNwRDWCqhTmUu7wB4NgoB2SzwbakYQrxxHhXfmir9O1YJQ= = 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=i0Dfl8 AqBcD/DgHuTzbjOAGsS/Rj7tU10qSpJenuKsc=; b=ks0tmUwlRsB/4rsobWhvhM sOsiqxH83keKq2CuNyDl8q/aj4DdFeWPUMmh14N1LsQSYiNw6NXCjifOt3fAVkle fCOc0d0wmdc/IOQDcndtcxmr5xFoWBSNSFLV6pY89qtlfExz5v8x/T1paKLjTqdj pfXlKLejr4cZZ3cjwNS+lYW8iR0AkjKaxS3S+2xe6ZZbTatfqyHHI6y6RQIkyDCR qM/9Z6IREeJ4fqRsikaCp7mpthyhnbcGmJz53HkFPWdvrgdkUMQ9mvhVXqcZb74V 7d7kk9dBglBvEVfdKe27OqibLzYmKPVa6tgR85QrFcaMS+MF4n0QBNy7XyrVJ1aA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrledtgddugeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtg homh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C203C180091; Mon, 24 Feb 2020 16:10:00 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-947-gbed3ff6-fmstable-20200220v2 Mime-Version: 1.0 Message-Id: <3debc2a5-231f-4fd1-a0a7-193f5e8b181e@dogfood.fastmail.com> In-Reply-To: References: <644c56e0-9949-41c1-bed0-621142859788@beta.fastmail.com> <9c095bdb-b09b-49af-aab4-a53fb743d3de@beta.fastmail.com> Date: Tue, 25 Feb 2020 08:10:01 +1100 From: "Bron Gondwana" To: jmap@ietf.org, "Raphael OUAZANA" Content-Type: multipart/alternative; boundary=f55f017971e74838805bade39ae4d842 Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-mdn-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 21:10:04 -0000 --f55f017971e74838805bade39ae4d842 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Raphael, It would be good to get this edit done soon if you can so we can get the= document underway before Vancouver. Cheers, Bron. On Sat, Feb 8, 2020, at 00:54, Raphael OUAZANA wrote: >=20 > Le 7 f=C3=A9vrier 2020 05:17, de murch@fastmailteam.com >> Or call the method /send or /submit, since it both generates the MDN = and submits it to an MSA. >=20 > Yes, /send seems a better naming for me, it was one of my first propos= al (in fact I put it in MessageSubmission so it was MessageSubmission/se= ndMDN). >>=20 >> Also, should the request have an additional boolean argument which di= ctates whether the original message should be included in the MDN? >>=20 >=20 > For me MDN are lightweight notifications with almost, and we tend to u= se them only for automatic handling, where the original message is ignor= ed. > But you are right, being part of the specification it could be an adde= d option. > 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 --f55f017971e74838805bade39ae4d842 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Raphael,
It would be good to get this ed= it done soon if you can so we can get the document underway before Vanco= uver.

Cheers,
=
Bron.

On S= at, Feb 8, 2020, at 00:54, Raphael OUAZANA wrote:


Le 7 f=C3=A9vrier 2020 05:1= 7, de murch@fastmailteam.com

Or call the = method /send or /submit, since it both generates the MDN and submits it to an MSA.


Ye= s, /send seems a better naming for me, it was one of my first proposal (= in fact I put it in MessageSubmission so it was MessageSubmission/sendMD= N).


Also, should the request have an ad= ditional boolean argument which dictates whether the original message should be included in the MDN?



For me MDN a= re lightweight notifications with almost, and we tend to use them only f= or automatic handling, where the original message is ignored.

= But you are right, being part of the specification it could be an added = option.

Regards,

Rapha=C3=ABl.


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

=

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

--f55f017971e74838805bade39ae4d842-- From nobody Wed Feb 26 10:08:26 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 D5FF83A0F9B; Wed, 26 Feb 2020 10:08:24 -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.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <158274050478.22951.12697677021706269547@ietfa.amsl.com> Date: Wed, 26 Feb 2020 10:08:24 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-05.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 18:08:25 -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-05.txt Pages : 12 Date : 2020-02-26 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mdn-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 26 10:21:18 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 0D1D93A10AE for ; Wed, 26 Feb 2020 10:21:13 -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 AIPn0gWhyXuY for ; Wed, 26 Feb 2020 10:21:10 -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 1A1023A10B6 for ; Wed, 26 Feb 2020 10:21:09 -0800 (PST) Received: from linagora.com (unknown [10.233.69.202]) by outgoing.linagora.com (Postfix) with ESMTP id 693DF3B; Wed, 26 Feb 2020 18:21:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1582741267; bh=pYkNWn+smwbXVqrUvK9VhrkFz5gysIWyWIR8jYeMjgs=; h=From:Reply-To:To:Cc:Subject:Date:References:In-Reply-To:From; b=giLb3xbpkdusbFP6PjaaWVFOWDjQ57B7jw+LPpwM9hOLYhfSvvkUhXTLnCtZtsQwB 8Te0llqRj4u22q/Wjc8t2PjXpRolKNknuwsLMY/7wvn+GKBSRGLtUtD2JryLQjNT3A reNtxicerQImOy7T49wZld82SG/HwLMCnI+RLHnROQRxvds+ZHLPqF9a5rp8LzqgRs MUXuYFo/5YXcoJaipOjIo83I+DyCiMAmnGEhaAqL24l4DAx6oC8Kyy5Fe6QSashtE8 TXwfBsTosxgv0Ei4iXAawdiL7H3/N3VXz2KLXVhbaTvRurzfQlGmwMlakgPUJTi3g7 hu4+EaQlQk7Zw== 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: Bron Gondwana , "jmap@ietf.org" , Ken Murchison Cc: Raphael OUAZANA Message-ID: Date: Wed, 26 Feb 2020 18:21:05 +0000 References: <644c56e0-9949-41c1-bed0-621142859788@beta.fastmail.com> <9c095bdb-b09b-49af-aab4-a53fb743d3de@beta.fastmail.com> In-Reply-To: Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-mdn-04 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 18:21:18 -0000

Hello,

It seems I missed this point while updating the draft.

I will wait for 1 or 2 days for remarks, and update again the draft with this added argument and eventual fixes from remarks.

Regards,

Raphaël.

Le 7 février 2020 14:54, de rouazana@linagora.com


Le 7 février 2020 05:17, de murch@fastmailteam.com

Or call the method /send or /submit, since it both generates the MDN and submits it to an MSA.


Yes, /send seems a better naming for me, it was one of my first proposal (in fact I put it in MessageSubmission so it was MessageSubmission/sendMDN).

Also, should the request have an additional boolean argument which dictates whether the original message should be included in the MDN?


For me MDN are lightweight notifications with almost, and we tend to use them only for automatic handling, where the original message is ignored.

But you are right, being part of the specification it could be an added option.

Regards,

Raphaël.

From nobody Fri Feb 28 07:19:39 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 E50733A083C; Fri, 28 Feb 2020 07:19:19 -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: <158290315985.22320.3662036498962625010@ietfa.amsl.com> Date: Fri, 28 Feb 2020 07:19:19 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-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: Fri, 28 Feb 2020 15:19:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : Handling Message Disposition Notification with JMAP Author : Raphaël Ouazana Filename : draft-ietf-jmap-mdn-06.txt Pages : 12 Date : 2020-02-28 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mdn-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 Fri Feb 28 14:36:35 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 3CE863A1F58; Fri, 28 Feb 2020 14:35:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: aamelnikov@fastmail.fm, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292930523.19931.5542897307148076221@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:05 -0800 Archived-At: Subject: [Jmap] jmap - Requested session has been scheduled for IETF 107 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:13 -0000 Dear Jim Fenton, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jmap Session 1 (1:00 requested) Tuesday, 24 March 2020, Afternoon Session III 1740-1840 Room Name: Plaza A size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/jmap.ics Request Information: --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Jim Fenton Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: doh oauth saag iasa2 dmarc artarea uta dispatch extra calext Technology Overlap: t2trg core lamps ace httpbis tls txauth People who must be present: Bron Gondwana Jim Fenton Alexey Melnikov Resources Requested: Special Requests: One co-chair is unavailable Thursday PM and Friday, so please avoid those times if possible. Many of the same people attend both JMAP and EXTRA, so please see if they can be placed consecutively. --------------------------------------------------------- From nobody Fri Feb 28 19:43: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 A71733A0AB6 for ; Fri, 28 Feb 2020 19:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=b4crxJoX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1iGOwgOz 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 96DeaF56DYCX for ; Fri, 28 Feb 2020 19:43:32 -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 F33263A0AA8 for ; Fri, 28 Feb 2020 19:43:31 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DC34721E56; Fri, 28 Feb 2020 22:43:27 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 28 Feb 2020 22:43:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=ag4h AFG3TA/Qz2KLxLswKRZ1/s7OdM9H6v1yU8y2q1M=; b=b4crxJoX6EbpO9K471CQ +nkOqSzCnZDHhm7F9oKTPHMrziKcqT52RJ36jFigr+cNFhqStGMw+gjcrlggPwyt r8CsOSmNYaRrX/KLEkbIchRrnv+BIDFknoP/25tiEOL1CGBRXhI/L31xc8AYme5B tj/oNb0TEaErew2oc3RO0bHlpBqV7+wN4vEV23h+kWu0sOk4V9E3c6WVNfpRYUNz icz+IQ1ix4akw41oaq/ZZIMh66a0cBi6X45FdMEbrsjPr3Qv9f7u1wksyVWJNxQs tk86kk/XShwx+/GQrX3r38I/BV5X5FPv6ibFsTmUXcnvH13W+En4CyRdQ4mLGoJ0 cQ== 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=ag4hAF G3TA/Qz2KLxLswKRZ1/s7OdM9H6v1yU8y2q1M=; b=1iGOwgOzpS4NQXry83rdjZ aQBw6LBdsnrSlbT0gtdZ8gXQpOZUsqI2tnmmTXDg7hAeTe5kfLIh4D+iZ2civiRI IKHV41ZZ4PZwhOUb78oa7TOjslZG5Ulhk/+YEhl3TuWwvt6iSpshJR1MSnrVEaQT pgNb3CZvCmO8aw+RvRSZ5u7YP8yzcejSgsLeHJyGQKpRhUPpW3TR2zEHwfnsSKgc PLXcBYgO1BUh++vdCMynIy4LQIfX3PCVuA1n42UXouvDlnRxYEVAoYWkckW1mQPw rLZ7uTG31ELJm7q0E/uK0pTAPXSBBO1hT3t1L67dNtzomEjBY18cgsW0h3an7ojQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrleelgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2F581180091; Fri, 28 Feb 2020 22:43:27 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-967-g014f925-fmstable-20200226v1 Mime-Version: 1.0 Message-Id: <85703b8c-777f-4cae-a282-8dfc55b06ca2@dogfood.fastmail.com> In-Reply-To: <158290315985.22320.3662036498962625010@ietfa.amsl.com> References: <158290315985.22320.3662036498962625010@ietfa.amsl.com> Date: Sat, 29 Feb 2020 14:43:29 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: "Raphael OUAZANA" Content-Type: multipart/alternative; boundary=2027fe7afcef42aabe42fcff28e08f99 Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mdn-06.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 03:43:39 -0000 --2027fe7afcef42aabe42fcff28e08f99 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Raphael for uploading this - unfortunately I have identified one = more issue :( The $MDNSent keyword is mentioned in many places. This conflicts with RF= C8621: *"Because JSON is case sensitive, servers MUST return keywords in lowerc= ase."** * I think it's necessary to add some text about the fact that keywords are= always lowercase in JMAP and to change all references to $MDNSent from = that point onwards to be lowercase - in particular the example in sectio= n 3.1 needs to be lowercase. Other than this, you've resolved all the questions I had - and I don't s= ee any others, so I'm happy to submit once this issue is resolved. Cheers, Bron. On Sat, Feb 29, 2020, at 02:19, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. > This draft is a work item of the JSON Mail Access Protocol WG of the I= ETF. >=20 > Title : Handling Message Disposition Notification with JMAP > Author : Rapha=C3=ABl Ouazana > Filename : draft-ietf-jmap-mdn-06.txt > Pages : 12 > Date : 2020-02-28 >=20 > Abstract: > This document specifies a data model for handling [RFC8098] MDN > messages with a server using JMAP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-jmap-mdn-06 > https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jmap-mdn-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of subm= ission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --2027fe7afcef42aabe42fcff28e08f99 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Raphael for uploading this - unfortunately I have i= dentified one more issue :(
<= br>
The $MDNSent keyword is menti= oned in many places.  This conflicts with RFC8621:

<= i>"Because JSON is case sensitive, servers MUST return keywords in lower= case."

<= div style=3D"font-family:Arial;">I think it's necessary to add some text= about the fact that keywords are always lowercase in JMAP and to change= all references to $MDNSent from that point onwards to be lowercase - in= particular the example in section 3.1 needs to be lowercase.
<= div style=3D"font-family:Arial;">
Other than this, you've resolved all the questions I had - and I do= n't see any others, so I'm happy to submit once this issue is resolved.<= br>

Cheers,

Br= on.

On Sat, Fe= b 29, 2020, at 02:19, internet-drafts@ietf.org wrote:

<= div style=3D"font-family:Arial;">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 W= G of the IETF.

       = Title           : Han= dling Message Disposition Notification with JMAP
        Author&nb= sp;         : Rapha=C3=ABl Ouaza= na
Filename   =      : draft-ietf-jmap-mdn-06.txt
Pages       =     : 12
Date&= nbsp;           : 2020= -02-28

Abstract:
   This document specifies a data model for handling [RFC809= 8] MDN
   messages = with a server using JMAP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dra= ft-ietf-jmap-mdn/

<= div style=3D"font-family:Arial;">There are also htmlized versions availa= ble at:
https://tools.ietf.or= g/html/draft-ietf-jmap-mdn-06
https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-06
<= div style=3D"font-family:Arial;">
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf= -jmap-mdn-06


= Please note that it may take a couple of minutes from the time of submis= sion
until the htmlized versi= on and diff are available at tools.ietf.org.

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


___________________________________= ____________
Jmap mailing lis= t
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap=


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


--2027fe7afcef42aabe42fcff28e08f99--