From nobody Wed Jun 10 05:40:51 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 B86F73A0598; Wed, 10 Jun 2020 05:40:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: barryleiba@computer.org, brong@fastmailteam.com, jmap-chairs@ietf.org, jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159179284946.9932.7370334841865728593@ietfa.amsl.com> Date: Wed, 10 Jun 2020 05:40:49 -0700 Archived-At: Subject: [Jmap] jmap - New Meeting Session Request for IETF 108 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, 10 Jun 2020 12:40:50 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: 15 Conflicts to Avoid: People who must be present: Barry Leiba Jim Fenton Bron Gondwana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jun 10 05:45: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 2B4C13A0798 for ; Wed, 10 Jun 2020 05:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_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=JZYkVFGj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IDCrkzRN 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 xExFR-kE3_qu for ; Wed, 10 Jun 2020 05:45:35 -0700 (PDT) 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 8AC093A03F2 for ; Wed, 10 Jun 2020 05:45:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B57995C00E1; Wed, 10 Jun 2020 08:45:34 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 10 Jun 2020 08:45:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=4g99 lHYF4KKMd9017cBFrorFzs4d/ca8sxF7+o8m36c=; b=JZYkVFGjo+ErAf1IXrgH klbgrSpcbgV+vJV3WWapkz2Dbyk5GzUQys3uLQ+IAHtj5F1A5kGFpcdBDnPaw6K7 N0f/SqkVJ7gPaUfl63bBRx7YbQ5uqrvwmzhWc1lmRcsjIGvF/inseHD3uTocXedO DF+S8Z45kSCVOPMxc0BU3X6h1kucrTBj/W9Qh01Flc8oPKJv5ebxsTY3Zd/psYLx +zWhnxvVJsBUVdGKEwshyGEWee+PBkRfy7bpN3yMIO3gJz4Si5yuoiijjDtE+v+3 CcfYqNHkxRMwCqBVF/8l+vu1sqXaMNgms7Yhw5H/iLh6soOGsGZ9+PpL+SiU2sen 3A== 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=fm3; bh=4g99lH YF4KKMd9017cBFrorFzs4d/ca8sxF7+o8m36c=; b=IDCrkzRN8QdDrIF09AfzaC QhoN1r4min0wBdehnq3cL7ph5WZN7dsNuayva1aj3dpSpNSA4YAFm9e88VJlUZ2T Pl5xzVCkO9gYg8aKwpO2frr51UpZzdW6qhE9bAoNomZ0D0Pn0f3NAriTMFXeaPWW iU1EubyHwvKoypif0bs+rwd95U8RAZJuUVFApP/lG4rpBjGRfj0B2UBsEWd6s2Vj dfigkmjsP8iJwWi+42bvC5qHXKJ20NweAe5khFHWYNWgzdAwW4/AX8L2aCNK+LIe TPB69DRegdnrRCckcNl3JGO8Q/Akz5PcbLPPlCWtt0pX6jC6iIVlpWeX69jdMYAQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehiedgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepvefgieekudeludeuvedvgedtieffudfhieffgedtudet ffeiteffudfhudevuedvnecuffhomhgrihhnpehlihhnrghgohhrrgdrtghomhdpihgvth hfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 30343180091; Wed, 10 Jun 2020 08:45:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990 Mime-Version: 1.0 Message-Id: <6d2919ca-9026-484e-885c-14e8b2bca05e@dogfood.fastmail.com> In-Reply-To: <050acaf4-05fd-448e-ad64-8313c14f6d23@dogfood.fastmail.com> References: <7e3a193f-6515-4d32-85a0-88bf624ba97c@www.fastmail.com> <050acaf4-05fd-448e-ad64-8313c14f6d23@dogfood.fastmail.com> Date: Wed, 10 Jun 2020 22:45:13 +1000 From: "Bron Gondwana" To: jmap@ietf.org, "Raphael OUAZANA" Cc: "Raphael OUAZANA" Content-Type: multipart/alternative; boundary=4a642b12888541b7b2a5a00a2e367ab8 Archived-At: Subject: Re: [Jmap] draft-ietf-jmap-mdn-06 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 12:45:38 -0000 --4a642b12888541b7b2a5a00a2e367ab8 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Oops, I realise I didn't also send this to the list when I replied befor= e and may have got the wrong address. I found some issues when putting together the shepherding doc and doing = a really thorough readthrough of the spec and also looking at our implem= entation. It would be good to be prepared to talk about these things at the interi= m meeting next week. Cheers, Bron. On Wed, May 20, 2020, at 16:46, Bron Gondwana wrote: > My apologies for the delay. I realised our implementation is incomplet= e, so I sat down with Neil (virtually!) and did a full readthrough. What= do you know, we found more stuff to query. Sorry about that. >=20 > *Abstract:* >=20 > This may be a little too short - it doesn't explain what JMAP is or wh= y it would be of interest. Possibly also something that the editors will= pick up on, but it would be good to make it a little more "this is what= JMAP is, and this is why having MDN support in JMAP is a good idea". >=20 > *1.3 Capabilities Object* >=20 > I would move both MDN/send and MDN/parse as being only present if urn:= ietf:params:jmap:mdn is present in the accountCapabilities. Given that M= DN/parse works on a blobId, and blobIds are per account, it makes sense = that both of them require an account. >=20 > *2. MDN: forEmailId* >=20 > I would reverse the expression change from: >=20 > This argument can only be null when the MDN object is a server response for the "MDN/parse" method. >=20 > And instead say "This property MUST NOT be null for MDN/send, but may = be null in the response from MDN/parse". That way we're not making state= ments about potential future extensions. >=20 > *2. MDN: finalRecipient* >=20 > We discussed that wildcard identities are possible in JMAP, which coul= d make calculating finalRecipient more difficult. I would do two things = here: >=20 > 1) make finalRecipient optional on MDN/send - if set, it overrides the= value that would be calculated from the Identity. >=20 > 2) add to Security Considerations that the server SHOULD validate that= the user is permitted to use the finalRecipient value and return a forb= iddenFrom error if not. >=20 > *2. MDN: Disposition Object* >=20 > RFC8098 defines the strings as case insensitive. JSON values don't hav= e to be case sensitive, but it would be much more like the rest of JMAP = if you defined these values to be only lowercase via JMAP, e.g. >=20 > o sendingMode: "String" This MUST be one of the following strings:= "mdn-sent-manually" / "mdn-sent-automatically" >=20 > And also add some text which says that these are defined case insensit= ive in 8098 but are case sensitive in this RFC and MUST be converted to = lowercase by /parse. >=20 > If you disagree and think they should match what's in the raw file, th= en document needs to specify that these particular values are case insen= sitive. >=20 > *2.1 MDN Send*** >=20 > You refer an "MDNError" but don't actually define it. From the example= s it's clear that this is a SetError. I think it would be best to change= that to: >=20 > o notSent: "Id[SetError]|null" >=20 > Having done so, you can then enumerate the expected error types and re= asons, with reference to the existing registry (apart from the new mdnAl= readySent error). >=20 > *2.1 MDN Send part 2* >=20 > This paragraph has problems: >=20 > If the Account Id or Identity id given cannot be found, the MDN sending is rejected with an "invalidProperties" error. >=20 > One is the inconsistent spelling of accountId and identityId which I'm= sure the editors would capture, but you may as well fix upfront. >=20 > Secondly, the correct error here in JMAP is invalidArguments and it re= jects the entire method call, as these are method level arguments rather= than properties on an individual MDN. >=20 > *2.1 MDN Send implicit Email/set*** >=20 > It is not clear from this text whether an implicit Email/set is issued= if there are no successfully sent MDNs (i.e. 'sent' is null). I am happ= y with either, but it needs to be clear! >=20 > It would be good to explain here exactly how the implicit Email/set wo= uld look, e.g. >=20 > For the following method call: >=20 > [ "MDN/send", { "accountId": "ue150411c", "identityId": "I64588216", "send": { "k1546": { "forEmailId": "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" } } } }, "0" ] >=20 > The implicit Email/set call would be equivalent to: >=20 > [ "Email/set", { "accountId": "ue150411c", "update": { "Md45b47b4877521042cec0938": { "keywords/$mdnsent": true } } }, "0" ] >=20 > *2.2 MDN/parse*** >=20 > There reasons for "forEmailId" to be null could be expanded to include= : "the server can't efficiently calculate the related email". >=20 > (I guess if there's more than one email with the same "Message-Id" hea= der but different emailId then what gets returned here is undefined - co= uld be any one of the emails, or could be null) >=20 > Again, the invalidProperties error should be invalidArguments. >=20 > *3.1 Sending an MDN*** >=20 > The Email/set example is incorrect. Since the implicit request is a pa= tch to "keywords/$mdnsent", a server would not be expected to echo the f= ull value of the keywords property in the result, since it didn't unilat= erally change it. I would expect this response: >=20 > [ "Email/set", { "accountId": "ue150411c", "oldState": "23", "newState": "42", "updated": { "Md45b47b4877521042cec0938": {} } }, "0" ]] >=20 > Where "updated" maps the emailId from the forEmailId property to an em= pty object. >=20 > *All examples need to either have sendingMode changed to lowercase or = the definition changed as above.* >=20 > *5. Security Considerations*** >=20 > As mentioned above, we should talk about validating the finalRecipient= if we allow it to be set by the client. >=20 >=20 > Again, sorry about it taking so long to get back with this feedback - = I bet you're frustrated at how slow the process is, and this time it's e= ntirely my fault. I look forward to reviewing a -10 and actually shepher= ding this thing for real! >=20 > Cheers, >=20 > Bron. >=20 > On Tue, May 5, 2020, at 22:44, Bron Gondwana wrote: >> Hi Raphael - I got Ken to follow up to you on it since he wrote our i= mplementation. I see you've dealt with that in -09. >>=20 >> I'll do the shepherd writeup this week and submit it this week. >>=20 >> Cheers, >>=20 >> Bron. >>=20 >> On Wed, Apr 29, 2020, at 00:26, Raphael OUAZANA wrote: >>> Hi Bron, >>> Any news on this? >>> Thanks, >>> Rapha=C3=ABl. >>> Le 20 mars 2020 09:24, de rouazana@linagora.com >>>> I agree, I think I've fixed every comments with -08. >>>> Thanks, >>>> Rapha=C3=ABl. >>>> Le 20 mars 2020 06:43, de brong@fastmailteam.com >>>>> Thanks for that.=20 >>>>>=20 >>>>> With that done, I BELIEVE that we -08 resolves every issue outstan= ding. Do you agree? I'll go ahead and do the shepherd writeup if so. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Bron. >>>>>=20 >>>>> On Thu, Mar 19, 2020, at 21:17, Raphael OUAZANA wrote: >>>>>>=20 >>>>>> Le 18 mars 2020 19:09, de murch@fastmail.com >>>>>>>=20 >>>>>>> On 3/18/20 1:42 PM, Raphael OUAZANA wrote: >>>>>>>> Hello, >>>>>>>> Le 6 mars 2020 20:35, de murch@fastmail.com=20 >>>>>>>>>=20 >>>>>>>>> On 3/5/20 7:40 PM, Ken Murchison wrote: >>>>>>>>> > A few questions as I implement this in Cyrus: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> > - The JMAP server may not be able to determine the Final-Rec= ipient of=20 >>>>>>>>> > the original message was Bcc'd or sent to an alias. Should t= he MDN=20 >>>>>>>>> > object include a 'from' property? >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> It should match the email of the account, no? >>>>>>>=20 >>>>>>> If the email was sent to an email alias and eventually delivered= to the underlying account, the sender of the MDN might want to have the= MDN use the alias so as not to leak the real address of the account. >>>>>>>=20 >>>>>>>> Or maybe we should ask for an identity when sending an MDN, so = that the user can choose which email appears in this field? >>>>>>>=20 >>>>>>> Yes, that is what I was thinking. If the user doesn't provide a = from address, then we can default to the email of the account. >>>>>>=20 >>>>>> I will add an identity parameter, like in MessageSubmission. I wi= ll make it mandatory because for me it's not clear how we can get an ema= il address from an account. >>>>>> Regards, >>>>>> Rapha=C3=ABl. >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> Jmap mailing list >>>>>> Jmap@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jmap >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Bron Gondwana, CEO, Fastmail Pty Ltd >>>>> brong@fastmailteam.com >>>>>=20 >>>>>=20 >>=20 >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 >=20 > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com >=20 >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --4a642b12888541b7b2a5a00a2e367ab8 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Oops, I realise I didn't also send this to the list w= hen I replied before and may have got the wrong address.

= I found some issues when putting together the shepherding doc and doing = a really thorough readthrough of the spec and also looking at our implem= entation.

It would be good to be prepared to talk about t= hese things at the interim meeting next week.

Cheers,
=

Bron.

<= div>On Wed, May 20, 2020, at 16:46, Bron Gondwana wrote:
My apologies for the delay.  I realised our implementation is in= complete, so I sat down with Neil (virtually!) and did a full readthroug= h.  What do you know, we found more stuff to query.  Sorry abo= ut that.

Abstract:

This may be a li= ttle too short - it doesn't explain what JMAP is or why it would be of i= nterest.  Possibly also something that the editors will pick up on,= but it would be good to make it a little more "this is what JMAP is, an= d this is why having MDN support in JMAP is a good idea".

1.3 Capabilities Object

I would move both MDN/sen= d and MDN/parse as being only present if urn:ietf:params:jmap:mdn is pre= sent in the accountCapabilities.  Given that MDN/parse works on a b= lobId, and blobIds are per account, it makes sense that both of them req= uire an account.

2. MDN: forEmailId

I would reverse the expression change from:

This argument can only be null when the M=
DN object
      is a server response for the "MDN/parse" method.

An= d instead say "This property MUST NOT be null for MDN/send, but may be n= ull in the response from MDN/parse".  That way we're not making sta= tements about potential future extensions.

2. MDN: fin= alRecipient

We discussed that wildcard identities are= possible in JMAP, which could make calculating finalRecipient more diff= icult.  I would do two things here:

1) make finalRec= ipient optional on MDN/send - if set, it overrides the value that would = be calculated from the Identity.

2) add to Security Consi= derations that the server SHOULD validate that the user is permitted to = use the finalRecipient value and return a forbiddenFrom error if not.
=

2. MDN: Disposition Object

RFC8098 defines t= he strings as case insensitive.  JSON values don't have to be case = sensitive, but it would be much more like the rest of JMAP if you define= d these values to be only lowercase via JMAP, e.g.

   o  sendingMode: "String" This MUS=
T be one of the following strings:
      "mdn-sent-manually" / "mdn-sent-automatically"

And also add some text which says that these are defined case insensiti= ve in 8098 but are case sensitive in this RFC and MUST be converted to l= owercase by /parse.
If you disagree and think they = should match what's in the raw file, then document needs to specify that= these particular values are case insensitive.

2.1 MDN= Send

You refer an "MDNError" but don't actual= ly define it.  From the examples it's clear that this is a SetError= .  I think it would be best to change that to:

o  notSent: "Id[SetError]|null"
<=
/pre>

Having done so, you can then enumerate the expected error typ=
es and reasons, with reference to the existing registry (apart from the =
new mdnAlreadySent error).
2.1 MDN Send part 2
=


This paragraph has problems:

   If the Account Id or Identity id given can=
not be found, the MDN
   sending is rejected with an "invalidProperties" error.

One is the inconsistent spelling of accountId and identityId which I'm =
sure the editors would capture, but you may as well fix upfront.

Secondly, the correct error here in JMAP is invalidArguments and it rejects =
the entire method call, as these are method level arguments rather than =
properties on an individual MDN.

2.1 MDN Send implicit=
 Email/set

It is not clear from this text whet=
her an implicit Email/set is issued if there are no successfully sent MD=
Ns (i.e. 'sent' is null).  I am happy with either, but it needs to =
be clear!

It would be good to explain here exactly how th=
e implicit Email/set would look, e.g.

For the following m=
ethod call:

  =
     [ "MDN/send", {
         "accountId": "ue150411c",
         "identityId": "I64588216",
         "send": {
           "k1546": {
             "forEmailId": "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"
             }
           }
         }
       }, "0" ]

The implicit Email/set call would be equi=
valent to:

   =
    [ "Email/set", {
         "accountId": "ue150411c",
         "update": {
           "Md45b47b4877521042cec0938": {
             "keywords/$mdnsent": true
           }
         }
       }, "0" ]

2.2 MDN/parse

There reasons for "forEmailId" to be null could be expanded=
 to include: "the server can't efficiently calculate the related email".=


(I guess if there's more than one email with the same "M=
essage-Id" header but different emailId then what gets returned here is =
undefined - could be any one of the emails, or could be null)
<=
div style=3D"font-family:Arial;">
Again, the invalidProperties error should be invalidArguments.
<=
/div>

3.1 Sending an MDN

The Email/set=
 example is incorrect.  Since the implicit request is a patch to "k=
eywords/$mdnsent", a server would not be expected to echo the full value=
 of the keywords property in the result, since it didn't unilaterally ch=
ange it.  I would expect this response:

     [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]

Where "updated" maps the emailId from the =
forEmailId property to an empty object.

All examples n=
eed to either have sendingMode changed to lowercase or the definition ch=
anged as above.

5. Security Considerations<=
/b>

As mentioned above, we should talk about validating t=
he finalRecipient if we allow it to be set by the client.


Again, sorry about it takin=
g so long to get back with this feedback - I bet you're frustrated at ho=
w slow the process is, and this time it's entirely my fault.  I loo=
k forward to reviewing a -10 and actually shepherding this thing for rea=
l!

Cheers,
Bron.

On Tue, May 5, 2020, at 22:44, Bron Gon=
dwana wrote:
=

Hi Raphael - I got Ken to follow up to=
 you on it since he wrote our implementation.  I see you've dealt w=
ith that in -09.

I'll do the shepherd writeup this week a=
nd submit it this week.

<=
/div>
Cheers,

Bron.
<=
/div>

On Wed, Apr 29, 20=
20, at 00:26, Raphael OUAZANA wrote:
Hi Bron,
Any news on this?
Thanks,
Rapha=C3=ABl.
Le 20 mars 2020 0=
9:24, de rouazana@linagora.com
I agree, I=
 think I've fixed every comments with -08.
Thanks,
R=
apha=C3=ABl.
Le 20 mars 2020 06:43, de brong@fastmailt=
eam.com
Th=
anks for that. 

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

Cheers,

=
Bron.

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

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

On 3/18/20 1:42 PM, Raphael OUAZANA
      wrote:
Hello,
Le =
6 mars 2020 20:35, de murch@fastmail.com 

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


> - The JMAP ser=
ver may not be able to determine the
          Final-Recipient of 
> the original message wa=
s Bcc'd or sent to an alias. 
          Should the MDN 
> object include a 'from' pro=
perty?


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

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

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

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


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

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


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



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



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



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



--4a642b12888541b7b2a5a00a2e367ab8--


From nobody Wed Jun 10 05:47:25 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 787DC3A07AE for ; Wed, 10 Jun 2020 05:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level: 
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=dAFEm2mu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I24PNc2j
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 Lhl7BOBX-aux for ; Wed, 10 Jun 2020 05:47:22 -0700 (PDT)
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 F265E3A07AC for ; Wed, 10 Jun 2020 05:47:21 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2AF635C00CD for ; Wed, 10 Jun 2020 08:47:20 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 10 Jun 2020 08:47:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=SbQ4HiQ RAKfqXMj9Rg58966OMecRF1YQVkL51sW9ciE=; b=dAFEm2muaAI2BKybRdcyVHI yDQgDJ4Cpq5IVAAhXEnhexWpAgM98DyuGzQm4BqmWQskbLGZqbfK52TI4DWurT8q g8PPes/igQCcc5jAOv398iZrm9b/Sp/CBS3gfYNZSxvB9nmAAkRKmJRtmLZf7f8T ZfHtfV1kSmRU2/pJtoTKV6EayTjAEQPmoCgvOgOprJNaaZs4A+x5wlKcjtU55jTS dgQYJVArhBD5JOOpa3QWrA+cB8ay50IHLtqO7ntlfA22tW9GG51Jq97Q75bTThOT 7fOxUCXR9zDBPz4P81GoAXIFucWcKPl6fs46pTZjwVub9ecY0kUXl/UPKzZhmOQ= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=SbQ4Hi QRAKfqXMj9Rg58966OMecRF1YQVkL51sW9ciE=; b=I24PNc2ju/okyfs1oen0B1 RK3gxTu872vpaJK12DAk3tWdfGI47JxCaEuriNCi2p36vVBGb1DiOsgDE3bLhQVt DHG2rWSSbxSv1MT5SUDEGJvDJ/Y7NNMk1MVmixbDTLJmFc+OnOAoIzOk61l7/oez VYWUoHnYea/8bAt+n1DhjR0Fh67YqG+15+LMvNdFSgmTXGaILrN5DoZp4klBfZ92 y9Gnyj16yq730Q3Cwue8Ghchg7ML99LkWIQyTx3CYThw4OYZ02U3s+1EnR834WVZ jRWeCqp/BjR+WIx/gaJkNGZmyUTqHeTFyr4v7RZsevTkWjsShdARc5kz0vfyVdPw ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehiedgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffveefiefgje evteehheelgeetleetveeguedthfehgffhtdejhfdvhefhtdekgfenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5FC74180091; Wed, 10 Jun 2020 08:47:19 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <159179284946.9932.7370334841865728593@ietfa.amsl.com>
References: <159179284946.9932.7370334841865728593@ietfa.amsl.com>
Date: Wed, 10 Jun 2020 22:46:59 +1000
From: "Bron Gondwana" 
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=1e7e42d66e594fc29e9f2b5a4fb27d11
Archived-At: 
Subject: Re: [Jmap] jmap - New Meeting Session Request for IETF 108
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, 10 Jun 2020 12:47:23 -0000

--1e7e42d66e594fc29e9f2b5a4fb27d11
Content-Type: text/plain

I've put this request in to reserve us some space. I could have sworn I already did one, but either datatracker ate it or I never completed submission.

We'll know for sure if we need it after our interim meeting, which is unfortunately after the cutoff date! We've made very slow progress recently, so I am keen to have something to force us to keep momentum!

Cheers,

Bron.

On Wed, Jun 10, 2020, at 22:40, IETF Meeting Session Request Tool wrote:
> 
> 
> A new meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group.
> 
> 
> ---------------------------------------------------------
> Working Group Name: JSON Mail Access Protocol
> Area Name: Applications and Real-Time Area
> Session Requester: Bron Gondwana
> 
> 
> Number of Sessions: 1
> Length of Session(s): 50 Minutes
> Number of Attendees: 15
> Conflicts to Avoid: 
> 
> 
> 
> 
> 
> 
> 
> 
> People who must be present:
>  Barry Leiba
>  Jim Fenton
>  Bron Gondwana
> 
> Resources Requested:
> 
> Special Requests:
> 
> ---------------------------------------------------------
> 
> 
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap
> 

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


--1e7e42d66e594fc29e9f2b5a4fb27d11
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


I've put this request in to reserve us some space.  I=
 could have sworn I already did one, but either datatracker ate it or I =
never completed submission.
<=
br>
We'll know for sure if we nee=
d it after our interim meeting, which is unfortunately after the cutoff =
date!  We've made very slow progress recently, so I am keen to have=
 something to force us to keep momentum!

Cheers,

Bron.

On Wed, Jun 10, 2020, at 22:40, IETF Meet=
ing Session Request Tool wrote:


A new m=
eeting session request has just been submitted by Bron Gondwana, a Chair=
 of the jmap working group.
<=
br>

---------------------------------------------------------=

Working Group Name: JSON Mai=
l Access Protocol
Area Name: =
Applications and Real-Time Area
Session Requester: Bron Gondwana


Number of Sessions: 1
Length of Session(s):  50 Minutes
Number of Attendees: 15
Conflicts to Avoid: 








People who must be present:
  Barry Leiba
&nb=
sp; Jim Fenton
  Bron Go=
ndwana

Resources Requested:

Special Request=
s:
  
------------------------------------------=
---------------


_______________________________________________
Jmap mailing list
https://www.ietf.org/mailman/listinfo/jmap
<=
div style=3D"font-family:Arial;">

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



--1e7e42d66e594fc29e9f2b5a4fb27d11--


From nobody Wed Jun 10 05:52:34 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 5A3A43A07BA for ; Wed, 10 Jun 2020 05:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=linagora.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24zFMWE5TxF1 for ; Wed, 10 Jun 2020 05:52:28 -0700 (PDT)
Received: from outgoing.linagora.com (outgoing.linagora.com [51.75.198.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24E13A07BB for ; Wed, 10 Jun 2020 05:52:27 -0700 (PDT)
Received: from linagora.com (unknown [10.233.69.48]) by outgoing.linagora.com (Postfix) with ESMTP id 9D26F3B; Wed, 10 Jun 2020 12:52:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1591793545; bh=azIBIJEg32sGI8Cmq7tDgYWdIw0iJ6pgM0wDsLdEuO0=; h=From:Reply-To:To:Subject:Date:References:From; b=sRtzoHnBixtOp4dyBUM2jrfhcqQrUoB4g5LFlmujQ61uIqPDCOwk1uaFaQzDRhjyv GhO3iQe6jp32HNyLCDmvSRmeQ4oyQoOv9+Qf5fzoOrHd2YNJN6/pzMtf4+igK+A66E AvMqZxG3MZsTWrWp21hMfADkjzHRCys5GfCrB0mGhUlUjoxyIVKo6aW3fx/QukeqeD XjScVDlX+/qJMEqhYF+Kz6yZT0WvpMeZqbY3Qi0oGpoF88OS3KBqXoVeLBaIKHeCaD r4taMSyW2WBaSmLK9r2LAO4Kf3MsQQL8koh5WXNeJNceMoHjtVEhalwqnMs7GbkQ4T OOOQINGemZW9A==
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" , Raphael OUAZANA , Bron Gondwana 
Message-ID: 
Date: Wed, 10 Jun 2020 12:49:31 +0000
References:        <7e3a193f-6515-4d32-85a0-88bf624ba97c@www.fastmail.com> <050acaf4-05fd-448e-ad64-8313c14f6d23@dogfood.fastmail.com>
Archived-At: 
Subject: Re: [Jmap] draft-ietf-jmap-mdn-06
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2020 12:52:32 -0000


Hi Bron,
No problem, I well received your previous answer, I was j=
ust very busy=2E
I will try to take some time to dig into your remark=
s soon=2E
Regards,
Rapha=C3=ABl=2E
Le 10 juin 2020=
 14:45, de brong@fastmailteam=2Ecom

p=2EMsoNormal,p=2EMsoNoSpacing{margin:0}
Oops, I realise I didn't also send this to the l=
ist when I replied before and may have got the wrong address=2E

I found some issues when putting together the shepherding doc and doing a =
really thorough readthrough of the spec and also looking at our implementat=
ion=2E

It would be good to be prepared to talk about these thin=
gs at the interim meeting next week=2E

Cheers,

Bron=
=2E

On Wed, May 2=
0, 2020, at 16:46, Bron Gondwana wrote:
My apologies for the=
 delay=2E  I realised our implementation is incomplete, so I sat down =
with Neil (virtually!) and did a full readthrough=2E  What do you know=
, we found more stuff to query=2E  Sorry about that=2E

=
Abstract:

This may be a little too short - it doesn't expla=
in what JMAP is or why it would be of interest=2E  Possibly also somet=
hing that the editors will pick up on, but it would be good to make it a li=
ttle more "this is what JMAP is, and this is why having MDN support in JMAP=
 is a good idea"=2E

1=2E3 Capabilities Object
<=
div style=3D"font-family:Arial;">
I would move both MDN/send and MDN/parse as being only present if urn:iet=
f:params:jmap:mdn is present in the accountCapabilities=2E  Given that=
 MDN/parse works on a blobId, and blobIds are per account, it makes sense t=
hat both of them require an account=2E

2=2E MDN: forEmailId<=
/b>

I would reverse the expression change from:

This argument can only be null w=
hen the MDN object
      is a server response for the "MDN/parse" method=2E=


And instead say "This property MUST NOT be null for MDN/send, =
but may be null in the response from MDN/parse"=2E  That way we're not=
 making statements about potential future extensions=2E

2=2E=
 MDN: finalRecipient

We discussed that wildcard identities =
are possible in JMAP, which could make calculating finalRecipient more diff=
icult=2E  I would do two things here:

1) make finalRecipie=
nt optional on MDN/send - if set, it overrides the value that would be calc=
ulated from the Identity=2E

=

2) add to Security Considerations t=
hat the server SHOULD validate that the user is permitted to use the finalR=
ecipient value and return a forbiddenFrom error if not=2E

2=2E MDN: Dispo=
sition Object

RFC8098 defines the strings as case insensiti=
ve=2E  JSON values don't have to be case sensitive, but it would be mu=
ch more like the rest of JMAP if you defined these values to be only lowerc=
ase via JMAP, e=2Eg=2E

   o  sendingMode: "String" This MUST be one of the following strings=
:
      "mdn-sent-manually" / "mdn-sent-automatically"

An=
d also add some text which says that these are defined case insensitive in =
8098 but are case sensitive in this RFC and MUST be converted to lowercase =
by /parse=2E

If you disagree and think they should match =
what's in the raw file, then document needs to specify that these particula=
r values are case insensitive=2E

2=2E1 MDN Send

You refer an "MDNError" but don't actually define it=2E  Fr=
om the examples it's clear that this is a SetError=2E  I think it woul=
d be best to change that to:
o  notSent: "Id[SetError]|null"

Having done so, you=
 can then enumerate the expected error types and reasons, with reference to=
 the existing registry (apart from the new mdnAlreadySent error)=2E

2=2E1 MDN Send part 2

This paragraph has problems:<=
br>

   If the Account=
 Id or Identity id given cannot be found, the MDN
   sending is rejected wi=
th an "invalidProperties" error=2E

One is the inconsistent spel=
ling of accountId and identityId which I'm sure the editors would capture, =
but you may as well fix upfront=2E

Secondly, the correct error =
here in JMAP is invalidArguments=
 and it rejects the entire method call, as these are method l=
evel arguments rather than properties on an individual MDN=2E

<=
b>2=2E1 MDN Send implicit Email/set

It is not clear =
from this text whether an implicit Email/set is issued if there are no succ=
essfully sent MDNs (i=2Ee=2E 'sent' is null)=2E  I am happy with eithe=
r, but it needs to be clear!
It would be good to explain here e=
xactly how the implicit Email/set would look, e=2Eg=2E

For the=
 following method call:

       [ "MDN/send", {
         "accountId": "ue150411c",
         "=
identityId": "I64588216",
         "send": {
           "k1546": {
        =
     "forEmailId": "Md45b47b4877521042cec0938",
             "subject": "Re=
ad receipt for: World domination",
             "textBody": "This receipt s=
hows that the email has been
                 displayed on your recipient's=
 computer=2E There is no
                 guaranty it has been read or unde=
rstood=2E",
             "reportingUA": "linagora=2Ecom; OpenPaaS",
       =
      "disposition": {
               "actionMode": "manual-action",
      =
         "sendingMode": "MDN-sent-manually",
               "type": "displa=
yed"
             }
           }
         }
       }, "0" ]

The=
 implicit Email/set call would be equivalent to:

       [ "Email/set", {
         "accountId=
": "ue150411c",
         "update": {
           "Md45b47b4877521042cec0938"=
: {
             "keywords/$mdnsent": true
           }
         }
       }=
, "0" ]

2=2E2 MDN/parse

Th=
ere reasons for "forEmailId" to be null could be expanded to include: "the =
server can't efficiently calculate the related email"=2E

(I gue=
ss if there's more than one email with the same "Message-Id" header but dif=
ferent emailId then what gets returned here is undefined - could be any one=
 of the emails, or could be null)

Again, the invalidProperties =
error should be invalidArguments=2E

3=2E1 Sending an MDN=


The Email/set example is incorrect=2E  Since the i=
mplicit request is a patch to "keywords/$mdnsent", a server would not be ex=
pected to echo the full value of the keywords property in the result, since=
 it didn't unilaterally change it=2E  I would expect this response:

     [ "Email/set",=
 {
       "accountId": "ue150411c",
       "oldState": "23",
       "newSta=
te": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
   =
    }
     }, "0" ]]

<=
div style=3D"font-family:Arial;">Where "updated" maps the emailId from the =
forEmailId property to an empty object=2E

All examples need =
to either have sendingMode changed to lowercase or the definition changed a=
s above=2E

5=2E Security Considerations

As mentioned above, we should talk about validating the finalRecipie=
nt if we allow it to be set by the client=2E


Again, sorry about it taking so long to get back =
with this feedback - I bet you're frustrated at how slow the process is, an=
d this time it's entirely my fault=2E  I look forward to reviewing a -=
10 and actually shepherding this thing for real!

Cheers,

Bron=2E

On =
Tue, May 5, 2020, at 22:44, Bron Gondwana wrote:
Hi Raph=
ael - I got Ken to follow up to you on it since he wrote our implementation=
=2E  I see you've dealt with that in -09=2E

I'll do the sh=
epherd writeup this week and submit it this week=2E

Cheers,
=


Bron=2E

=
On Wed, Apr 29, 2020, at 00:26, Raphael OUAZANA wrote:
Hi Bron,
Any news on=
 this?
Thanks,
Rapha=C3=ABl=2E
Le 20 =
mars 2020 09:24, de rouazana@linagora=2Ecom
=
I agree, I think I've fixed every comments with -08=2E
Thanks,
Rapha=C3=ABl=2E
Le 20 mars 2020 06:43, de brong@f=
astmailteam=2Ecom
Thanks for that=2E 

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

Cheers,

Bron=
=2E

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

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

On 3/18/20 1:42 PM, Raphael OUAZANA
      wrote:
<=
/div>
Hello,
Le 6 mars 2020 2=
0:35, de murch@fastmail=2Ecom 
=


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


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


It should match the email of the account, no?

If the email was sent to an email alias and eve=
ntually delivered
      to the underlying account, the sender of the MDN mi=
ght want to
      have the MDN use the alias so as not to leak the real add=
ress of
      the account=2E

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


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

I will add an identity parameter, =
like in MessageSubmission=2E I will make it mandatory because for me it's n=
ot clear how we can get an email address from an account=2E
Regar=
ds,
Rapha=C3=ABl=2E

_______________________________________________
Jmap maili=
ng list
Jmap@ietf=2Eorg
https://www=2Eietf=2Eor=
g/mailman/listinfo/jmap


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



--
=

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


--
  Bron Gondwan=
a, CEO, Fastmail Pty Ltd
  brong@fastmailteam=2Ecom
<=
/div>



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





From nobody Wed Jun 10 05:56:53 2020
Return-Path: 
X-Original-To: jmap@ietf.org
Delivered-To: jmap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 248F63A081D; Wed, 10 Jun 2020 05:56:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: brong@fastmailteam.com, barryleiba@computer.org, jmap@ietf.org, jmap-chairs@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159179381205.12417.2692855055303038483@ietfa.amsl.com>
Date: Wed, 10 Jun 2020 05:56:52 -0700
Archived-At: 
Subject: [Jmap] jmap - Update to a Meeting Session Request for IETF 108
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, 10 Jun 2020 12:56:52 -0000

An update to a meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group.


---------------------------------------------------------
Working Group Name: JSON Mail Access Protocol
Area Name: Applications and Real-Time Area
Session Requester: Bron Gondwana


Number of Sessions: 1
Length of Session(s):  100 Minutes
Number of Attendees: 15
Conflicts to Avoid: 
 Chair Conflict: calext
 Technology Overlap: uta httpbis txauth






People who must be present:
  Barry Leiba
  Alexey Melnikov
  Jim Fenton
  Neil Jenkins
  Bron Gondwana

Resources Requested:

Special Requests:
  Not at the very end of the day please, that's very late for our Australians.

We plan to use this session as a combined session with EXTRA depending how much work comes up at our interim meetings.
---------------------------------------------------------



From nobody Wed Jun 10 05:58:27 2020
Return-Path: 
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900893A084A for ; Wed, 10 Jun 2020 05:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=k4A4pKNh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uYFtn365
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 LE5wRB-YUnz7 for ; Wed, 10 Jun 2020 05:58:18 -0700 (PDT)
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 47DFC3A082A for ; Wed, 10 Jun 2020 05:58:18 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A68DD5C0132 for ; Wed, 10 Jun 2020 08:58:17 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 10 Jun 2020 08:58:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=H5b9BWt na5QynF3q4vmEnyyLujjmL4HBjaNK4Xcx7DM=; b=k4A4pKNhOdgO//YEh255c1g hSu7TMT0UOBaJ7TJWL+R57T79HnWeBozuIVw4gL/5Fb8GwsGe5Mw4cAEQj3KiMux h9ba2LcOFU+aqu069Jgj/eP5tsnMs39mXcRUGCS+2Hib/mzyMk2pe+DDmsQxcPaE M9gNL2PrLLasWETyZq+CnAu9whtLAtqLONUICDzYxz3tRc+xSUACWn4lH8K61ccQ ChoZXWFUiKTjJLogBAu5iUkg/75cgZtjIsFCZRPLR0XUqSPu+3PjeBB09BBTbwWK MXZm2+m+xsqFzK8L6tA+V55stviqbGJKn7KZF4eQpbJwPmscWaQ1mmoIOeF7cYw= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=H5b9BW tna5QynF3q4vmEnyyLujjmL4HBjaNK4Xcx7DM=; b=uYFtn365UQ5Kp0hXAib1PM FQTEdJT+Uhm0szbZxhtQsIimGH55TodEPTCQkv6Hkdsp6dCm4ld1+HhBRG7SePa0 vnk0DwOJbymV9idKwULdTMFQqdc8OTb4n2YewKhBAzE9CEpOVcuqRbtYgApVfDxj nEMDDodhmWoknO4dg1TyyTeK4GDsWCJY8/dWqeA39sCtL24d++c37NdeupsHwNoz 3vjCD9PgUg24Rn/EZCawS34Vdwrz0R+HYfHcW1x9++U9aZ34rWavxEbRH+AV0mp2 CYA6OZ7lJGXNqPcm+Ylbx0R6YkWQX/YgSgxWncCyUefwKYXVQDkpPrRhsNjWUILg ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehiedgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevgfeikedule duueevvdegtdeiffduhfeiffegtdduteffieetffduhfduveeuvdenucffohhmrghinhep lhhinhgrghhorhgrrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggr mhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6DC80180091; Wed, 10 Jun 2020 08:58:17 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990
Mime-Version: 1.0
Message-Id: <4b8a93a9-58b6-4d66-bb9e-1cdbbb5dd765@dogfood.fastmail.com>
In-Reply-To: 
References:        <7e3a193f-6515-4d32-85a0-88bf624ba97c@www.fastmail.com> <050acaf4-05fd-448e-ad64-8313c14f6d23@dogfood.fastmail.com> 
Date: Wed, 10 Jun 2020 22:57:56 +1000
From: "Bron Gondwana" 
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=a0521b3727264668aa6f3e4725d59e4e
Archived-At: 
Subject: Re: [Jmap] draft-ietf-jmap-mdn-06
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2020 12:58:25 -0000

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

Great thanks! Hopefully you can attend the meeting next week too.

Cheers,

Bron.

On Wed, Jun 10, 2020, at 22:49, Raphael OUAZANA wrote:
> Hi Bron,

> No problem, I well received your previous answer, I was just very busy=
.

> I will try to take some time to dig into your remarks soon.

> Regards,

> Rapha=C3=ABl.

> Le 10 juin 2020 14:45, de brong@fastmailteam.com
>> Oops, I realise I didn't also send this to the list when I replied be=
fore and may have got the wrong address.
>>=20
>> I found some issues when putting together the shepherding doc and doi=
ng a really thorough readthrough of the spec and also looking at our imp=
lementation.
>>=20
>> It would be good to be prepared to talk about these things at the int=
erim meeting next week.
>>=20
>> Cheers,
>>=20
>> Bron.
>>=20
>> On Wed, May 20, 2020, at 16:46, Bron Gondwana wrote:
>>> My apologies for the delay. I realised our implementation is incompl=
ete, so I sat down with Neil (virtually!) and did a full readthrough. Wh=
at do you know, we found more stuff to query. Sorry about that.
>>>=20
>>> *Abstract:*
>>>=20
>>> This may be a little too short - it doesn't explain what JMAP is or =
why it would be of interest. Possibly also something that the editors wi=
ll pick up on, but it would be good to make it a little more "this is wh=
at JMAP is, and this is why having MDN support in JMAP is a good idea".
>>>=20
>>> *1.3 Capabilities Object*
>>>=20
>>> I would move both MDN/send and MDN/parse as being only present if ur=
n:ietf:params:jmap:mdn is present in the accountCapabilities. Given that=
 MDN/parse works on a blobId, and blobIds are per account, it makes sens=
e that both of them require an account.
>>>=20
>>> *2. MDN: forEmailId*
>>>=20
>>> I would reverse the expression change from:
>>>=20
>>> This argument can only be null when the MDN object
      is a server response for the "MDN/parse" method.
>>>=20
>>> And instead say "This property MUST NOT be null for MDN/send, but ma=
y be null in the response from MDN/parse". That way we're not making sta=
tements about potential future extensions.
>>>=20
>>> *2. MDN: finalRecipient*
>>>=20
>>> We discussed that wildcard identities are possible in JMAP, which co=
uld make calculating finalRecipient more difficult. I would do two thing=
s here:
>>>=20
>>> 1) make finalRecipient optional on MDN/send - if set, it overrides t=
he value that would be calculated from the Identity.
>>>=20
>>> 2) add to Security Considerations that the server SHOULD validate th=
at the user is permitted to use the finalRecipient value and return a fo=
rbiddenFrom error if not.
>>>=20
>>> *2. MDN: Disposition Object*
>>>=20
>>> RFC8098 defines the strings as case insensitive. JSON values don't h=
ave to be case sensitive, but it would be much more like the rest of JMA=
P if you defined these values to be only lowercase via JMAP, e.g.
>>>=20
>>>    o  sendingMode: "String" This MUST be one of the following string=
s:
      "mdn-sent-manually" / "mdn-sent-automatically"
>>>=20
>>> And also add some text which says that these are defined case insens=
itive in 8098 but are case sensitive in this RFC and MUST be converted t=
o lowercase by /parse.
>>>=20
>>> If you disagree and think they should match what's in the raw file, =
then document needs to specify that these particular values are case ins=
ensitive.
>>>=20
>>> *2.1 MDN Send***
>>>=20
>>> You refer an "MDNError" but don't actually define it. From the examp=
les it's clear that this is a SetError. I think it would be best to chan=
ge that to:
>>>=20
>>> o  notSent: "Id[SetError]|null"
>>>=20
>>> Having done so, you can then enumerate the expected error types and =
reasons, with reference to the existing registry (apart from the new mdn=
AlreadySent error).
>>>=20
>>> *2.1 MDN Send part 2*
>>>=20
>>> This paragraph has problems:
>>>=20
>>>    If the Account Id or Identity id given cannot be found, the MDN
   sending is rejected with an "invalidProperties" error.
>>>=20
>>> One is the inconsistent spelling of accountId and identityId which I=
'm sure the editors would capture, but you may as well fix upfront.
>>>=20
>>> Secondly, the correct error here in JMAP is invalidArguments and it =
rejects the entire method call, as these are method level arguments rath=
er than properties on an individual MDN.
>>>=20
>>> *2.1 MDN Send implicit Email/set***
>>>=20
>>> It is not clear from this text whether an implicit Email/set is issu=
ed if there are no successfully sent MDNs (i.e. 'sent' is null). I am ha=
ppy with either, but it needs to be clear!
>>>=20
>>> It would be good to explain here exactly how the implicit Email/set =
would look, e.g.
>>>=20
>>> For the following method call:
>>>=20
>>>        [ "MDN/send", {
         "accountId": "ue150411c",
         "identityId": "I64588216",
         "send": {
           "k1546": {
             "forEmailId": "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"
             }
           }
         }
       }, "0" ]
>>>=20
>>> The implicit Email/set call would be equivalent to:
>>>=20
>>>        [ "Email/set", {
         "accountId": "ue150411c",
         "update": {
           "Md45b47b4877521042cec0938": {
             "keywords/$mdnsent": true
           }
         }
       }, "0" ]
>>>=20
>>> *2.2 MDN/parse***
>>>=20
>>> There reasons for "forEmailId" to be null could be expanded to inclu=
de: "the server can't efficiently calculate the related email".
>>>=20
>>> (I guess if there's more than one email with the same "Message-Id" h=
eader but different emailId then what gets returned here is undefined - =
could be any one of the emails, or could be null)
>>>=20
>>> Again, the invalidProperties error should be invalidArguments.
>>>=20
>>> *3.1 Sending an MDN***
>>>=20
>>> The Email/set example is incorrect. Since the implicit request is a =
patch to "keywords/$mdnsent", a server would not be expected to echo the=
 full value of the keywords property in the result, since it didn't unil=
aterally change it. I would expect this response:
>>>=20
>>>      [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]
>>>=20
>>> Where "updated" maps the emailId from the forEmailId property to an =
empty object.
>>>=20
>>> *All examples need to either have sendingMode changed to lowercase o=
r the definition changed as above.*
>>>=20
>>> *5. Security Considerations***
>>>=20
>>> As mentioned above, we should talk about validating the finalRecipie=
nt if we allow it to be set by the client.
>>>=20
>>>=20
>>> Again, sorry about it taking so long to get back with this feedback =
- I bet you're frustrated at how slow the process is, and this time it's=
 entirely my fault. I look forward to reviewing a -10 and actually sheph=
erding this thing for real!
>>>=20
>>> Cheers,
>>>=20
>>> Bron.
>>>=20
>>> On Tue, May 5, 2020, at 22:44, Bron Gondwana wrote:
>>>> Hi Raphael - I got Ken to follow up to you on it since he wrote our=
 implementation. I see you've dealt with that in -09.
>>>>=20
>>>> I'll do the shepherd writeup this week and submit it this week.
>>>>=20
>>>> Cheers,
>>>>=20
>>>> Bron.
>>>>=20
>>>> On Wed, Apr 29, 2020, at 00:26, Raphael OUAZANA wrote:
>>>>> Hi Bron,

>>>>> Any news on this?

>>>>> Thanks,

>>>>> Rapha=C3=ABl.

>>>>> Le 20 mars 2020 09:24, de rouazana@linagora.com
>>>>>> I agree, I think I've fixed every comments with -08.

>>>>>> Thanks,

>>>>>> Rapha=C3=ABl.

>>>>>> Le 20 mars 2020 06:43, de brong@fastmailteam.com
>>>>>>> Thanks for that.=20
>>>>>>>=20
>>>>>>> With that done, I BELIEVE that we -08 resolves every issue outst=
anding. Do you agree? I'll go ahead and do the shepherd writeup if so.
>>>>>>>=20
>>>>>>> Cheers,
>>>>>>>=20
>>>>>>> Bron.
>>>>>>>=20
>>>>>>> On Thu, Mar 19, 2020, at 21:17, Raphael OUAZANA wrote:
>>>>>>>>=20

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

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

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

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

>>>>>>>>>>>=20

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

>>>>>>>>>>=20

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

>>>>>>>>>=20

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

>>>>>>>>>=20

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

>>>>>>>>>=20

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

>>>>>>>>=20

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

>>>>>>>> Regards,

>>>>>>>> Rapha=C3=ABl.

>>>>>>>>>=20

>>>>>>>> _______________________________________________
>>>>>>>> Jmap mailing list
>>>>>>>> Jmap@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/jmap
>>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>>>>>>  brong@fastmailteam.com
>>>>>>>=20
>>>>>>>=20
>>>>=20
>>>> --
>>>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>>>  brong@fastmailteam.com
>>>>=20
>>>>=20
>>>=20
>>> --
>>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>>  brong@fastmailteam.com
>>>=20
>>>=20
>>=20
>> --
>>  Bron Gondwana, CEO, Fastmail Pty Ltd
>>  brong@fastmailteam.com
>>=20
>>=20
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap
>=20

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


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


Great thanks!  Hopefully you can attend the meet=
ing next week too.

=

Cheers,

Bron.
=


On Wed, Jun 10, 2020, a=
t 22:49, Raphael OUAZANA wrote:
Hi Bron,
No problem, I well received your p=
revious answer, I was just very busy.
I will try to take some =
time to dig into your remarks soon.
Regards,
Rapha=C3=
=ABl.
Le 10 juin 2020 14:45, de brong@fastmailteam.com=

Oops, I r=
ealise I didn't also send this to the list when I replied before and may=
 have got the wrong address.
=

I found some issues when put=
ting together the shepherding doc and doing a really thorough readthroug=
h of the spec and also looking at our implementation.

It =
would be good to be prepared to talk about these things at the interim m=
eeting next week.

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

Bron.
<=
div style=3D"font-family:Arial;">
On Wed, May 20, 2020, at=
 16:46, Bron Gondwana wrote:
My apologies for the d=
elay.  I realised our implementation is incomplete, so I sat down w=
ith Neil (virtually!) and did a full readthrough.  What do you know=
, we found more stuff to query.  Sorry about that.

<=
b>Abstract:

This may be a little too short - it doesn=
't explain what JMAP is or why it would be of interest.  Possibly a=
lso something that the editors will pick up on, but it would be good to =
make it a little more "this is what JMAP is, and this is why having MDN =
support in JMAP is a good idea".

1.3 Capabilities Obje=
ct

I would move both MDN/send and MDN/parse as being o=
nly present if urn:ietf:params:jmap:mdn is present in the accountCapabil=
ities.  Given that MDN/parse works on a blobId, and blobIds are per=
 account, it makes sense that both of them require an account.
=


2. MDN: forEmailId

I would reverse the expre=
ssion change from:

=

This argument can only be null when the MDN object
      is a server response for the "MDN/parse" method.

An=
d instead say "This property MUST NOT be null for MDN/send, but may be n=
ull in the response from MDN/parse".  That way we're not making sta=
tements about potential future extensions.

2. MDN: fin=
alRecipient

We discussed that wildcard identities are=
 possible in JMAP, which could make calculating finalRecipient more diff=
icult.  I would do two things here:

1) make finalRec=
ipient optional on MDN/send - if set, it overrides the value that would =
be calculated from the Identity.

2) add to Security Consi=
derations that the server SHOULD validate that the user is permitted to =
use the finalRecipient value and return a forbiddenFrom=
 error if not.

2. MDN: Dispositio=
n Object

RFC8098 defines the strings as case insensit=
ive.  JSON values don't have to be case sensitive, but it would be =
much more like the rest of JMAP if you defined these values to be only l=
owercase via JMAP, e.g.

<=
/div>
   o  sendingMode: "String" This MUST be one of the following =
strings:
      "mdn-sent-manually" / "mdn-sent-automatically"

And also add some text which says that these are defined case insensiti=
ve in 8098 but are case sensitive in this RFC and MUST be converted to l=
owercase by /parse.
If you disagree and think they =
should match what's in the raw file, then document needs to specify that=
 these particular values are case insensitive.

2.1 MDN=
 Send

You refer an "MDNError" but don't actual=
ly define it.  From the examples it's clear that this is a SetError=
.  I think it would be best to change that to:

o  notSent: "Id[SetError]|null"
<=
/pre>

Having done so, you can then enumerate the expected error typ=
es and reasons, with reference to the existing registry (apart from the =
new mdnAlreadySent error).
2.1 MDN Send part 2
=


This paragraph has problems:

   If the Account Id or Identity id given can=
not be found, the MDN
   sending is rejected with an "invalidProperties" error.

One is the inconsistent spelling of accountId and identityId which I'm =
sure the editors would capture, but you may as well fix upfront.

Secondly, the correct error here in JMAP is invalidA=
rguments and it rejects the entire method call, as =
these are method level arguments rather than properties on an individual=
 MDN.

2.1 MDN Send implicit Email/set

It is not clear from this text whether an implicit Email/set i=
s issued if there are no successfully sent MDNs (i.e. 'sent' is null).&n=
bsp; I am happy with either, but it needs to be clear!

It=
 would be good to explain here exactly how the implicit Email/set would =
look, e.g.

For the following method call:

       [ "MDN/send", {
         "accountId": "ue150411c",
         "identityId": "I64588216",
         "send": {
           "k1546": {
             "forEmailId": "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"
             }
           }
         }
       }, "0" ]

The implicit Email/set call would be equi=
valent to:

   =
    [ "Email/set", {
         "accountId": "ue150411c",
         "update": {
           "Md45b47b4877521042cec0938": {
             "keywords/$mdnsent": true
           }
         }
       }, "0" ]

2.2 MDN/parse

There reasons for "forEmailId" to be null could be expanded=
 to include: "the server can't efficiently calculate the related email".=


(I guess if there's more than one email with the same "M=
essage-Id" header but different emailId then what gets returned here is =
undefined - could be any one of the emails, or could be null)
<=
div style=3D"font-family:Arial;">
Again, the invalidProperties error should be invalidArguments.
<=
/div>

3.1 Sending an MDN

The Email/set=
 example is incorrect.  Since the implicit request is a patch to "k=
eywords/$mdnsent", a server would not be expected to echo the full value=
 of the keywords property in the result, since it didn't unilaterally ch=
ange it.  I would expect this response:

     [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]

Where "updated" maps the emailId from the =
forEmailId property to an empty object.

All examples n=
eed to either have sendingMode changed to lowercase or the definition ch=
anged as above.

5. Security Considerations<=
/b>

As mentioned above, we should talk about validating t=
he finalRecipient if we allow it to be set by the client.


Again, sorry about it takin=
g so long to get back with this feedback - I bet you're frustrated at ho=
w slow the process is, and this time it's entirely my fault.  I loo=
k forward to reviewing a -10 and actually shepherding this thing for rea=
l!

Cheers,
Bron.

On Tue, May 5, 2020, at 22:44, Bron Gon=
dwana wrote:
Hi Raphael - I got Ken to follow up=
 to you on it since he wrote our implementation.  I see you've deal=
t with that in -09.

I'll do the shepherd writeup this wee=
k and submit it this week.
Cheers,

Bron.

On Wed, Apr 29,=
 2020, at 00:26, Raphael OUAZANA wrote:
Hi Bron,
Any news on this?=

Thanks,
Rapha=C3=ABl.
Le 20 mars =
2020 09:24, de rouazana@linagora.com
I ag=
ree, I think I've fixed every comments with -08.
Thanks,
Rapha=C3=ABl.
Le 20 mars 2020 06:43, de brong@fas=
tmailteam.com
Thanks for that. 

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

Cheers,
=


Bron.

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

Le 18 mars 2=
020 19:09, de murch@fastmail.com

=

On 3/18/20 1:42 PM, Raphae=
l OUAZANA
      wrote:
Hello,
Le =
6 mars 2020 20:35, de murch@fastmail.com 
=


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


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


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

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

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

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


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

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


--=

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



--
  Bron Gondwana, CEO, Fastmail Pty Ltd
=

  brong@fastmailteam.com

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

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



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


=

_______________________________________________<=
br>
Jmap mailing list


=

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



--a0521b3727264668aa6f3e4725d59e4e--


From nobody Wed Jun 10 06:04:13 2020
Return-Path: 
X-Original-To: jmap@ietf.org
Delivered-To: jmap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 511963A0A06; Wed, 10 Jun 2020 06:04:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: barryleiba@computer.org, jmap@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159179424730.11101.6742890445474367188@ietfa.amsl.com>
Date: Wed, 10 Jun 2020 06:04:07 -0700
Archived-At: 
Subject: [Jmap] jmap - Update to a Meeting Session Request for IETF 108
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, 10 Jun 2020 13:04:12 -0000

An update to a meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group.


---------------------------------------------------------
Working Group Name: JSON Mail Access Protocol
Area Name: Applications and Real-Time Area
Session Requester: Bron Gondwana


Number of Sessions: 1
Length of Session(s):  100 Minutes
Number of Attendees: 15
Conflicts to Avoid: 
 Chair Conflict: calext
 Technology Overlap: uta httpbis txauth






People who must be present:
  Barry Leiba
  Alexey Melnikov
  Jiankang Yao
  Jim Fenton
  Neil Jenkins
  Bron Gondwana

Resources Requested:

Special Requests:
  Not at the very end of the day please, that's very late for our Australians.

We plan to use this session as a combined session with EXTRA depending how much work comes up at our interim meetings.
---------------------------------------------------------



From nobody Wed Jun 10 09:59:00 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 A2F2D3A0BAE for ; Wed, 10 Jun 2020 09:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=linagora.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73nOIq3Tvnvf for ; Wed, 10 Jun 2020 09:58:57 -0700 (PDT)
Received: from outgoing.linagora.com (outgoing.linagora.com [51.75.198.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3263A0B72 for ; Wed, 10 Jun 2020 09:58:56 -0700 (PDT)
Received: from linagora.com (unknown [10.233.69.48]) by outgoing.linagora.com (Postfix) with ESMTP id 6BAF33B; Wed, 10 Jun 2020 16:58:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linagora.com; s=s20181122; t=1591808335; bh=F+3FpaG7Mu2bU3TDoptFSBfGUqIEXAeMoNlo92p2ooU=; h=From:Reply-To:To:Subject:Date:References:From; b=JYuGfvkS0eSx5k3nJO2PrJcoM5Vj72YZyimpgBRC/XtwMmnEWhHYPLtwloF0pL27H rJdQtXc6IaELZvTEMcQ0JZv8PSusaldNl1CYUoyzDiCicjIsOG10eWjPG2FEEG8Ent mpQalGS9rsAmq390vH9MDF0tvLQThO78cuYXYymQ2NPwOWLWw1gFeisHj8eP8czSls 5SBZCjLmiMJyZdTrts2sqbG8vQc/gEd2Qv04/lxW5VfohGOPGsm2mMJgmRMZZnrb+p LM2bplvzYj8ffw+tYW0tcWszEGvJ65Jt/2dnvmw7JmtPkP22p/0qewyOkvWUh236aZ 3GBJicvk4DCCQ==
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Raphael OUAZANA 
Sender: Raphael OUAZANA 
Reply-To: rouazana@linagora.com
To: "jmap@ietf.org" , Raphael OUAZANA , Bron Gondwana 
Message-ID: 
Date: Wed, 10 Jun 2020 16:58:50 +0000
References:        <7e3a193f-6515-4d32-85a0-88bf624ba97c@www.fastmail.com> <050acaf4-05fd-448e-ad64-8313c14f6d23@dogfood.fastmail.com>
Archived-At: 
Subject: Re: [Jmap] draft-ietf-jmap-mdn-06
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2020 16:58:59 -0000


One point in particular is not clear to me:
Le 10 juin 2020 14:45, de brong@fastmailteam.com
2.1 MDN Send

You refer an "MDNError" but don't actually define it.  From the examples it's clear that this is a SetError..  I think it would be best to change that to:

o  notSent: "Id[SetError]|null"

Having done so, you can then enumerate the expected error types and reasons, with reference to the existing registry (apart from the new mdnAlreadySent error).


Can I use this definition even if it's not only a SetError, but an union of SetError and mdnAlreadySent?
Regards,
Raphaël.




From nobody Wed Jun 10 14:53:28 2020
Return-Path: 
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C463A1554 for ; Wed, 10 Jun 2020 14:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ifM73vCe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nlPBsNdy
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 FNkGtl-H0Beq for ; Wed, 10 Jun 2020 14:53:24 -0700 (PDT)
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 9C10A3A1553 for ; Wed, 10 Jun 2020 14:53:24 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id F2B6D41F for ; Wed, 10 Jun 2020 17:53:23 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 10 Jun 2020 17:53:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=qakHQBV 9lbDa5Ru+7Wr+AECeA1h5jPz6+nVK+IH6kC8=; b=ifM73vCe2hhq1myAL0Uir40 2w59SC5T0YWdC5dHOIKb2FmSmiIKtCUjkQ93VP5Qs2GLzSEVjP4MeLTFCu7uKeqn BP/ATDsEvQE/IP71C3rqQPZ0Jjy9ouUkyH9NyDDR8PtTcl58/RqlDtp9wRRgw5sd a5M2lksV8zlXuIHbXBchWC3Ck4e4icj9MD+OMJihEk3lJ/pv1j/gdeXyI/m0zsC4 hNUQodmTUknbJ1xYt6f/sTXhYHkl/+i5IDQzecWLOnGbxIdcwsvVs+vQptKEZ/nG dsAPB820p1ONc7QFKl5m3n6Fgl51m6kKvI+GH5fmfiW8ZEufzK5OP3u9ZZd1b1Q= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=qakHQB V9lbDa5Ru+7Wr+AECeA1h5jPz6+nVK+IH6kC8=; b=nlPBsNdyG5gdPCwBMD3zHi 2S/U/GyG7SzlfAMLQwpoFM4HskA2HyhPkfpCfjEHcLQ7yF+gwTdOS/e8w4LJbDrS AlOfwnNAcBpe6shAfrzOB+vQ0xjNFbrf4cdoTXxOg9Cg3FIWXMAkBTbHhIXX/24h O+sHHhTzZ8QyQRlaEz5VkWA3nBxNCAsU+l9ujSHdwBncNYikXkALC+OhWPULJ5Cl HXbg0sZvKHD1UERuNbJCHDfp8fFkfZObks1VaDtPky18lu6djboBwSjtNIBDIagT 3bWaZyB8JKUXR4IcVm7E2ciRpPKJHzwviTCS1gTK2HV79FYE4yk5QsV7WY9oioKw ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehjedgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeejhfeukeevje efledukeevveeffeeggfdvgeevvdekteeguefgfeefjedugedvjeenucffohhmrghinhep ihgrnhgrrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 303EF180091; Wed, 10 Jun 2020 17:53:23 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990
Mime-Version: 1.0
Message-Id: <79e5fcf5-f547-4dac-a7f1-d406f3b5b05c@dogfood.fastmail.com>
In-Reply-To: 
References:        <7e3a193f-6515-4d32-85a0-88bf624ba97c@www.fastmail.com> <050acaf4-05fd-448e-ad64-8313c14f6d23@dogfood.fastmail.com> 
Date: Thu, 11 Jun 2020 07:53:02 +1000
From: "Bron Gondwana" 
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=b30ea55b27314877870bbf00be4ef2d6
Archived-At: 
Subject: Re: [Jmap] draft-ietf-jmap-mdn-06
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Jun 2020 21:53:26 -0000

--b30ea55b27314877870bbf00be4ef2d6
Content-Type: text/plain

On Thu, Jun 11, 2020, at 02:58, Raphael OUAZANA wrote:
> One point in particular is not clear to me:

> Le 10 juin 2020 14:45, de brong@fastmailteam.com
>> *2.1 MDN Send*
>>> 
>>> You refer an "MDNError" but don't actually define it. From the examples it's clear that this is a SetError.. I think it would be best to change that to:
>>> 
>>> o  notSent: "Id[SetError]|null"
>>> 
>>> Having done so, you can then enumerate the expected error types and reasons, with reference to the existing registry (apart from the new mdnAlreadySent error).
>>> 
> 

> Can I use this definition even if it's not only a SetError, but an union of SetError and mdnAlreadySent?


It was clear to me reading that mdnAlreadySent is a type for SetError.

>From RFC8620:

A *SetError* object has the following properties:

   o  type: "String"

      The type of error.

   o  description: "String|null"

      A description of the error to help with debugging that includes an
      explanation of what the problem was.  This is a non-localised
      string and is not intended to be shown directly to end users.

So "mdnAlreadySent" would be added to the registry at https://www.iana.org/assignments/jmap/jmap.xhtml and listed as a possible error type for this method.

Bron.

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


--b30ea55b27314877870bbf00be4ef2d6
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


On Thu, Jun 11, 2020, at 02:58, Raphael OUAZANA wrote=
:
One point i=
n particular is not clear to me:
Le 10 juin 2020 14:45=
, de brong@fastmailteam.com
2.1 MDN =
Send

You refer an "MDNError" but don't actually define it.  From the e=
xamples it's clear that this is a SetError..  I think it would be b=
est to change that to:

o  notSent: "Id[SetError]|null"

Having done so, =
you can then enumerate the expected error types and reasons, with refere=
nce to the existing registry (apart from the new mdnAlreadySent error).<=
br>


Can I us=
e this definition even if it's not only a SetError, but an union of SetE=
rror and mdnAlreadySent?

It was clear to me re=
ading that mdnAlreadySent is a type for SetError.

From RF=
C8620:

A *SetError* object has the following properties:

   o  type: "String"

      The type of error.

   o  description: "String|null"

      A description of the error to help with debugging that includes an=

      explanation of what the problem was.  This is a non-localised
      string and is not intended to be shown directly to end users.
<=
/pre>

So "mdnAlreadySent" would be added to the registry at https://www.iana.o=
rg/assignments/jmap/jmap.xhtml and listed as a possible error type f=
or this method.

Bron.

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

=


--b30ea55b27314877870bbf00be4ef2d6--


From nobody Thu Jun 11 03:39:24 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 46B143A1810 for ; Thu, 11 Jun 2020 03:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level: 
X-Spam-Status: No, score=-2.095 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_NONE=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=cketti.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8srgD9rlQZ0K for ; Thu, 11 Jun 2020 03:39:13 -0700 (PDT)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.161]) (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 C5DD93A17F1 for ; Thu, 11 Jun 2020 03:39:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591871949; s=strato-dkim-0002; d=cketti.de; h=In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=r4B4ZAe7nSSDZDpHEtA41pGP1DKtVkWyuAR3nkw8ylg=; b=gEU+DjmTf4cQjWX5RI2j0LpG3IqvV7UCwztd+ef+ySDQFBpxyRlYw0SZblV5jOj3Su ARuu7YSBHPoHWBpK+RLc6WMgunC48HyFaGa3Klv9yaXannj7ERoACp1zwDzCZK2qTtmv VSM8rsfUOZA26f22kLeaZLS/B+ughpJigTXcT5JP3o0zqQiyvUyEZuBTK0cmSCC2KW/h jqd/ch4QbQhyG1eqHsQUCIQcEKY9lIEL2jNeTtAi9cNKVyNb4wPARC2udfV8FDBaV0rf T5XzCiQaX7fD/Os1mWAfBJSfSDRrlPwIMZgA+ZDHQH3L7t0tJMaGHAxjwdur3ENsO/eB 7wZA==
X-RZG-AUTH: ":L2ckdkutb+sebmQwUUWXIIIYdHNZM+Bv5gC+3oItIZntReBfOoHCAsuiGZE="
X-RZG-CLASS-ID: mo00
Received: from [192.168.5.133] by smtp.strato.de (RZmta 46.10.1 DYNA|AUTH) with ESMTPSA id N07a15w5BAd80TT (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Thu, 11 Jun 2020 12:39:08 +0200 (CEST)
To: jmap@ietf.org
References:        <7e3a193f-6515-4d32-85a0-88bf624ba97c@www.fastmail.com> <050acaf4-05fd-448e-ad64-8313c14f6d23@dogfood.fastmail.com> <6d2919ca-9026-484e-885c-14e8b2bca05e@dogfood.fastmail.com>
From: cketti 
Message-ID: <9424bb4b-ea8d-13be-ef72-75b9ce003339@cketti.de>
Date: Thu, 11 Jun 2020 12:39:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <6d2919ca-9026-484e-885c-14e8b2bca05e@dogfood.fastmail.com>
Content-Type: multipart/alternative; boundary="------------926405B5585FB092FAA4AB38"
Content-Language: en-US
Archived-At: 
Subject: Re: [Jmap] draft-ietf-jmap-mdn-06
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2020 10:39:23 -0000

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

On 10.06.20 14:45, Bron Gondwana wrote:
>> *3.1 Sending an MDN*
>>
>> The Email/set example is incorrect.  Since the implicit request is a
>> patch to "keywords/$mdnsent", a server would not be expected to echo
>> the full value of the keywords property in the result, since it
>> didn't unilaterally change it.  I would expect this response:
>>
>>      [ "Email/set", {
>>        "accountId": "ue150411c",
>>        "oldState": "23",
>>        "newState": "42",
>>        "updated": {
>>          "Md45b47b4877521042cec0938": {}
>>        }
>>      }, "0" ]]
>>
>> Where "updated" maps the emailId from the forEmailId property to an
>> empty object.
>>

This would be annoying for clients. They'd have to hard-code what the
implicit Email/set looks like.

It also makes it harder to change what the implicit Email/set call looks
like in a future version of the spec. If an additional property was to
be modified it would have to be included in the response to be backward
compatible to this spec. Then you'd have to come up with a new way to
specify an implicit request ("include these changed properties in the
response, but not those").

I do realize that including the modified keyword in the response makes
things more complicated for the server. But to me it feels like the
better alternative.


--------------926405B5585FB092FAA4AB38
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 10.06.20 14:45, Bron Gondwana wrote:

    

    

      
      
      
      

        
3.1 Sending an MDN

        

        


        

        
The Email/set example is
          incorrect.  Since the implicit request is a patch to
          "keywords/$mdnsent", a server would not be expected to echo
          the full value of the keywords property in the result, since
          it didn't unilaterally change it.  I would expect this
          response:

        

        


        

        
     [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]


        


        

        
Where "updated" maps the emailId
          from the forEmailId property to an empty object.

        

        


        

      

    

    


    

    
This would be annoying for clients. They'd have to hard-code what
      the implicit Email/set looks like.

    

    
It also makes it harder to change what the implicit Email/set
      call looks like in a future version of the spec. If an additional
      property was to be modified it would have to be included in the
      response to be backward compatible to this spec. Then you'd have
      to come up with a new way to specify an implicit request ("include
      these changed properties in the response, but not those").

    
I do realize that including the modified keyword in the response
      makes things more complicated for the server. But to me it feels
      like the better alternative.

    

  


--------------926405B5585FB092FAA4AB38--


From nobody Thu Jun 11 05:09:51 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 681753A077A for ; Thu, 11 Jun 2020 05:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=pkPgK+u8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YAXUkRkf
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 vpgHhnfgb38t for ; Thu, 11 Jun 2020 05:09:47 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01603A0766 for ; Thu, 11 Jun 2020 05:09:47 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C13CE5C0185 for ; Thu, 11 Jun 2020 08:09:46 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 11 Jun 2020 08:09:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=tV+wZfQ v6Rkb6HZC1+lr8L2RulwMB9KURofFNZWFn1E=; b=pkPgK+u8lfmpucmjqTWjXj5 lnrwAf4x2PZ0ord0puh2mHBI3XetSgU8TgzgM8UnE3z01x2g3vGhSXcunuFtkXty Fyp/7VXEhioOA80VsDleE51FK5MQyKk1ra+l+iqskzycV6o2JmQecNBk5pCGaG/O psZvtyND5+auKdcpFIQZjLPEmq5j8jQLw+SgMPzHsqHwdq1jgNoKj83ZPT6pePkM 3mp9cqE0aSZ7SPH3K1VhpXj6RBHxawhraKkcom9FwI2zJlb7xLnY+A0xhiWlkfaU oVl4wItmIupcEZSjKPFLsKut4P1XS775Xe0hppD+bDUNY9vbOkDEZyj9CyNjy9A= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=tV+wZf Qv6Rkb6HZC1+lr8L2RulwMB9KURofFNZWFn1E=; b=YAXUkRkf4HhRgoDJC3RoyE ocIYgyyTox6GpiSX4DB9gCHG2ttoEFTCADuiClbaFoOljAIzGKVb8/TP7Xx2BZbQ KC6IcjJ/ZF8f6m/UZiletgIJUoOg8elMTgsloPvjZCNGZUa/pkjDxLC10spxt5zM ylF1kp4N0FU81lrqwRgZloJwlhtKdUk62paHozzcTxGSP/CdNgmQZ9anxptubbvI Qtseca7Q5UUlNotLUfzfO45P12eX5CE+05WFn04PGe/jlFyJnYQN/wW4zLcSCbze CKgjBWEir+iFgzCkiPoIVxTQG6IrHVG/xR8eIZwrAmteXg4RGXL8V1Cb1EsPlPJA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehledgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhudfhveehve dvleehvedtvdehkeetiefffeeluefgfeffuedviefgjeeuuefghfenucffohhmrghinhep lhhinhgrghhorhgrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4040C180091; Thu, 11 Jun 2020 08:09:46 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990
Mime-Version: 1.0
Message-Id: <670d3ff0-4aa1-4939-9a15-87e921fac080@dogfood.fastmail.com>
In-Reply-To: <9424bb4b-ea8d-13be-ef72-75b9ce003339@cketti.de>
References:        <7e3a193f-6515-4d32-85a0-88bf624ba97c@www.fastmail.com> <050acaf4-05fd-448e-ad64-8313c14f6d23@dogfood.fastmail.com> <6d2919ca-9026-484e-885c-14e8b2bca05e@dogfood.fastmail.com> <9424bb4b-ea8d-13be-ef72-75b9ce003339@cketti.de>
Date: Thu, 11 Jun 2020 22:09:26 +1000
From: "Bron Gondwana" 
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=c62eb0a90c6342209c29b9000c5fad04
Archived-At: 
Subject: Re: [Jmap] draft-ietf-jmap-mdn-06
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2020 12:09:49 -0000

--c62eb0a90c6342209c29b9000c5fad04
Content-Type: text/plain

On Thu, Jun 11, 2020, at 20:39, cketti wrote:
> On 10.06.20 14:45, Bron Gondwana wrote:
>>> *3.1 Sending an MDN*
>>> 
>>> The Email/set example is incorrect. Since the implicit request is a patch to "keywords/$mdnsent", a server would not be expected to echo the full value of the keywords property in the result, since it didn't unilaterally change it. I would expect this response:
>>> 
>>>      [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]
>>> 
>>> 
>>> Where "updated" maps the emailId from the forEmailId property to an empty object.
>>> 
> 

> This would be annoying for clients. They'd have to hard-code what the implicit Email/set looks like.

> It also makes it harder to change what the implicit Email/set call looks like in a future version of the spec. If an additional property was to be modified it would have to be included in the response to be backward compatible to this spec. Then you'd have to come up with a new way to specify an implicit request ("include these changed properties in the response, but not those").

> I do realize that including the modified keyword in the response makes things more complicated for the server. But to me it feels like the better alternative.


The argument of "if an additional property was to be modified" doesn't apply in JMAP land, because that additional property would come with an additional "using" parameter, and the client would have to set that - in which case it would know what the server would do. There's no backwards/forwards compatibility issue because the client explicitly requests which specs are to be used, and the server explicitly lists which ones it supports.

HOWEVER...

You raise pretty much the same objection that I have to implicit sets in the first place. They shouldn't exist. So what would it look like to have an EXPLICIT set?

       [[ "MDN/send", {
         "accountId": "ue150411c",
         "identityId": "I64588216",
         "send": {
           "k1546": {
             "forEmailId": "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"
             }
           }
         },
*         "onSuccessUpdateEmail": {
           "#k1546": {
             "keywords/$mdnsent": true**
**           }**
**         }*
       }, "0" ]]

This would match the semantics of EmailSubmission/set, which this is kind of a special case of in some ways, and would then mean that there's never any need to worry about the automatic tasks that the server takes, because it never does. Yes, you need to hard-code that logic into clients, but it strongly matches with my hard earned belief that automatic magical behaviour on the server is bad - the client should explicitly ask for side-effects.

I would also put a SHOULD or even MUST in the spec that the server reject an MDN/send which doesn't result in setting the keyword $mdnsent on the server in that case.

But - I'm happy with either way - but I'm not happy with requiring the Email/set response to act differently from every other triggered Email/set response, because as a server author this makes things really messy.

Bron.

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


--c62eb0a90c6342209c29b9000c5fad04
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


On Thu, Jun 11, 2020, at 20:39, cketti wrote:
On 10.06.20 14:45, Bron Gondwana wrote:
3.1 Sending an MDN

The Ema=
il/set example is
          incorrect.  Since the implicit request is a patch to
          "keywords/$mdnsent", a server would not be expected to echo
          the full value of the keywords property in the result, since
          it didn't unilaterally change it.  I would expect this
          response:

     [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]


Where "updated" maps the emailId
          from the forEmailId property to an empty object.

This would be annoying for clients. They'd have to hard-code wha=
t
      the implicit Email/set looks like.
It also makes it hard=
er to change what the implicit Email/set
      call looks like in a future version of the spec. If an additional
      property was to be modified it would have to be included in the
      response to be backward compatible to this spec. Then you'd have
      to come up with a new way to specify an implicit request ("include=

      these changed properties in the response, but not those").
=

I do realize that including the modified keyword in the response
      makes things more complicated for the server. But to me it feels
      like the better alternative.

The argumen=
t of "if an additional property was to be modified" doesn't apply in JMA=
P land, because that additional property would come with an additional "=
using" parameter, and the client would have to set that - in which case =
it would know what the server would do.  There's no backwards/forwa=
rds compatibility issue because the client explicitly requests which spe=
cs are to be used, and the server explicitly lists which ones it support=
s.

HOWEVER...
=

You raise pretty much the sa=
me objection that I have to implicit sets in the first place.  They=
 shouldn't exist.  So what would it look like to have an EXPLICIT s=
et?

       [[ "MDN/send", {
         "accountId": "ue150411c",
         "identityId": "I64588216",
         "send": {
           "k1546": {
             "forEmailId": "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"
             }
           }
         },
         "onSuccessUpdateEmail": {
           "#k1546": {
             "keywords/$mdnsent": true
           }
=
         }
       }, "0" ]]

This would match the semantics of EmailSubmission/set, which this=
 is kind of a special case of in some ways, and would then mean that the=
re's never any need to worry about the automatic tasks that the server t=
akes, because it never does.  Yes, you need to hard-code that logic=
 into clients, but it strongly matches with my hard earned belief that a=
utomatic magical behaviour on the server is bad - the client should expl=
icitly ask for side-effects.
=

I would also put a SHOULD or=
 even MUST in the spec that the server reject an MDN/send which doesn't =
result in setting the keyword $mdnsent on the server in that case.

But - I'm happy with either way - but I'm not happy with requi=
ring the Email/set response to act differently from every other triggere=
d Email/set response, because as a server author this makes things reall=
y messy.

Bron.

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




--c62eb0a90c6342209c29b9000c5fad04--


From nobody Thu Jun 11 06:04: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 08DAD3A081C for ; Thu, 11 Jun 2020 06:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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=cketti.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2mWV_FOyULz for ; Thu, 11 Jun 2020 06:04:27 -0700 (PDT)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.218]) (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 9917A3A0836 for ; Thu, 11 Jun 2020 06:04:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591880665; s=strato-dkim-0002; d=cketti.de; h=In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=yMGSLY4tbvlku1jwL0m0WiBpnpVZ9QQtmjzwJUx4YaY=; b=nUZZ7f1dCXugCvnWg5q6CFxxEiByMnazqyIYWMPoC9iHX1q8J9eGD49AQ8jiyyDzgS FsOl42NAQ/e9JK+B6Hky3OooqZC+wr5dFD8LF86yrDihgJ17UcBusJ/rrMBywM6Qp+bk wKQDmy92pNNbq00nphVgyNuIa+HouOTmgy9I2xOkOslR2+AREgRjbqUEVSmdDDx6Yhgx iUm5dwZUlei5AJ8OhJuIhh2iL6Ot6T9KqOVzSrNGpbCZrdtw+Uelh0EWYyKdktEfv9fn RRkMttExKeVIxbm5vzACgBb3DqmZ7kve3DNPoJ2ROq4f4yMn5S3dam8z0KxquWuwrK3d 1Sjg==
X-RZG-AUTH: ":L2ckdkutb+sebmQwUUWXIIIYdHNZM+Bv5gC+3oItIZntReBfOoHCAsuiGZE="
X-RZG-CLASS-ID: mo00
Received: from [192.168.5.133] by smtp.strato.de (RZmta 46.10.2 DYNA|AUTH) with ESMTPSA id 90b21bw5BD4P0Fw (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for ; Thu, 11 Jun 2020 15:04:25 +0200 (CEST)
To: jmap@ietf.org
References:        <7e3a193f-6515-4d32-85a0-88bf624ba97c@www.fastmail.com> <050acaf4-05fd-448e-ad64-8313c14f6d23@dogfood.fastmail.com> <6d2919ca-9026-484e-885c-14e8b2bca05e@dogfood.fastmail.com> <9424bb4b-ea8d-13be-ef72-75b9ce003339@cketti.de> <670d3ff0-4aa1-4939-9a15-87e921fac080@dogfood.fastmail.com>
From: cketti 
Message-ID: <27d50324-7bf4-c6d3-f541-23d204bb3237@cketti.de>
Date: Thu, 11 Jun 2020 15:04:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <670d3ff0-4aa1-4939-9a15-87e921fac080@dogfood.fastmail.com>
Content-Type: multipart/alternative; boundary="------------DB147BFC3245885E2B51DC86"
Content-Language: en-US
Archived-At: 
Subject: Re: [Jmap] draft-ietf-jmap-mdn-06
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Jun 2020 13:04:30 -0000

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

On 11.06.20 14:09, Bron Gondwana wrote:
> You raise pretty much the same objection that I have to implicit sets
> in the first place.  They shouldn't exist.  So what would it look like
> to have an EXPLICIT set?
>
>        [[ "MDN/send", {
>          "accountId": "ue150411c",
>          "identityId": "I64588216",
>          "send": {
>            "k1546": {
>              "forEmailId": "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"
>              }
>            }
>          },
> *"onSuccessUpdateEmail": { "#k1546": { "keywords/$mdnsent": true***
> *}***
> *}*
>        }, "0" ]]
>
> This would match the semantics of EmailSubmission/set, which this is
> kind of a special case of in some ways, and would then mean that
> there's never any need to worry about the automatic tasks that the
> server takes, because it never does.  Yes, you need to hard-code that
> logic into clients, but it strongly matches with my hard earned belief
> that automatic magical behaviour on the server is bad - the client
> should explicitly ask for side-effects.
>
> I would also put a SHOULD or even MUST in the spec that the server
> reject an MDN/send which doesn't result in setting the keyword
> $mdnsent on the server in that case.

I like that. I agree that being explicit is better.


--------------DB147BFC3245885E2B51DC86
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
On 11.06.20 14:09, Bron Gondwana wrote:

    

    

      
      
      
      
You raise pretty much the same
        objection that I have to implicit sets in the first place.  They
        shouldn't exist.  So what would it look like to have an EXPLICIT
        set?

      

      


      

      
       [[ "MDN/send", {
         "accountId": "ue150411c",
         "identityId": "I64588216",
         "send": {
           "k1546": {
             "forEmailId": "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"
             }
           }
         },
         "onSuccessUpdateEmail": {
           "#k1546": {
             "keywords/$mdnsent": true


      
           }


      
         }


      
       }, "0" ]]


      


      

      
This would match the semantics of
        EmailSubmission/set, which this is kind of a special case of in
        some ways, and would then mean that there's never any need to
        worry about the automatic tasks that the server takes, because
        it never does.  Yes, you need to hard-code that logic into
        clients, but it strongly matches with my hard earned belief that
        automatic magical behaviour on the server is bad - the client
        should explicitly ask for side-effects.

      

      


      

      
I would also put a SHOULD or even
        MUST in the spec that the server reject an MDN/send which
        doesn't result in setting the keyword $mdnsent on the server in
        that case.

      

    

    
I like that. I agree that being explicit is better.

    

  


--------------DB147BFC3245885E2B51DC86--


From nobody Thu Jun 11 14:37: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 90A7A3A0A3A for ; Thu, 11 Jun 2020 14:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXOmF8V48qoO for ; Thu, 11 Jun 2020 14:37:38 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 21DE03A0A32 for ; Thu, 11 Jun 2020 14:37:37 -0700 (PDT)
Received: from steel.local ([IPv6:2601:647:4400:9fb0:f1a4:173d:8e3b:1952]) (authenticated bits=0) by v2.bluepopcorn.net (8.15.2/8.15.2/Debian-14~deb10u1) with ESMTPSA id 05BLbZR8024839 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 11 Jun 2020 14:37:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1591911457; bh=PxZ/3d8/L4efXnNwdKS0ApVTPlTL3Jp+JIfZ6xsBKes=; h=Subject:References:To:From:Date:In-Reply-To:From; b=UtENF0++Z0CCR4H2IfGHDmDUEBKyfHd+1AAiXnvOmJ3nR4PckO0JziomsKMs5snCY 1EaVUs4OUbO7IAxToQbCZiFZ5kgGs6B5CTmZ40pr+ukg8WUg/tRH3BD/c9cxBVdSGX KLL14LeyyugGZ1Pw/VBIaLWue7LCBOfQeMqsbiTc=
References: <159181529656.16063.6964178024900109434@ietfa.amsl.com>
To: jmap@ietf.org
From: Jim Fenton 
Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCXVD9ggUJDORhvgAKCRAbJaiwFdCf vgiSEACd3Nem63zL2C6daCFfRzOANkf30Q8AvaRVwhfdFxs+5vETCzbqctrtIAHeqncXjm9G uEJWxecAiHZXKoWUEFECMp3+Saznw0np+c722M4k9xI+mxqbcE0qgpYQgA8zbS/Lbds3f/bk /00jrQg4VMkumONlh+RZVwxAsnWp8efrJsNTn0QOPZavAkPEN59wfyWQ3O4pNY8i3zum8Wge 8NS4BBMyG0fmjWgUq0K2QrTD4AKBslM2IWCLECypP1AOfHKmmTACKFOnzJJ4KspUw3hdBnS1 fvudUC8u26Q3T6rHosRqxGmgW7sQWwAusgMSa/A6zxR6soEBSsMT5Tf+VHebuz1FWE4ogrvJ InvewfYSCYzOQamYYGArcBtAzU00pUzW2Or7SlwZPHHy2EfMd0zvT7mwSYLwwwcCsWc1O/CI xHGea7PBgO3TdR0Ex254yc+NTyxF3isBC/fodF9aNWF6x6SV3VKYJ3U2uqS9ga85dZz8Qeps MwlSEGRVhVVWGbSxy0GxV5Up0yX4vl0kI0c7Tt57JCOoRBpn/lTK/7IEtZK6/uiw98KCy+BM uF7HPsgXjd/AQjSsZIJgDyVY/y7niduqhW2izNEdhV77htVbKHRf2SfJQNudWOIcOhUTlddH kOSjet+MDso61JxrFV4j/8wFno7NwpPIhD//HvKAiLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJdUP9SBQkM5GOPAAoJEBslqLAV0J++vZoP/1shJ+5iImGzvGUTTDJcAX6Wha+22QP0G51Z QGZbeB0gE+gDmRwd2yw0cO3y1sPoTJliUSuZ3DFIjv8CLBgDlrkUnijBWbi5YznsAZkH0vKG ESGzinJC6y/Nzf2TZokKiOaYrTYcZx8x2wxjNO+zsihm/rvhV/YnHEYd9dlV/MjAL3xtHU/9 fNcTDtF3RchADyVCxlqrRUkFj61dHxU+U5JRftyIliLltsy2Nlr4uAsxNX+tpAH2D2HLmjwx bV2fpTnFCVImtuo6ZqNZ8SMk1Xq0fBBdo3acBw42kL/qGIKS9x3NWEy8vsmQXn0QqNBd1Q62 9ghm82mHMTRKnOXqkMgICpZ0HffPf3p7zMkEqWptgEHxE6ZHm9hJMGEf8RED9DCYh+N1uFaM 7ndQPPFKlj80sGmNF9+01mO53hrxeL/WAdGox/STpTb2BDpiyrLdT/2R0vJNEfMxBBYlw1gc g8mPEwHwZ940/qql7e41TkDGUZa2a1WegKLj8hK1pgDDBptcdIvlvuk284jOZ2/jDyaBDsMf 310OoJchJ3977odtSCArybQIwMjTx0rv6dqjsuqP89jqlrGV6izqf1n4p4FNrBSWOSRGaoWD JJVHL4YUhP44G5xDBCtp3TqatLa5F2Rgxj50EFIzOuu9Pg1tBCPP1G+0EiikVTdDkC63X4RG
X-Forwarded-Message-Id: <159181529656.16063.6964178024900109434@ietfa.amsl.com>
Message-ID: 
Date: Thu, 11 Jun 2020 14:37:29 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <159181529656.16063.6964178024900109434@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------309186290FC653643F7C0B12"
Content-Language: en-US
Archived-At: 
Subject: [Jmap] Fwd: Nomcom 2020-2021 Second Call For Volunteers
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, 11 Jun 2020 21:37:41 -0000

This is a multi-part message in MIME format.
--------------309186290FC653643F7C0B12
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I'm forwarding this at the request of the 2020-2021 NomCom chair. Note
that our responsible AD, Barry Leiba, is up for selection.

As a member of the 2019-2020 NomCom, I can personally say that serving
on NomCom is a very rewarding experience and a great way to serve IETF,
although it is a significant (but not enormous) commitment.

Feel free to contact me offlist if you have any questions about serving
on NomCom.

-Jim



-------- Forwarded Message --------
Subject: 	Nomcom 2020-2021 Second Call For Volunteers
Date: 	Wed, 10 Jun 2020 11:54:56 -0700
From: 	NomCom Chair 2020 
To: 	IETF Announcement List 
CC: 	ietf@ietf.org



This is the second sending of the call for volunteers for the 2020-2021
NomCom.

I wanted to mention a few updates from the previous email (sent 2 weeks
ago):
- I've fixed the URL at the bottom of the email to point to
https://datatracker.ietf.org/nomcom/2020/ instead of /2019/. This was a
test to see if anyone was paying attention. Apparently, some people were.=
 ;)
- The IETF 108 registration form includes a checkbox that will let you
volunteer. You can use this instead of emailing me, when you register
for IETF 108.
- I currently have 39 volunteers. Last year had 149. I need more voluntee=
rs!
-------------------------------------------------------------------------=
--------
The IETF NomCom appoints people to fill the open slots on the LLC, IETF
Trust, the IAB, and the IESG.

Ten voting members for the NomCom are selected in a verifiably random
way from a pool of volunteers. The more volunteers, the better chance we
have of choosing a random yet representative cross section of the IETF
population.

The details of the operation of the NomCom can be found in BCP 10 (RFC
8713). RFC 3797 details the selection algorithm.

Special for this year (and only this year), we also have RFC 8788
(one-off update to RFC 8713 / BCP 10) to tell us who is eligible to
volunteer:

Members of the IETF community must have attended at least three of
the last five in-person IETF meetings in order to volunteer.

The five meetings are the five most recent in-person meetings that
ended prior to the date on which the solicitation for NomCom
volunteers was submitted for distribution to the IETF community.
Because no IETF 107 in-person meeting was held, for the 2020-2021
Nominating Committee those five meetings are IETFs
102 [Montreal, Canada; July 2018],
103 [Bangkok, Thailand; November 2018],
104 [Prague, Czech Republic; March 2019],
105 [Montreal, Canada; July 2019], and 106 [Singapore; November 2019].

Keep in mind that eligibility is based on in-person attendance at the
five listed meetings. You can check your eligibility at:
https://www.ietf.org/registration/nomcom.py.

If you qualify, please volunteer. Before you decide to volunteer, please
remember that anyone appointed to this NomCom will not be considered as
a candidate for any of the positions that the 2020 - 2021 NomCom is
responsible for filling.

People commonly volunteer by ticking the box on IETF registration forms.
The IETF 106 form did not ask whether people were willing to volunteer.
IETF 107 did ask, but all those registrations were canceled. I have
asked the Secretariat if it is possible to get the list if volunteers
from canceled IETF 107 registrations. If that list is available, I will
contact all who are verified as eligible. But given the uncertainty of
this process, I would encourage people to volunteer directly (see the
bottom of this email for instructions). Thank you for volunteering!

The list of people and posts whose terms end with the March 2021 IETF
meeting, and thus the positions for which this NomCom is responsible, are=


IETF Trust:
Joel Halpern

LLC:
Maja Andjelkovic

IAB:
Jari Arkko
Jeff Tantsura
Mark Nottingham
Stephen Farrell
Wes Hardaker
Zhenbin Li

IESG:
Alissa Cooper, IETF Chair/GEN AD
Alvaro Retana, RTG AD
Barry Leiba, ART AD
Deborah Brungard, RTG AD
=C3=89ric Vyncke, INT AD
Magnus Westerlund, TSV AD
Roman Danyliw, SEC AD
Warren Kumari, OPS AD

All appointments are for 2 years. The Routing area has 3 ADs and the
General area has 1; all other areas have 2 ADs. Thus, all areas (that
have more than one AD) have at least one continuing AD.

The primary activity for this NomCom will begin in July 2020 and should
be completed in January 2021. The NomCom will have regularly scheduled
conference calls to ensure progress. There will be activities to collect
requirements from the community, review candidate questionnaires, review
feedback from community members about candidates, and talk to candidates.=


While being a NomCom member does require some time commitment it is also
a very rewarding experience.

As a member of the NomCom it is very important that you be willing and
able to attend either videoconference or in-person meetings (which may
not happen) during 14-20 November (IETF 109 - Bangkok) to conduct
interviews. Videoconference attendance will be supported whether or not
there are in-person meetings. Orientation and setting of the NomCom
schedule will be done by videoconference during the week 20-24 July
(exact time and date to be determined after NomCom membership is
finalized on July 12), the week prior to IETF 108. Being at IETF 110
(Prague) is not essential.

Please volunteer by sending me an email before 23:59 UTC June 24, 2020,
as follows:

To: nomcom-chair-2020@ietf.org
Subject: NomCom 2020-21 Volunteer

Please include the following information in the email body:

Your Full Name: // as you write it on the IETF registration form

Current Primary Affiliation:
// Typically what goes in the Company field
// in the IETF Registration Form

Emails: // All email addresses used to register for the past 5 IETF meeti=
ngs
// Preferred email address first

Telephone: // For confirmation if selected

You should expect an email response from me within 5 business days
stating whether or not you are qualified. If you don't receive this
response, please re-send your email with the tag "RESEND"" added to the
subject line.

If you are not yet sure if you would like to volunteer, please consider
that NomCom members play a very important role in shaping the leadership
of the IETF. Questions by email or voice are welcome. Volunteering for
the NomCom is a great way to contribute to the IETF!

You can find a detailed timeline on the NomCom web site at:
https://datatracker.ietf.org/nomcom/2020/

I will be publishing a more detailed target timetable, as well as
details of the randomness seeds to be used for the RFC 3797 selection
process, within the next few weeks.

Thank you!

Barbara Stark
bs7652 at att dot com
nomcom-chair-2020 at ietf dot org

--------------309186290FC653643F7C0B12
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
I'm forwarding this at the request of the 2020-2021 NomCom chair.
      Note that our responsible AD, Barry Leiba, is up for selection.

    

    
As a member of the 2019-2020 NomCom, I can personally say that
      serving on NomCom is a very rewarding experience and a great way
      to serve IETF, although it is a significant (but not enormous)
      commitment.

    

    
Feel free to contact me offlist if you have any questions about
      serving on NomCom.

    
-Jim

    

    


      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            Nomcom 2020-2021 Second Call For Volunteers
          

          

            Date: 
            Wed, 10 Jun 2020 11:54:56 -0700
          

          

            From: 
            NomCom Chair 2020 <nomcom-chair-2020@ietf.org>
          

          

            To: 
            IETF Announcement List <ietf-announce@ietf.org>
          

          

            CC: 
            ietf@ietf.org
          

        
      

      

      

      This is the second sending of the call for volunteers for the
      2020-2021 NomCom.

      

      I wanted to mention a few updates from the previous email (sent 2
      weeks ago):

      - I've fixed the URL at the bottom of the email to point to
      https://datatracker.ietf.org/nomcom/2020/ instead of /2019/. This
      was a test to see if anyone was paying attention. Apparently, some
      people were. ;)

      - The IETF 108 registration form includes a checkbox that will let
      you volunteer. You can use this instead of emailing me, when you
      register for IETF 108.

      - I currently have 39 volunteers. Last year had 149. I need more
      volunteers!

---------------------------------------------------------------------------------

      The IETF NomCom appoints people to fill the open slots on the LLC,
      IETF Trust, the IAB, and the IESG.

      

      Ten voting members for the NomCom are selected in a verifiably
      random way from a pool of volunteers. The more volunteers, the
      better chance we have of choosing a random yet representative
      cross section of the IETF population.

      

      The details of the operation of the NomCom can be found in BCP 10
      (RFC 8713). RFC 3797 details the selection algorithm.

      

      Special for this year (and only this year), we also have RFC 8788
      (one-off update to RFC 8713 / BCP 10) to tell us who is eligible
      to volunteer:

      

      Members of the IETF community must have attended at least three of

      the last five in-person IETF meetings in order to volunteer.

      

      The five meetings are the five most recent in-person meetings that

      ended prior to the date on which the solicitation for NomCom

      volunteers was submitted for distribution to the IETF community.

      Because no IETF 107 in-person meeting was held, for the 2020-2021

      Nominating Committee those five meetings are IETFs

      102 [Montreal, Canada; July 2018],

      103 [Bangkok, Thailand; November 2018],

      104 [Prague, Czech Republic; March 2019],

      105 [Montreal, Canada; July 2019], and 106 [Singapore; November
      2019].

      

      Keep in mind that eligibility is based on in-person attendance at
      the five listed meetings. You can check your eligibility at:
      https://www.ietf.org/registration/nomcom.py.

      

      If you qualify, please volunteer. Before you decide to volunteer,
      please remember that anyone appointed to this NomCom will not be
      considered as a candidate for any of the positions that the 2020 -
      2021 NomCom is responsible for filling.

      

      People commonly volunteer by ticking the box on IETF registration
      forms. The IETF 106 form did not ask whether people were willing
      to volunteer. IETF 107 did ask, but all those registrations were
      canceled. I have asked the Secretariat if it is possible to get
      the list if volunteers from canceled IETF 107 registrations. If
      that list is available, I will contact all who are verified as
      eligible. But given the uncertainty of this process, I would
      encourage people to volunteer directly (see the bottom of this
      email for instructions). Thank you for volunteering!

      

      The list of people and posts whose terms end with the March 2021
      IETF meeting, and thus the positions for which this NomCom is
      responsible, are

      

      IETF Trust:

      Joel Halpern

      

      LLC:

      Maja Andjelkovic

      

      IAB:

      Jari Arkko

      Jeff Tantsura

      Mark Nottingham

      Stephen Farrell

      Wes Hardaker

      Zhenbin Li

      

      IESG:

      Alissa Cooper, IETF Chair/GEN AD

      Alvaro Retana, RTG AD

      Barry Leiba, ART AD

      Deborah Brungard, RTG AD

      Éric Vyncke, INT AD

      Magnus Westerlund, TSV AD

      Roman Danyliw, SEC AD

      Warren Kumari, OPS AD

      

      All appointments are for 2 years. The Routing area has 3 ADs and
      the General area has 1; all other areas have 2 ADs. Thus, all
      areas (that have more than one AD) have at least one continuing
      AD.

      

      The primary activity for this NomCom will begin in July 2020 and
      should be completed in January 2021. The NomCom will have
      regularly scheduled conference calls to ensure progress. There
      will be activities to collect requirements from the community,
      review candidate questionnaires, review feedback from community
      members about candidates, and talk to candidates.

      

      While being a NomCom member does require some time commitment it
      is also a very rewarding experience.

      

      As a member of the NomCom it is very important that you be willing
      and able to attend either videoconference or in-person meetings
      (which may not happen) during 14-20 November (IETF 109 - Bangkok)
      to conduct interviews. Videoconference attendance will be
      supported whether or not there are in-person meetings. Orientation
      and setting of the NomCom schedule will be done by videoconference
      during the week 20-24 July (exact time and date to be determined
      after NomCom membership is finalized on July 12), the week prior
      to IETF 108. Being at IETF 110 (Prague) is not essential.

      

      Please volunteer by sending me an email before 23:59 UTC June 24,
      2020, as follows:

      

      To: nomcom-chair-2020@ietf.org

      Subject: NomCom 2020-21 Volunteer

      

      Please include the following information in the email body:

      

      Your Full Name: // as you write it on the IETF registration form

      

      Current Primary Affiliation:

      // Typically what goes in the Company field

      // in the IETF Registration Form

      

      Emails: // All email addresses used to register for the past 5
      IETF meetings

      // Preferred email address first

      

      Telephone: // For confirmation if selected

      

      You should expect an email response from me within 5 business days
      stating whether or not you are qualified. If you don't receive
      this response, please re-send your email with the tag "RESEND""
      added to the subject line.

      

      If you are not yet sure if you would like to volunteer, please
      consider that NomCom members play a very important role in shaping
      the leadership of the IETF. Questions by email or voice are
      welcome. Volunteering for the NomCom is a great way to contribute
      to the IETF!

      

      You can find a detailed timeline on the NomCom web site at:

      https://datatracker.ietf.org/nomcom/2020/

      

      I will be publishing a more detailed target timetable, as well as
      details of the randomness seeds to be used for the RFC 3797
      selection process, within the next few weeks.

      

      Thank you!

      

      Barbara Stark

      bs7652 at att dot com

      nomcom-chair-2020 at ietf dot org

    

  


--------------309186290FC653643F7C0B12--


From nobody Fri Jun 12 23:23:32 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 BE3C23A092D for ; Fri, 12 Jun 2020 23:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_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 (1024-bit key) header.d=josephg.com header.b=MTuBFLFD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XDwXGg0R
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 jhjJZaBM7b6h for ; Fri, 12 Jun 2020 23:23:29 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEA93A092F for ; Fri, 12 Jun 2020 23:23:29 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1133F407 for ; Sat, 13 Jun 2020 02:23:28 -0400 (EDT)
Received: from imap35 ([10.202.2.85]) by compute1.internal (MEProxy); Sat, 13 Jun 2020 02:23:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=josephg.com; h= mime-version:message-id:date:from:to:subject:content-type; s= mesmtp; bh=3z/65/30Mhn/2R95GfHpzYL6VbJUdx3AvNHiIU6hp0Q=; b=MTuBF LFDqZCZxh6i8yEh4xu1Uoda6sg/BHSn49n0gfC4IRFIQYtgHQ2X6Zk/xXJ/ZZ+3l yPZ+QVZ/uZOMbYLE9xARvl1Io36bG7vTYn6ICef+ICRE3ZcE5vIY5bwZPdHNA+qO D/CzHRjgTO22a4R1yMrE7/3GIrtlSZO1qhkJj4=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=3z/65/30Mhn/2R95GfHpzYL6VbJUd x3AvNHiIU6hp0Q=; b=XDwXGg0RYmRJQ6fIXCHaB06K5/h7OyDby59cMChss68Pw qebsxNQ5QnfwdihXNcC4bmY4T9378EhEKItrl1l9cHNZCEyqVPyxTLs0lTkIAxbU NlFASKLsf4Z7Kz6BnCYhPMu3tpuJarIGVLC3kGw70qQPLeSnP2RcW3CAqCAP8Tvq QClh3lc9XhHSrOwruvAqTyFhrhhKNXMCoJ2SuSGzC9RFeFs35C89zWw2SUhGyLIO wOUWMCFXf5p84rwWDXvxqZd+scDYC6/42l73woEkTXEbLWII3MsnCVKbB81VQQ0A 5rBolWe1hQCIYXXwxLaVK2/I1dtNTiJ0ZoJY9kCiQ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeivddguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreertdenucfhrhhomhepfdfuvghphhcuifgvnhhtlhgvfdcuoehmvgesjhhoshgvphhh ghdrtghomheqnecuggftrfgrthhtvghrnhepudfhieduiedvtedtudekjedvkeeiueevke eileehjeetiefhteekhefgudegtdfhnecuffhomhgrihhnpehjohhsvghphhhgrdgtohhm pdhgihhthhhusgdrtghomhdpnhhpmhhjshdrtghomhenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmvgesjhhoshgvphhhghdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 70A9214C00B1; Sat, 13 Jun 2020 02:23:27 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990
Mime-Version: 1.0
Message-Id: <4cf2591e-e2d6-4149-a604-e0f6dbd8be71@www.fastmail.com>
Date: Sat, 13 Jun 2020 06:23:06 +0000
From: "Seph Gentle" 
To: jmap@ietf.org
Content-Type: text/plain
Archived-At: 
Subject: [Jmap] I made a tool to convert email to JMAP compatible JSON
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, 13 Jun 2020 06:23:32 -0000

Hi everyone!

At the hackathon in Singapore last year Neil Jenkins and I tried to make a JMAP wrapper around gmail's API. But we ran into a problem converting RFC822 message envelopes into JMAP objects.

So with a bit of help from Bron (brong) I extracted the email-to-JMAP codepath out of cyrus-imapd. (Cyrus underpins Fastmail). Anyway the end result is now we have a spec compliant, standalone C library / tool to convert email objects to JMAP-compatible json. It gives nice, clean, usable HTML from any email, extracts attachments, and all the other good stuff.

I'd love to see some alternate implementations in other languages. The extracted C code isn't particularly maintainable, but I figure this would provide a great basis for spec conformance testing. And its definitely usable on its own.

I also compiled the code to WASM and wrapped it in a nodejs library so you can convert emails to jmap json from nodejs or directly from the browser.

If you have some emails kicking around, have a play! This is a browser-only email viewer which internally loads and displays emails via jmap's format:

https://josephg.com/mail-viewer/

Code:
https://github.com/josephg/mime-to-jmap

NPM package (containing pre-compiled wasm bundle. Building it yourself is a huge pain because of libicu):
https://www.npmjs.com/package/mime-to-jmap

Hope someone finds it useful!
-Seph


From nobody Sat Jun 13 04:37:59 2020
Return-Path: 
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F943A0801 for ; Sat, 13 Jun 2020 04:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7ParSE7bOdS for ; Sat, 13 Jun 2020 04:37:55 -0700 (PDT)
Received: from usskm12.fastbighost.net (usskm12.fastbighost.net [216.155.147.116]) (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 B60CB3A07F8 for ; Sat, 13 Jun 2020 04:37:55 -0700 (PDT)
Received: from li288-253.members.linode.com ([66.228.38.253]:48736 helo=avan.tech) by usskm12.fastbighost.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jk4Ty-0001p2-BI; Sat, 13 Jun 2020 14:37:54 +0300
X-Mailer: Cypht
MIME-Version: 1.0
Cc: 
In-Reply-To: <4cf2591e-e2d6-4149-a604-e0f6dbd8be71@www.fastmail.com>
From: 
Reply-To: marc@marclaporte.com
To: Seph Gentle 
Date: Sat, 13 Jun 2020 07:37:54 -0400
Message-Id: <3af39b224ce9ed212ee53271d5abc17a@avan.tech>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - usskm12.fastbighost.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - marclaporte.com
X-Get-Message-Sender-Via: usskm12.fastbighost.net: authenticated_id: marc@marclaporte.com
X-Authenticated-Sender: usskm12.fastbighost.net: marc@marclaporte.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [Jmap] I made a tool to convert email to JMAP compatible JSON
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, 13 Jun 2020 11:37:58 -0000

Dear Seth,

Thank you very much for your contribution! Interesting use of WASM=2E

Can you add here?
https://jmap=2Eio/software=2Ehtml

Best regards,

Marc


On Sat, 13 Jun 2020 06:23:06 +0000 Seph Gentle me@josephg=2Ecom said

> Hi everyone!
>=20
> At the hackathon in Singapore last year Neil Jenkins and I tried to make =
a
> JMAP wrapper around gmail's API=2E But we ran into a problem converting RFC=
822
> message envelopes into JMAP objects=2E
>=20
> So with a bit of help from Bron (brong) I extracted the email-to-JMAP
> codepath out of cyrus-imapd=2E (Cyrus underpins Fastmail)=2E Anyway the end
> result is now we have a spec compliant, standalone C library / tool to
> convert email objects to JMAP-compatible json=2E It gives nice, clean, usab=
le
> HTML from any email, extracts attachments, and all the other good stuff=2E
>=20
> I'd love to see some alternate implementations in other languages=2E The
> extracted C code isn't particularly maintainable, but I figure this would
> provide a great basis for spec conformance testing=2E And its definitely us=
able
> on its own=2E
>=20
> I also compiled the code to WASM and wrapped it in a nodejs library so yo=
u
> can convert emails to jmap json from nodejs or directly from the browser=2E
>=20
> If you have some emails kicking around, have a play! This is a browser-on=
ly
> email viewer which internally loads and displays emails via jmap's format=
:
>=20
> https://josephg=2Ecom/mail-viewer/
>=20
> Code:
> https://github=2Ecom/josephg/mime-to-jmap
>=20
> NPM package (containing pre-compiled wasm bundle=2E Building it yourself is=
 a
> huge pain because of libicu):
> https://www=2Enpmjs=2Ecom/package/mime-to-jmap
>=20
> Hope someone finds it useful!
> -Seph
>=20
> _______________________________________________
> Jmap mailing list
> Jmap@ietf=2Eorg
> https://www=2Eietf=2Eorg/mailman/listinfo/jmap



From nobody Sat Jun 13 04:49:31 2020
Return-Path: 
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6813A081C for ; Sat, 13 Jun 2020 04:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_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 (1024-bit key) header.d=josephg.com header.b=bzt5+Tes; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cCqHR3xE
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 Vo4JNBbY4YgJ for ; Sat, 13 Jun 2020 04:49:28 -0700 (PDT)
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 0C4C23A081B for ; Sat, 13 Jun 2020 04:49:28 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 63202333; Sat, 13 Jun 2020 07:49:26 -0400 (EDT)
Received: from imap35 ([10.202.2.85]) by compute1.internal (MEProxy); Sat, 13 Jun 2020 07:49:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=josephg.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=mesmtp; bh=85oWV0wVmBqFfvbCjh2nukpzy3Ep NVy+cVroLoF7xDE=; b=bzt5+TessChSNylRPhAKR/hpjOyrQuwT4CpouSmz1yi7 xDZxpY34oXM6Og2x1aPkmnigfqaC087ZY1YSrE/mfqIX90Szq41auEpJICJVoPva h4kbvqiQ/7EEZfHurLsBMLqnUtp56LYxe+Kk+BSo60Z/tOgM2SYPUZ/LXPMcDkQ=
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=fm3; bh=85oWV0 wVmBqFfvbCjh2nukpzy3EpNVy+cVroLoF7xDE=; b=cCqHR3xE03xwVVaSpLOSdJ 0ViekP3vkS4o3LIVjpBoxb3s8d5G7qwjoaQKx0G4lVUTuE0gDAWzl5mDHkJnKJG0 NSOTCZPrx9ZPyX0pcMv8gpFIHJVvSZYopCMv7g0Ll1Jf+6eWeTof5o1WU04ZQKCb 7kowRvdldCrti9mVA+SvGpulI+SnMIvO69svi2P9snnOIEjEr29DKyXmxvCQDzTi Ern/Ps2hEeoN09j53xtoO5sCuVy5FNr38dGl4/lPOzYvfrQlOzj1zFKDso4rQYxA Cc3SsDk5HdLqz8RppK5pxY7sSoC3HMGzuYZjx5p4ErLMJkHrQTSuyjDwbIM61i6w ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeifedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfufgvphhhucfivghnthhlvgdfuceomhgvsehjohhsvghp hhhgrdgtohhmqeenucggtffrrghtthgvrhhnpeetueeivddujeevjeelteekleejledvfe efkedvheetjeetudejhfeigfeggeevvdenucffohhmrghinhepjhhmrghprdhiohdpjhho shgvphhhghdrtghomhdpghhithhhuhgsrdgtohhmpdhnphhmjhhsrdgtohhmpdhivghtfh drohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehmvgesjhhoshgvphhhghdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 76F5C14C00B1; Sat, 13 Jun 2020 07:49:25 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990
Mime-Version: 1.0
Message-Id: <1a8f9067-6630-4304-90c5-db601f213d52@www.fastmail.com>
In-Reply-To: <3af39b224ce9ed212ee53271d5abc17a@avan.tech>
References: <3af39b224ce9ed212ee53271d5abc17a@avan.tech>
Date: Sat, 13 Jun 2020 11:49:05 +0000
From: "Seph Gentle" 
To: marc@marclaporte.com
Cc: jmap@ietf.org
Content-Type: text/plain
Archived-At: 
Subject: Re: [Jmap] I made a tool to convert email to JMAP compatible JSON
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, 13 Jun 2020 11:49:30 -0000

Thanks; and absolutely!

Its a bit difficult to build and use from C at the moment - I haven't set up a shim / API / CLI tool to make that easy. Let me know if thats something folks are interested in.

-Seph


On Sat, Jun 13, 2020, at 11:37 AM, marc@marclaporte.com wrote:
> Dear Seth,
> 
> Thank you very much for your contribution! Interesting use of WASM.
> 
> Can you add here?
> https://jmap.io/software.html
> 
> Best regards,
> 
> Marc
> 
> 
> On Sat, 13 Jun 2020 06:23:06 +0000 Seph Gentle me@josephg.com said
> 
> > Hi everyone!
> > 
> > At the hackathon in Singapore last year Neil Jenkins and I tried to make a
> > JMAP wrapper around gmail's API. But we ran into a problem converting RFC822
> > message envelopes into JMAP objects.
> > 
> > So with a bit of help from Bron (brong) I extracted the email-to-JMAP
> > codepath out of cyrus-imapd. (Cyrus underpins Fastmail). Anyway the end
> > result is now we have a spec compliant, standalone C library / tool to
> > convert email objects to JMAP-compatible json. It gives nice, clean, usable
> > HTML from any email, extracts attachments, and all the other good stuff.
> > 
> > I'd love to see some alternate implementations in other languages. The
> > extracted C code isn't particularly maintainable, but I figure this would
> > provide a great basis for spec conformance testing. And its definitely usable
> > on its own.
> > 
> > I also compiled the code to WASM and wrapped it in a nodejs library so you
> > can convert emails to jmap json from nodejs or directly from the browser.
> > 
> > If you have some emails kicking around, have a play! This is a browser-only
> > email viewer which internally loads and displays emails via jmap's format:
> > 
> > https://josephg.com/mail-viewer/
> > 
> > Code:
> > https://github.com/josephg/mime-to-jmap
> > 
> > NPM package (containing pre-compiled wasm bundle. Building it yourself is a
> > huge pain because of libicu):
> > https://www.npmjs.com/package/mime-to-jmap
> > 
> > Hope someone finds it useful!
> > -Seph
> > 
> > _______________________________________________
> > Jmap mailing list
> > Jmap@ietf.org
> > https://www.ietf.org/mailman/listinfo/jmap
> 
> 
>


From nobody Sun Jun 14 22:45:02 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 D00093A09D3; Sun, 14 Jun 2020 22:44:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: jmap@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: jmap@ietf.org
Message-ID: <159219989378.8435.3304926851898961656@ietfa.amsl.com>
Date: Sun, 14 Jun 2020 22:44:53 -0700
Archived-At: 
Subject: [Jmap] I-D Action: draft-ietf-jmap-calendars-03.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, 15 Jun 2020 05:44:54 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the JSON Mail Access Protocol WG of the IETF.

        Title           : JMAP for Calendars
        Authors         : Neil Jenkins
                          Michael Douglass
	Filename        : draft-ietf-jmap-calendars-03.txt
	Pages           : 44
	Date            : 2020-06-14

Abstract:
   This document specifies a data model for synchronizing calendar data
   with a server using JMAP.


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

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

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


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 Jun 15 07:34:54 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 8CE733A0DDA; Mon, 15 Jun 2020 07:34:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: jmap@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: jmap@ietf.org
Message-ID: <159223169353.12809.1278283414996050403@ietfa.amsl.com>
Date: Mon, 15 Jun 2020 07:34:53 -0700
Archived-At: 
Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-02.txt
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Jun 2020 14:34:54 -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-02.txt
	Pages           : 17
	Date            : 2020-06-15

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-02
https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-02

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


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

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



From nobody Tue Jun 16 08:37:53 2020
Return-Path: 
X-Original-To: jmap@ietf.org
Delivered-To: jmap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5A23A17B2; Tue, 16 Jun 2020 08:37:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: internet-drafts@ietf.org
To: 
Cc: jmap@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: jmap@ietf.org
Message-ID: <159232187112.8357.11988987338710903029@ietfa.amsl.com>
Date: Tue, 16 Jun 2020 08:37:51 -0700
Archived-At: 
Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-10.txt
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Jun 2020 15:37:51 -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-10.txt
	Pages           : 13
	Date            : 2020-06-16

Abstract:
   JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic
   protocol for synchronising data, such as mail, calendars or contacts,
   between a client and a server.  It is optimised for mobile and web
   environments, and aims to provide a consistent interface to different
   data types.

   JMAP for Mail ([RFC8621] - The JSON Meta Application Protocol (JMAP)
   for Mail) specifies a data model for synchronising email data with a
   server using JMAP.  Clients can use this to efficiently search,
   access, organise, and send messages.

   MDN are defined in [RFC8098] and are used as "read receipts",
   "acknowledgements", or "receipt notifications".

   MDN have a specific format that must be parsed or generated.  The
   goal of this document is to specify a data model for handling 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-10
https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-10

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


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 Jun 17 03:54:08 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 96FEA3A0944 for ; Wed, 17 Jun 2020 03:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCAFCWL_il6X for ; Wed, 17 Jun 2020 03:54:03 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AD83A0949 for ; Wed, 17 Jun 2020 03:54:02 -0700 (PDT)
Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49n24T1GXNzysH; Wed, 17 Jun 2020 12:54:01 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: <159223169353.12809.1278283414996050403@ietfa.amsl.com>
Date: Wed, 17 Jun 2020 12:53:59 +0200
Cc: Henk Birkholz 
X-Mao-Original-Outgoing-Id: 614084039.402895-b52de24ec7030f435af9c51b01f7b5a9
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <159223169353.12809.1278283414996050403@ietfa.amsl.com>
To: jmap@ietf.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-jscontact-02.txt
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jun 2020 10:54:07 -0000

I=E2=80=99m trying to understand this draft, with a view to creating a =
CDDL description that should aid in understanding the English language =
definition of the structure.  I=E2=80=99m getting stuck at places like =
2.1.5, which is inscrutable.  What is a Relation object?  What is a =
relation type?  Of course, I can guess from the various clues, but it =
would be better if that weren=E2=80=99t necessary.

Is there a collection of examples that could be used to disambiguate the =
text?  That might help in creating the CDDL (which, really, should be a =
one-hour effort, without all the guesswork).
Possible positive side effects would include in turn validating that set =
of examples, and making sure terms like vendor-specific have a =
well-defined meaning.

I planned to briefly join the interim meeting today, but I can't, so =
here=E2=80=99s my plea for help on the mailing list.

Gr=C3=BC=C3=9Fe, Carsten


> On 2020-06-15, at 16:34, internet-drafts@ietf.org wrote:
>=20
>=20
> 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.
>=20
>        Title           : JSContact: A JSON representation of contact =
data
>        Authors         : Robert Stepanek
>                          Mario Loffredo
> 	Filename        : draft-ietf-jmap-jscontact-02.txt
> 	Pages           : 17
> 	Date            : 2020-06-15
>=20
> 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.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-jmap-jscontact-02
> https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-02
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jmap-jscontact-02
>=20
>=20
> 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.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
>=20


From nobody Wed Jun 17 04:29:38 2020
Return-Path: 
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32ADB3A09AB for ; Wed, 17 Jun 2020 04:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ahJFTbKln0Tw for ; Wed, 17 Jun 2020 04:29:35 -0700 (PDT)
Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 36A6D3A0911 for ; Wed, 17 Jun 2020 04:29:33 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2F27QAW/ule/xwBYJlmHAEBATwBAQQ?= =?us-ascii?q?EAQECAQEHAQEVgUMEAQEDAQGBOgIBAYMUhBqIIgGIPpomgXsLAQEBAQEBAQE?= =?us-ascii?q?BBgEBExoCBAEBhDuCKAEkPAINAhACCAEBAQYEAgKGUEIWAYYYDwEFWgIaAiY?= =?us-ascii?q?CSRYNCAEBgyKCfAWaeZt6gTKFUYNegUCBDigCAQEBAYxXD4FMP4ERJwwDglo?= =?us-ascii?q?+hQqCR4JgBI9BgmCheSgHgViBBYEGBAuXfgUKHZB3Bo1rr1ACBAIJAhWCAYF?= =?us-ascii?q?iTSRPgmpPFwINnGeBKQIGAQcBAQMJfIx3gWwBgRABAQ?=
X-IPAS-Result: =?us-ascii?q?A2F27QAW/ule/xwBYJlmHAEBATwBAQQEAQECAQEHAQEVg?= =?us-ascii?q?UMEAQEDAQGBOgIBAYMUhBqIIgGIPpomgXsLAQEBAQEBAQEBBgEBExoCBAEBh?= =?us-ascii?q?DuCKAEkPAINAhACCAEBAQYEAgKGUEIWAYYYDwEFWgIaAiYCSRYNCAEBgyKCf?= =?us-ascii?q?AWaeZt6gTKFUYNegUCBDigCAQEBAYxXD4FMP4ERJwwDglo+hQqCR4JgBI9Bg?= =?us-ascii?q?mCheSgHgViBBYEGBAuXfgUKHZB3Bo1rr1ACBAIJAhWCAYFiTSRPgmpPFwINn?= =?us-ascii?q?GeBKQIGAQcBAQMJfIx3gWwBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.73,522,1583190000"; d="scan'208";a="18472302"
Received: from mail-mtaka28.fraunhofer.de ([153.96.1.28]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2020 13:29:31 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0Dm0wBH/ele/1lIDI1mHQEBPAEFBQE?= =?us-ascii?q?CAQkBFYFDBQEDAQGBOgIBaXJUMDaEGogiAYg+miaBewsBAwEBAQEBBgEBLQI?= =?us-ascii?q?EAQGEO4ImAiQ8Ag0CEAEBBQMCAQYEbYVnQhYBhUMPAQVaAhoCJgJJFg0IAQG?= =?us-ascii?q?DIoMBmnabeoEyhVGDYYFAgQ4oAgEBAYxYD4FMP4ERJwwDglo+hQqCR4JgBI9?= =?us-ascii?q?BgmCheSgHgViBBYEGBAuXfgUKHZB3Bo1rr1ACBAIJAhWCAQuBVk0kT4JqTxc?= =?us-ascii?q?CDZxnQWgCBgEHAQEDCXyMd4FsAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.73,522,1583190000"; d="scan'208";a="28857022"
Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA28.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2020 13:29:29 +0200
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 05HBTStJ013634 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT) for ; Wed, 17 Jun 2020 13:29:29 +0200
Received: from [192.168.16.50] (79.234.115.101) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 17 Jun 2020 13:29:23 +0200
To: 
From: Henk Birkholz 
Message-ID: 
Date: Wed, 17 Jun 2020 13:29:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.115.101]
Archived-At: 
Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-jscontact-02.txt
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Jun 2020 11:29:37 -0000

Hi all,

as highlighted in the last virtual interim, I am creating a CDDL spec 
based on the latest I-D.ietf-jmap-jscontact.

The ongoing work most likely includes subjective bias and how my 
interpretation of the English text in the I-D looks like. Most likely, 
there are things that I interpret wrong :) Therefore, a targeted ask to 
this list:

Would it be possible to get a few examples of JSON instances of 
jscontact "card" objects? This would enable some test wrt the CDDL spec 
and would also highlight where I misunderstood the description in 
English text.

Unfortunately, I have a hard blocker today so I cannot join the jmap 
interim meeting. But I hope that the CDDL is at least in parts 
self-explanatory.

Viele Grüße,

Henk


From nobody Sat Jun 20 00:14:32 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 ACF163A078A for ; Sat, 20 Jun 2020 00:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqTrs0QE2Y2e for ; Sat, 20 Jun 2020 00:14:28 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA143A0793 for ; Sat, 20 Jun 2020 00:14:27 -0700 (PDT)
Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49pn3k2g30zyV1; Sat, 20 Jun 2020 09:14:26 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Carsten Bormann 
In-Reply-To: 
Date: Sat, 20 Jun 2020 09:14:25 +0200
Cc: Henk Birkholz 
X-Mao-Original-Outgoing-Id: 614330065.766957-ab7b95187dc84ff033a61882555c5259
Content-Transfer-Encoding: quoted-printable
Message-Id: <2930AA0D-330E-4A5E-82D7-3B09D723D284@tzi.org>
References: <159223169353.12809.1278283414996050403@ietfa.amsl.com> 
To: jmap@ietf.org
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: 
Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-jscontact-02.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, 20 Jun 2020 07:14:31 -0000

On 2020-06-17, at 12:53, Carsten Bormann  wrote:
>=20
> Is there a collection of examples that could be used to disambiguate =
the text?

(Apologies for the uncoordinated request=E2=80=A6)

Is there really no such collection?

Gr=C3=BC=C3=9Fe, Carsten


From nobody Mon Jun 22 08:31:11 2020
Return-Path: 
X-Original-To: jmap@ietf.org
Delivered-To: jmap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 145883A0E01; Mon, 22 Jun 2020 08:31:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: internet-drafts@ietf.org
To: 
Cc: jmap@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.2
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: jmap@ietf.org
Message-ID: <159283987001.31035.14770609981304374699@ietfa.amsl.com>
Date: Mon, 22 Jun 2020 08:31:10 -0700
Archived-At: 
Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-11.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, 22 Jun 2020 15:31:10 -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-11.txt
	Pages           : 13
	Date            : 2020-06-22

Abstract:
   JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic
   protocol for synchronising data, such as mail, calendars or contacts,
   between a client and a server.  It is optimised for mobile and web
   environments, and aims to provide a consistent interface to different
   data types.

   JMAP for Mail ([RFC8621] - The JSON Meta Application Protocol (JMAP)
   for Mail) specifies a data model for synchronising email data with a
   server using JMAP.  Clients can use this to efficiently search,
   access, organise, and send messages.

   MDN are defined in [RFC8098] and are used as "read receipts",
   "acknowledgements", or "receipt notifications".

   MDN have a specific format that must be parsed or generated.  The
   goal of this document is to specify a data model for handling 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-11
https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-11

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


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

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



From nobody Tue Jun 23 22:29:01 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 0491F3A080A for ; Tue, 23 Jun 2020 22:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=eo3UGMaK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y/93uOYI
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 qR9nV6P1sqkf for ; Tue, 23 Jun 2020 22:28:58 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F23083A077A for ; Tue, 23 Jun 2020 22:28:57 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 03328AF1; Wed, 24 Jun 2020 01:28:56 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 24 Jun 2020 01:28:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=TD9G r/eCS3G1v0kYN9XXZ8Jb1446xw7KeXdBPebyCko=; b=eo3UGMaKf24kpQCJSvAe b86iStvYmahbITqQkPqrpiTh9DfvO/2OQ10dzRGk7NOYyxDp0pKaoEmH8IyDCyoQ m6V/yrD7DAW6FUoHx/VTgUbf4KcfIwI1LXAv94DaCsNlPuNNZsAUzbcelBOTWZZp eJnjrMVA6scXwhgTjLz/iGC2kZ5qLz32ZL1JJeJW3nguE9MQkp1mjg6EHq7+t5Cv nXxQi2IwASVmTMo9hxo5PwBa7xrCzY0Bfw6uavUks6uOob12pZltcnnRE+kQXo6s /+y2vYBGQ3LJOGHJIwtCODRlzdI3IQ3ir5yVK0XNBpX82AuwKJkD3JqjLC3on+Jw yQ==
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=fm3; bh=TD9Gr/ eCS3G1v0kYN9XXZ8Jb1446xw7KeXdBPebyCko=; b=Y/93uOYI9uAQxhPaGGDBdU m4OMxo4ulvviBaveOAlOmCBuoikFZ016D1+t0Os1GYqTgg37Wv2Soi/Sw396Ua4E c+5CI18FRpNNAyAam71gdMDiMFLIFpyBIs+/E7wDsgATXBcBhnoHv5DOhTZJjRp/ jpktKBDeO9gcHtJNDqYTl7w/oxrzrf7SPJmcso3ZWVLrXH/p9nQlL1zIStmDCVL7 Jppo8OQ/QKHKF7UC+Vq664g3inqtLLNmkXD+0CXZrSpssF0g08PIFaWzfc3EDDZI ke2mH3uP6HydpgpTcddmms2LmkuHsZLS6kGMaytEvcBIB3QyovVghTdauRzE5CsA ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekiedgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepffdvkeefgeelieeutedttdffheevvefffeekuddvtddt keeigfejuddvhfdvudelnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 25D0D180091; Wed, 24 Jun 2020 01:28:56 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000
Mime-Version: 1.0
Message-Id: <1038d50c-fe3b-47b8-bfac-763694fb00d3@dogfood.fastmail.com>
In-Reply-To: <159283987001.31035.14770609981304374699@ietfa.amsl.com>
References: <159283987001.31035.14770609981304374699@ietfa.amsl.com>
Date: Wed, 24 Jun 2020 15:28:34 +1000
From: "Bron Gondwana" 
To: jmap@ietf.org
Cc: "Raphael OUAZANA" 
Content-Type: multipart/alternative; boundary=25a56c0c46234697ae3324b55d179d70
Archived-At: 
Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-mdn-11.txt
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 05:29:00 -0000

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

Hi Raphael,

This looks fantastic! Thanks so much for revising it so quickly.

I have only a couple of tiny comments.

*2.1.  MDN/send*

   o  onSuccessUpdateEmail: "Id[PatchObject]|null" A map of creation id
      to an object containing properties to update on the Email object
      referenced by the "MDN/send" if the sending succeeds.

This shouldn't be "creation id" it should just be "id", as seen later in=
 the example where it's prefixed with a '#' making it a back reference t=
o the ID created by the send. This is a little weird because MDN/send do=
esn't create an object, but it does need to create some kind of at least=
 session-length ID in order for the lookup in the Email/set to work.

So I would just remove the word "creation" from this and say "A map of i=
d to an object ...". Maybe add text: "this will always be a backreferenc=
e to the creation id (see example below)".

*3.1.  Sending an MDN for a received email*

The example still shows the Email/set response including the keywords up=
date, which it should not. It should just be:

     [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]


Cheers,

Bron.

On Tue, Jun 23, 2020, at 01:31, 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-11.txt
> Pages : 13
> Date : 2020-06-22
>=20
> Abstract:
>  JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic
>  protocol for synchronising data, such as mail, calendars or contacts,=

>  between a client and a server. It is optimised for mobile and web
>  environments, and aims to provide a consistent interface to different=

>  data types.
>=20
>  JMAP for Mail ([RFC8621] - The JSON Meta Application Protocol (JMAP)
>  for Mail) specifies a data model for synchronising email data with a
>  server using JMAP. Clients can use this to efficiently search,
>  access, organise, and send messages.
>=20
>  MDN are defined in [RFC8098] and are used as "read receipts",
>  "acknowledgements", or "receipt notifications".
>=20
>  MDN have a specific format that must be parsed or generated. The
>  goal of this document is to specify a data model for handling 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-11
> https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-11
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-jmap-mdn-11
>=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


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


Hi Raphael,

This looks fantastic! =
; Thanks so much for revising it so quickly.

I have only =
a couple of tiny comments.
2.1.  MDN/send

   o  onSuccessUpdateEmail: "Id[PatchObject]|null" =
A map of creation id
      to an object containing properties to update on the Email object
      referenced by the "MDN/send" if the sending succeeds.

This shouldn't be "creation id" it should just be "id", as seen later=
 in the example where it's prefixed with a '#' making it a back referenc=
e to the ID created by the send.  This is a little weird because MD=
N/send doesn't create an object, but it does need to create some kind of=
 at least session-length ID in order for the lookup in the Email/set to =
work.

So I would just remove the word "creation" from thi=
s and say "A map of id to an object ...".  Maybe add text: "this wi=
ll always be a backreference to the creation id (see example below)".

3.1.  Sending=
 an MDN for a received email

The example still shows =
the Email/set response including the keywords update, which it should no=
t.  It should just be:
<=
br>
     [ "Email/set", {
       "accountId": "ue150411c",
       "oldState": "23",
       "newState": "42",
       "updated": {
         "Md45b47b4877521042cec0938": {}
       }
     }, "0" ]]


Cheers,

Bron.

On Tue, Jun 23, 2020, at 01:31, internet-drafts@ietf.org wrote:
<=
blockquote type=3D"cite" id=3D"qt" style=3D"">

A New Internet-Draft=
 is available from the on-line Internet-Drafts directories.
This draft is a work item of the JSON Mai=
l Access Protocol WG of the IETF.

    =
;    Title        =
;   : Handling Message Disposition Notification with JMAP
<=
/div>
     &nb=
sp;  Author          :=
 Rapha=C3=ABl Ouazana
Filenam=
e        : draft-ietf-jmap-mdn-11.txt=

Pages    =
;       : 13
Date         =
   : 2020-06-22
Abstract:
   JMAP ([RFC8620] - JSON Meta Applicatio=
n Protocol) is a generic
&nbs=
p;  protocol for synchronising data, such as mail, calendars or con=
tacts,
   between a=
 client and a server.  It is optimised for mobile and web
=

   environments, and aims to=
 provide a consistent interface to different
   data types.

   JMA=
P for Mail ([RFC8621] - The JSON Meta Application Protocol (JMAP)
   for Mail) specifies a =
data model for synchronising email data with a
   server using JMAP.  Clients can use =
this to efficiently search,
&=
nbsp;  access, organise, and send messages.

 &n=
bsp; MDN are defined in [RFC8098] and are used as "read receipts",
   "acknowledgements", o=
r "receipt notifications".
   MDN have a specif=
ic format that must be parsed or generated.  The
   goal of this document is to specif=
y a data model for handling MDN
   messages with a server using JMAP.


The IETF datatracker status page fo=
r this draft is:

There are also ht=
mlized versions available at:

A diff from the previous version is available=
 at:


Please note that it may take a couple of minute=
s 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:
=


<=
br>
_____________________________=
__________________
Jmap maili=
ng list


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



--25a56c0c46234697ae3324b55d179d70--


From nobody Tue Jun 23 22:38:23 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 7A3EF3A0B80 for ; Tue, 23 Jun 2020 22:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Um+okVMA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XHJ0jqta
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 nBwER91aiEOT for ; Tue, 23 Jun 2020 22:38:20 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CD43A0B7E for ; Tue, 23 Jun 2020 22:38:19 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 10B70B03 for ; Wed, 24 Jun 2020 01:38:19 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 24 Jun 2020 01:38:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=B98rNZ8DPD6R1bDr8xNj45hOOBeVEhQtf/E1qtZ zHh0=; b=Um+okVMAB6XGFtqGgBDqkGibIVZ/g/AaJEuMlRq5bXWHjInzrsuxTM6 w1osETbj+qLEc1RDdTbAkAy6AQvFSeBCzbV9V15Swhbj9fEifqaYq2QKXpjWFiVQ BQR2SVveZvQpyZ+yHgNdr4mM2Szbu3tJNjyMPCXOxFtR+av1KSgqhcq+8SgXqtMv omW+AaSTwZ0TO7/0wM6CnW9DUDJM51IYkCF9M7eVQ2gZeuwb8fqVN9sQyr3wUjRA RJymxK/T/6JzsYm/qIbYJ/31LQPa58xBY4eom1Y+TT0S57cJn4C5wFxPfblqkLs1 z374+O6/x5Dyyugl2i2dRccAvA/1MZg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=B98rNZ8DPD6R1bDr8xNj45hOOBeVE hQtf/E1qtZzHh0=; b=XHJ0jqta7fbuNein5DyW39hLBH0vaqyJFbpPG9JLum2vZ tRSuMY1vZO8j+pu9cmt7IS5TZkb+EbV/rax73SahmJe+hJXWYPrEDmBgKEMhDWuu jtuGxBeTBLfEX3isI/Cqgwkj76EkvZTzqJB6U6QYSPHVO9ahgBzDWs4zR4xaBqbC MRRUdJEymhZcajLoBXKBbbR2AqHbF+ngi3edSg49dEr2USvmEbKEvg062IpQW85U AZQaPSAaEVr1H0yhNqlOxzkhWyg3S+kRE9DNwef2V8r/XVBpHRn3lQ5nPEpvYqUc H4REyeeQx0pj0ADyepey63v638xulnJZ4VQf5XppQ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekiedgleekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhjeehkeejkeehve eutdejteeihffffeduiedttdejhfelteevueehudeltdeuffenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 65A8B180091; Wed, 24 Jun 2020 01:38:18 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000
Mime-Version: 1.0
Message-Id: 
Date: Wed, 24 Jun 2020 15:37:58 +1000
From: "Bron Gondwana" 
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=31497fc2b2cb4a698189589d58a62482
Archived-At: 
Subject: [Jmap] Actions from last week's interim meeting
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, 24 Jun 2020 05:38:22 -0000

--31497fc2b2cb4a698189589d58a62482
Content-Type: text/plain

*Full minutes are online here:*

https://datatracker.ietf.org/meeting/interim-2020-jmap-01/materials/minutes-interim-2020-jmap-01-202006172300

If you have any actions, please make sure you do them :) Thanks. Special mention to Raphael, who has already done the MDN doc update - great work!

*Here's the ACTION points:*

ACTION: Alexey will prepare a revision of S/MIME document by IETF108, it should be ready for WGLC then.

ACTION: Bron to write up Shepherding doc for MDN doc.
ACTION: Bron to issue call for adoption of JSContact vcard mapping document.
ACTION: Bron to update milestones for JMAP working group

ACTION: Henk to send updated JSContact CDDL definition

ACTION: Neil to do more work on JMAP Calendars spec.

ACTION: Raphael to wait a few days for feedback on the list then issue one more update to MDN doc with the ability to set extensions. - *DONE*

ACTION: Robert and Mario to give examples or tool for jscontact/vcard translation to test CDDL against

Cheers,

Bron.

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


--31497fc2b2cb4a698189589d58a62482
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


Full minutes are online here:


If you have any actions, please make sure yo=
u do them :)  Thanks.  Special mention to Raphael, who has alr=
eady done the MDN doc update - great work!

Here's the =
ACTION points:

=

ACTI=
ON: Alexey will prepare a revision of S/MIME document by IETF108, it sho=
uld be ready for WGLC then.

ACTION: Bron to write up Shepherding doc for MDN doc.
<=
/div>
ACTION: Bron to issue call for ad=
option of JSContact vcard mapping document.
ACTION: Bron to update milestones for JMAP working grou=
p

<=
div>ACTION: Henk to send updated JSContact CDDL definition

ACTION: Ne=
il to do more work on JMAP Calendars spec.

ACTION: Raphael to wait a few days fo=
r feedback on the list then issue one more update to MDN doc with the ab=
ility to set extensions. - DONE

ACTION: Robe=
rt and Mario to give examples or tool for jscontact/vcard translation to=
 test CDDL against

=

Cheers,

Bron.

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



--31497fc2b2cb4a698189589d58a62482--


From nobody Tue Jun 23 23:00:54 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 A15C83A0B97 for ; Tue, 23 Jun 2020 23:00:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 7.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159297845064.32087.10313805444146629518@ietfa.amsl.com>
Date: Tue, 23 Jun 2020 23:00:50 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Jmap] Milestones changed for jmap WG
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 06:00:51 -0000

Changed milestone "Adopt a document for a JSON Contact format (after
recharter)", resolved as "Done".

Changed milestone "Submit Message Disposition Notification document to the
IESG", set due date to June 2020 from December 2019.

Changed milestone "Submit JMAP S/MIME signature validation document to the
IESG", set due date to July 2020 from February 2020.

Changed milestone "Adopt a document for S/MIME key management and server side
signing/encryption", set due date to August 2020 from February 2020.

Changed milestone "Submit JMAP Quotas document to the IESG", set due date to
August 2020 from February 2020.

Changed milestone "Adopt a document defining JMAP access to addressbooks",
set due date to August 2020 from July 2020.

URL: https://datatracker.ietf.org/wg/jmap/about/


From nobody Tue Jun 23 23:05:07 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 5DC233A0B96 for ; Tue, 23 Jun 2020 23:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=iFzky5+q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kgaSRyhO
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 yDida9TmxI1b for ; Tue, 23 Jun 2020 23:05:03 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1A83A0776 for ; Tue, 23 Jun 2020 23:05:02 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 730CF49E for ; Wed, 24 Jun 2020 02:05:01 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 24 Jun 2020 02:05:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=wsrE871ff4F04lUKcliTelM4n2vhGhBZQ/EbX6n vI+s=; b=iFzky5+qZE9sx/3ZcfUYNmkfwtCYpgNyuXoV/z1ArLAvNJzG1i2Z5Ze eG9psxiZe9E9kw4jXwOobLOQzunC8HUut+ProqaFV93SQU1vnAiFy5Rb+dy3yF7Q Dbge6rkVJ8ARRb1ArSOJo/0OykkWDnR9udFsMmR2kgtTYbuC6yjsyEU/LSHjEcLW EgTRP6TvGi4AJQTyTuPNU6+hEev99kYFKoE4yaD/Osg9Y8acRh7TdPJAWT//QKVq wsrelVka8HeRl/jYx3/Nj+ih0HT6Aph5r8D3iIl/p4lPUuJQhqsTHw5EZE6jht8E zit5egqEMSsBQf1iAx+ligzzOLUocCA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=wsrE871ff4F04lUKcliTelM4n2vhG hBZQ/EbX6nvI+s=; b=kgaSRyhOL7HD+NNdS+1XM5aJEOLzMMqdJqTZaHN6ODRDt 4R9gvN5xH1QybW7XUTW/zVM56t34xn9ELnYGrhsC1AcDOY/GGzzuUHc3Kv2VASnP WYcbT/LWivCveWviDdY6tT6k7LW9wiqwUVirKqbkuLOG6WPqSnGyJJv5FunB4Duy C4QFBYbtQqrtp/bjB2ccCTV4D0YGJNlkdxo2yPeRsj1Xbdg6kd/rAarb/7FSXxhi rn4OlSjKLZR11D7oMfVdOW3Ra8SmZKLntadFAWNGpoDnn2XOceAZEaMan4hj/5lv f+09y9KjvXnjtGzrDT435tOe5aYfAF8URHklG1EZA==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekiedguddtfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdelfeegudette fhheegtdelvefhudduhfeijeeghedtveeitddtuefggedvjeehnecuffhomhgrihhnpehi vghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8EA95180091; Wed, 24 Jun 2020 02:05:00 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000
Mime-Version: 1.0
Message-Id: 
Date: Wed, 24 Jun 2020 16:04:39 +1000
From: "Bron Gondwana" 
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=12a2595016734731b29cf7d84e696fc1
Archived-At: 
Subject: [Jmap] =?utf-8?q?Call_for_adoption_for_document_defining_mapping?= =?utf-8?q?s_between_VCARD_and_JSContact?=
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, 24 Jun 2020 06:05:05 -0000

--12a2595016734731b29cf7d84e696fc1
Content-Type: text/plain

As discussed in the interim last week, this is a formal call for adoption of:

https://datatracker.ietf.org/doc/draft-loffredo-jmap-jscontact-vcard/

This document is designed as a companion for our existing document:

https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/

Since this one is so simple, and was mentioned in the minutes of the last call already, I'm just going to give one week on this - so please reply by July 1st if you have any objections to us taking on this document (with the understanding that it's still a work in progress).

Cheers,

Bron.


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


--12a2595016734731b29cf7d84e696fc1
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


As discussed in the interim last week, this is a formal ca=
ll for adoption of:


This docum=
ent is designed as a companion for our existing document:

https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/

Since this one is so simple, and was mentioned in the minutes of=
 the last call already, I'm just going to give one week on this - so ple=
ase reply by July 1st if you have any objections to us taking on this do=
cument (with the understanding that it's still a work in progress).
<=
/div>

Cheers,

Bron.<=
br>


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



--12a2595016734731b29cf7d84e696fc1--


From nobody Wed Jun 24 07:11:41 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 8C9C03A0DE9 for ; Wed, 24 Jun 2020 07:11:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 7.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159300789956.4870.10805308101706350409@ietfa.amsl.com>
Date: Wed, 24 Jun 2020 07:11:39 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Jmap] Milestones changed for jmap WG
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Jun 2020 14:11:40 -0000

Changed milestone "Adopt a document defining mappings between VCARD and
JSContact", set state to active from review, accepting new milestone.

URL: https://datatracker.ietf.org/wg/jmap/about/


From nobody Thu Jun 25 02:03:40 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 73E093A0889 for ; Thu, 25 Jun 2020 02:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK1RWaKwlVLm for ; Thu, 25 Jun 2020 02:03:37 -0700 (PDT)
Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775253A0882 for ; Thu, 25 Jun 2020 02:03:37 -0700 (PDT)
Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 059F21F5AE; Thu, 25 Jun 2020 09:03:37 +0000 (UTC)
Date: Thu, 25 Jun 2020 09:03:36 +0000
From: Eric Wong 
To: jmap@ietf.org
Message-ID: <20200625090336.GA32628@dcvr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Archived-At: 
Subject: [Jmap] recommendations for gigantic mailboxes
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, 25 Jun 2020 09:03:39 -0000

Hi all, I'm considering implementing JMAP in public-inbox[1].

TL;DR: would it be reasonable to expose 10 million messages in a
single JMAP mailbox?  It can already be done for an NNTP newsgroup :>


public-inbox started with NNTP and HTTP support, but I recently
started implementing an IMAP server and it seems fine.  It's
mainly tested with mutt, isync|mbsync, offlineimap, and Gnus.

Whereas newsreaders typically have a rolling window where
messages expire; MUAs and IMAP <=> Maildir syncing tools tend to
hold messages forever.  That's slow when mailboxes get into the
order of 100K...

MUAs and Maildirs on traditional filesystems fall down with 400K
messages in the git@vger.kernel.org mailing list, so right now
it's broken into 9 segments capped at 50K messages, each:

  imaps://public-inbox.org/INBOX.comp.version-control.git.0
  ..
  imaps://public-inbox.org/INBOX.comp.version-control.git.8

400K is nothing, even.  LKML has 3.6 million and grows around
30K a month[2]:

  https://lore.kernel.org/lkml/
  nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel

So, JMAP is fresh ground; so I wonder if having a single mailbox
on the order of 10 million messages is reasonable for JMAP clients.
NNTP clients have no problem handling a newsgroup that large.

Or if I should go route I did with IMAP and partition mailboxes
virtually into 50K or so.  It doesn't affect the underlying
storage at all.  I wasn't really happy to do that for IMAP, but
the prevalance and limitations of existing MUAs had to be taken
into account (and I still work on a Centrino laptop from 2005,
sometimes).

Thanks for reading!


[1] https://public-inbox.org/README.html
    Archives mail in git; indexes using Xapian + SQLite.

[2] LKML required designing the v2 public-inbox format
    back in 2018 for scalability:
    https://public-inbox.org/public-inbox-v2-format.html
    I've tested it up to 10M or so before running out of space;
    but I expect it to do more in ~10 years (if civilization
    survives that long!)


From nobody Thu Jun 25 08:50:58 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 977C03A0C0E; Thu, 25 Jun 2020 08:50:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: internet-drafts@ietf.org
To: 
Cc: jmap@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: jmap@ietf.org
Message-ID: <159310025254.30341.7170166747742479400@ietfa.amsl.com>
Date: Thu, 25 Jun 2020 08:50:52 -0700
Archived-At: 
Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-12.txt
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
List-Id: JSON Message Access Protocol 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jun 2020 15:50:53 -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-12.txt
	Pages           : 13
	Date            : 2020-06-25

Abstract:
   JMAP ([RFC8620] - JSON Meta Application Protocol) is a generic
   protocol for synchronising data, such as mail, calendars or contacts,
   between a client and a server.  It is optimised for mobile and web
   environments, and aims to provide a consistent interface to different
   data types.

   JMAP for Mail ([RFC8621] - The JSON Meta Application Protocol (JMAP)
   for Mail) specifies a data model for synchronising email data with a
   server using JMAP.  Clients can use this to efficiently search,
   access, organise, and send messages.

   MDN are defined in [RFC8098] and are used as "read receipts",
   "acknowledgements", or "receipt notifications".

   MDN have a specific format that must be parsed or generated.  The
   goal of this document is to specify a data model for handling 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-12
https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-12

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


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

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



From nobody Thu Jun 25 22:54:08 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 9D7073A0033 for ; Thu, 25 Jun 2020 22:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=KSHq//xD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uMJvbouR
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 7dwR-erBx7ZA for ; Thu, 25 Jun 2020 22:54:02 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B713A0029 for ; Thu, 25 Jun 2020 22:54:02 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id A356894A for ; Fri, 26 Jun 2020 01:54:01 -0400 (EDT)
Received: from imap28 ([10.202.2.78]) by compute4.internal (MEProxy); Fri, 26 Jun 2020 01:54:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=cTVMx4h Vg38UdKd2K9uIyw4mcWfh3TQpo6CXo2D/7WY=; b=KSHq//xDg7/qkz0Ae0z2fnk RlAX+m9pvUC9P6tTJkmLPrpaGVK8CLMPl1ZnhgO8db/NwfaQZ4KxPy1qur0NxHG+ P9ew6KGKB35+pFTBiBGiBZT0cpQShi9HZqurDBLOLTY+WzQHz4ZFXCGXLZ4HjQGc TEjeCj0VlyWrVDvpTEZ6LvC2jKECKkt1VLlyXQWzg5cnPHyU2nkXxZkF+79YgEKH adTot6+ZPXLkwW9i9cjHpigrWupEseZpFPsOyvRWuebE0r/sIIoTUZNObnJtWDDv dJdaGzaaykWWlaIvBWW9nWhRmvj6tw8S+iPVymJb6FEPGoHtMcor2S4//DXsgNQ= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=cTVMx4 hVg38UdKd2K9uIyw4mcWfh3TQpo6CXo2D/7WY=; b=uMJvbouR9oH9/0V2YVXejK GcqeroXIIHFZqQEda8Jnm+RXdcB1HE7JR4jCuRogrY56kqVwIpNsGu0sgYbnJMc5 u7BEX9jDSPds+SMh2Hsha+8XBMPsFFg7rmGZ1Gr243uULwORMLxizRIP9oaH3p81 JOpl8Vv6bKkfLn/8GgJa4oG8zkUWgzj4BuAovL+7TeecUKODPBDZoj3puMbUQqOi 18OSuo0eHrQhS71fJK3I24lH2i1jh/km1OEhHxdrei1Jn7YGR1i9NAhyb43LTkts pSiyIGX90QQFAq2L3cx6tiBEP3+uQ7TGFfN5BQV4TlZZwE+lRVE1fRrD7Qjioj9g ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeltddgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeffgfejtdeuvdevtdetkeejjefhieekueejleehgfdutddu heektdffffevlefgvdenucffohhmrghinhepjhhmrghprdhiohenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghi lhhtvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D2A7624009E; Fri, 26 Jun 2020 01:54:00 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000
Mime-Version: 1.0
Message-Id: <28189879-e304-49f4-8876-4f46b2af7351@beta.fastmail.com>
In-Reply-To: <20200625090336.GA32628@dcvr>
References: <20200625090336.GA32628@dcvr>
Date: Fri, 26 Jun 2020 15:53:53 +1000
From: "Neil Jenkins" 
To: "IETF JMAP Mailing List" 
Content-Type: multipart/alternative; boundary=f77c14735b6c4eb9a84f251bdf83396a
Archived-At: 
Subject: Re: [Jmap] recommendations for gigantic mailboxes
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, 26 Jun 2020 05:54:05 -0000

--f77c14735b6c4eb9a84f251bdf83396a
Content-Type: text/plain

On Thu, 25 Jun 2020, at 19:03, Eric Wong wrote:
> TL;DR: would it be reasonable to expose 10 million messages in a
> single JMAP mailbox?

Yes, I don't see why not.

> So, JMAP is fresh ground; so I wonder if having a single mailbox
> on the order of 10 million messages is reasonable for JMAP clients.

I mean, this is really down to implementation. There's nothing in the protocol that makes this particularly problematic, but if it's trying to save every message locally then it could run into trouble depending on its choice of on-disk format. But JMAP makes it easy to page in just the portion of the mailbox you are currently interested in viewing, so as long as the client is working in this mode it should be fine.

As JMAP is very new, there are not many clients to test against yet to see how they work with such a large volume. You can point the demo webmail  client at a server to test with; I've tried it with the order of ~1 million messages but not with ~10 million. This is not caching anything locally other than temporarily for performance reasons, which is a good model for accessing this kind of data.

Neil.
--f77c14735b6c4eb9a84f251bdf83396a
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


On Thu, 25 Jun =
2020, at 19:03, Eric Wong wrote:
TL;DR: would it be reasonable to expose 10 million =
messages in a
single JMAP mailbox?
<=
div>
Yes, I don't see why not.

So, JMAP is fresh groun=
d; so I wonder if having a single mailbox
on the order of =
10 million messages is reasonable for JMAP clients.

I mean, this is really down to implementation. The=
re's nothing in the protocol that makes this particularly problematic, b=
ut if it's trying to save every message locally then it could run into t=
rouble depending on its choice of on-disk format. But JMAP makes it easy=
 to page in just the portion of the mailbox you are currently interested=
 in viewing, so as long as the client is working in this mode it should =
be fine.

As JMAP is very new, there are not=
 many clients to test against yet to see how they work with such a large=
 volume. You can point the demo webmail client at a server to test with; I've tried it with t=
he order of ~1 million messages but not with ~10 million. This is not ca=
ching anything locally other than temporarily for performance reasons, w=
hich is a good model for accessing this kind of data.

=

Neil.

--f77c14735b6c4eb9a84f251bdf83396a--


From nobody Fri Jun 26 03:55:00 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 15E093A1166 for ; Fri, 26 Jun 2020 03:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=nNCCubPT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PyoJc1uU
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 kKGBoK4nk1hd for ; Fri, 26 Jun 2020 03:54:57 -0700 (PDT)
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 CF84B3A103F for ; Fri, 26 Jun 2020 03:54:57 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1359D828 for ; Fri, 26 Jun 2020 06:54:57 -0400 (EDT)
Received: from imap28 ([10.202.2.78]) by compute1.internal (MEProxy); Fri, 26 Jun 2020 06:54:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=b0kmUD7 aOVkvvhdRACgzRx+PVAgynPB7rp78/VfjSww=; b=nNCCubPTYesJIpGgNgZO5j/ N3i+lEQXRlA3N5xdLHCQ+brknXVDW4qWQm3W8yDNpPZMcXJSvu74V8PTZmjfgJK6 gNfslqObLYFsXQBiWUKy+XGGh6bDuhPmhr4gYvv2hjbVLdGj2NtFSW1/vjS2ldVQ OqCryRldjhYKo/gbgo2CAqpeZT5VQwx8ISRiG46BW3lbsYUpZq05LV15fU7jZGYx skQ38M7k8hw03FRfb7ltFgZLXVnfnrLX5wcP9KrgURO6DXvH8dTUsfyR1jcz6THO nT1xQGoXKtxbP5bsJc7BaD9+eQ3gx3zFwpA6x0uNCFVLDcTyBbWaeup/yGA4cgg= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=b0kmUD 7aOVkvvhdRACgzRx+PVAgynPB7rp78/VfjSww=; b=PyoJc1uUHTo8zbZ57RMHWw XPKjyLfQRoRgl7PpdQeKPR3IhtsNIS6w7yxBwebTZx6B3/pqA73EuHJnP7zybL/e ft57649++CqFStNmRw53pxPj0IiJwddiFRY7/S2h5g5sZYV0a+vog4BRQh2aNcbB zTgwRTtv4BsydIk9uyBchKLIJ5sei8J5Sl+dKcGyPH2EUXTo+Ynf6fOV1DwXH1aw JvmqJVnt6GrGeHSFL46TnRCu0pehqBj/VqUuw2IGIEGKOUdel87ChwZHGce0lO/b mi3Ji7URhtFaMY9xUd9XxOiEj124HrRlBmROpTF10ciuKFkAClPaIm3gf9/gyKJw ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeluddgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvudeuieehgf dvheeuueejjeeuudfgiefgveetfeelteeffffgtdejjefgueduvdenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4AE1A24009E; Fri, 26 Jun 2020 06:54:56 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <28189879-e304-49f4-8876-4f46b2af7351@beta.fastmail.com>
References: <20200625090336.GA32628@dcvr> <28189879-e304-49f4-8876-4f46b2af7351@beta.fastmail.com>
Date: Fri, 26 Jun 2020 20:54:35 +1000
From: "Bron Gondwana" 
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=28043fd996774bccb7728ada23a59f14
Archived-At: 
Subject: Re: [Jmap] recommendations for gigantic mailboxes
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, 26 Jun 2020 10:54:59 -0000

--28043fd996774bccb7728ada23a59f14
Content-Type: text/plain

On Fri, Jun 26, 2020, at 15:53, Neil Jenkins wrote:
> On Thu, 25 Jun 2020, at 19:03, Eric Wong wrote:
>> TL;DR: would it be reasonable to expose 10 million messages in a
>> single JMAP mailbox?
> 
> Yes, I don't see why not.
> 
>> So, JMAP is fresh ground; so I wonder if having a single mailbox
>> on the order of 10 million messages is reasonable for JMAP clients.
> 
> I mean, this is really down to implementation. There's nothing in the protocol that makes this particularly problematic, but if it's trying to save every message locally then it could run into trouble depending on its choice of on-disk format. But JMAP makes it easy to page in just the portion of the mailbox you are currently interested in viewing, so as long as the client is working in this mode it should be fine.

Yeah, as Neil says - the protocol itself is going to be totally fine. The big issue for you is going to be your data model, particularly if you're trying to do Email/query and Email/queryChanges efficiently.

Overall, it's going to be nicer than IMAP because you don't have to do as much unsolicited work - if the client wants something it will ask for it, and if it doesn't ask, you don't need to create it.

Cheers,

Bron.

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


--28043fd996774bccb7728ada23a59f14
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


On Fri, Jun 26, 2020, at 15:53, Neil Jenkins wrote:
On Thu, 25 J=
un 2020, at 19:03, Eric Wong wrote:
TL;DR: would it be reasonable to expose 10 m=
illion messages in a
single JMAP mailbox?

Yes, I don't see why not.

So, JMAP is f=
resh ground; so I wonder if having a single mailbox
on the=
 order of 10 million messages is reasonable for JMAP clients.
<=
/blockquote>

I mean, this is really down to implement=
ation. There's nothing in the protocol that makes this particularly prob=
lematic, but if it's trying to save every message locally then it could =
run into trouble depending on its choice of on-disk format. But JMAP mak=
es it easy to page in just the portion of the mailbox you are currently =
interested in viewing, so as long as the client is working in this mode =
it should be fine.

Yeah, as Neil says - the =
protocol itself is going to be totally fine.  The big issue for you=
 is going to be your data model, particularly if you're trying to do Ema=
il/query and Email/queryChanges efficiently.

Overall, it'=
s going to be nicer than IMAP because you don't have to do as much unsol=
icited work - if the client wants something it will ask for it, and if i=
t doesn't ask, you don't need to create it.

Cheers,

Bron.

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



--28043fd996774bccb7728ada23a59f14--


From nobody Fri Jun 26 04:57: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 DA2923A095B for ; Fri, 26 Jun 2020 04:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 iPmZPHdrnVBg for ; Fri, 26 Jun 2020 04:57:54 -0700 (PDT)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D463A093E for ; Fri, 26 Jun 2020 04:57:54 -0700 (PDT)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 6675EC0130; Fri, 26 Jun 2020 13:03:20 +0100 (IST)
Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no
Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1593173000; bh=0dDTb54jHv6ArYo+RROufKipmCzQVfm01GSKsVhzULQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ha5RshtEywZfqQeTZ0GZI/By5432uIJrb4XT+UREV0v1foyvNQrZ00CDHWLHYnrut YjoTCGqWMj/6/QuaesXtr5vOOB6hFSJ92J/rTNseZjXyuEadvjv/7ONorbOoyI9jk/ RtB9KAu9owErgoaiteCEwPUbwt9fcigNR0+kjBhM=
Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1593172999-9695-9692/9/77; Fri, 26 Jun 2020 12:03:19 +0000
From: Arnt Gulbrandsen 
To: jmap@ietf.org
Date: Fri, 26 Jun 2020 13:57:50 +0200
Mime-Version: 1.0
Message-Id: <2119e568-665e-4804-aa75-527a4020ff62@gulbrandsen.priv.no>
In-Reply-To: 
References: <20200625090336.GA32628@dcvr> <28189879-e304-49f4-8876-4f46b2af7351@beta.fastmail.com> 
User-Agent: Trojita/0.7; Qt/5.7.1; xcb; Linux; Devuan GNU/Linux 2.1 (ascii)
Content-Type: text/plain; charset=utf-8; format=flowed
Archived-At: 
Subject: Re: [Jmap] recommendations for gigantic mailboxes
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, 26 Jun 2020 11:57:56 -0000

On Friday 26 June 2020 12:54:35 CEST, Bron Gondwana wrote:
> Overall, it's going to be nicer than IMAP because you don't 
> have to do as much unsolicited work - if the client wants 
> something it will ask for it, and if it doesn't ask, you don't 
> need to create it.

Having a publicly available four-million-message mailbox will be nice for 
JMAP, too. So many IMAP clients fail miserably when they come up against 
million-message gmail accounts. Neil, Bron, I do hope you'll add a 
suggestion to test new clients against public-inbox if/when.

Arnt


From nobody Fri Jun 26 09:32:40 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 BC18E3A0A73 for ; Fri, 26 Jun 2020 09:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS7ZJxGd16ZR for ; Fri, 26 Jun 2020 09:32:36 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id CE0583A0A66 for ; Fri, 26 Jun 2020 09:32:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1593189155; d=isode.com; s=june2016; i=@isode.com; bh=3AfO7EA1/A1x11ZhEXD6XUq1j2cDH9bfXGfFXuMBV50=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=tp/TYqj1gMnPfXFwbbnMtz40uN5T1039sgH5/JSUOVQEMHmb+U7Z4ee9X6nbAV1YB/blf6 IeI/8jC29KLSVPSoyoYG8X23pl8VDnWCj+EKTc4uNxA7NfMJGFEp7nk+f6Tu1Yst/2zaCw Zrjuu0xk64H43LczjNZFYF3GJuhgtDQ=;
Received: from [172.27.252.104] (connect.isode.net [172.20.0.72])  by statler.isode.com (submission channel) via TCP with ESMTPSA  id ; Fri, 26 Jun 2020 17:32:35 +0100
To: Bron Gondwana , jmap@ietf.org
References: 
From: Alexey Melnikov 
Message-ID: 
Date: Fri, 26 Jun 2020 17:32:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------336BEA6E5CE1F58E0DB1EC80"
Content-Language: en-GB
Archived-At: 
Subject: Re: [Jmap] Call for adoption for document defining mappings between VCARD and JSContact
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, 26 Jun 2020 16:32:39 -0000

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

Hi,

On 24/06/2020 07:04, Bron Gondwana wrote:
> As discussed in the interim last week, this is a formal call for 
> adoption of:
>
> https://datatracker.ietf.org/doc/draft-loffredo-jmap-jscontact-vcard/
>
> This document is designed as a companion for our existing document:
>
> https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/
>
> Since this one is so simple, and was mentioned in the minutes of the 
> last call already, I'm just going to give one week on this - so please 
> reply by July 1st if you have any objections to us taking on this 
> document (with the understanding that it's still a work in progress).

I had a quick scan of the document and I agree that it should be adopted 
by JMAP WG.

Best Regards,

Alexey


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


  
    
  
  
    
Hi,

    

    
On 24/06/2020 07:04, Bron Gondwana
      wrote:

    

    

      
      
      
      
As discussed in the interim last
        week, this is a formal call for adoption of:

      

      


      

      
      


      

      
This document is designed as a
        companion for our existing document:

      

      


      

      
      


      

      
Since this one is so simple, and
        was mentioned in the minutes of the last call already, I'm just
        going to give one week on this - so please reply by July 1st if
        you have any objections to us taking on this document (with the
        understanding that it's still a work in progress).

      

    

    
I had a quick scan of the document and I agree that it should be
      adopted by JMAP WG.

    
Best Regards,

    
Alexey

    

    

    

  


--------------336BEA6E5CE1F58E0DB1EC80--