From nobody Sun Dec 3 10:15:11 2017 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 AB54F124D85 for ; Sun, 3 Dec 2017 10:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=AdjXCRkI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HvKOEFBO 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 d-5QdSrLd10i for ; Sun, 3 Dec 2017 10:15:08 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C885126DCA for ; Sun, 3 Dec 2017 10:15:08 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4DA9E20940; Sun, 3 Dec 2017 13:15:07 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Sun, 03 Dec 2017 13:15:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8oWPlUrSF6MTfpuEN 1QRRYQs+Wo0uuPdAnS15bh4dJ0=; b=AdjXCRkIf7z0ln3ja2hKGbiwtNNnbsYNb qoBQ1skyf9xNV/SCME8lxuDsg5De5gYWoqAcYZYnTToPHyxs08FZrZ1x63bHbK7v hzRPu/MclKqY1kbpBg4DyT15fmmD4peE1XiIvHg90qVE5vrS7IwHjxASFTefmf/t hK2QSbPz3U8DOs72Gc4M7Jj+COqgbYXtvY7vJbxaGyhrZfxEuMfcE2v8k0YzXGDa dVSbg8Vvo08XiPOZJv92KUGp+lLenL0jzcSDvDnTOHW1mUqvUgXOKMMKuZ/dekK/ oVCt0ZBm+PfOWEsj9KKCF25499oRXuzfCO884VUXtAVBJn2Gb2Lbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8oWPlU rSF6MTfpuEN1QRRYQs+Wo0uuPdAnS15bh4dJ0=; b=HvKOEFBOlumHq/EXv69RMk 9aYbb+igw52Y/tZsWYMAYwv1SmRWLJL5XuhGtRqY9vL5TmkTJTL43tzfXlCjQ83q 2y9KWJkpOviuoHQcVO6tRuuHzSMN1gghq+bFqfWk1MLoQs/JkYNsakWij0YIhSaM LeVezXUtFihQ9okAJQjxS/8z2DVt7kMPOJhYhKjCSJ6gYbbnIhC9uhhiGTz5xi+z XMotCn9Ivk/7xiSCHdNTnACOqg8A4udEbcMoIhy2nqJG+luTyV7OqacyN8nUKxLL vg7HfPDyeUf6Pk4mvhMCVw56hQveoaMH7eKg1zmzQ9L9/k1xptT1W0JDbEbjfRQw == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id CF9477E6B8; Sun, 3 Dec 2017 13:15:06 -0500 (EST) References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> <20171128135837.GB2390@meili> <1511925847.2214786.1187644272.47957DBF@webmail.messagingengine.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1511925847.2214786.1187644272.47957DBF@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary=Apple-Mail-F31EDB79-027A-4F0A-9676-20E51E6F2BCB Content-Transfer-Encoding: 7bit Message-Id: <8535394E-075E-4F83-8166-7ACB472860B8@glyphein.mailforce.net> Cc: Josef Jeff Sipek , Bron Gondwana , IETF JMAP Mailing List X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Sun, 3 Dec 2017 13:15:03 -0500 To: Neil Jenkins Archived-At: Subject: Re: [Jmap] Call for objections - standardising on plural names everywhere X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 18:15:10 -0000 --Apple-Mail-F31EDB79-027A-4F0A-9676-20E51E6F2BCB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Nov 28, 2017, at 10:24 PM, Neil Jenkins wrote:= >=20 > For completeness, copying to the list another suggestion from the GitHub t= icket: >=20 > Mailbox.get > Mailbox.getUpdates > Mailbox.getList > Mailbox.getListUpdates > Mailbox.set >=20 > (You could also replace the "." with a slash, e.g. "Mailbox/get", which I t= hink I slightly prefer for readability.) I like this. I think the hierarchical nature of the syntax actually makes t= he plural now more desirable than the singular and walks the reader of the s= pec through the idea that each of these actions is to be applied to multiple= items, which of course is what you wanted in the first place. > Not sure what response names you would use with this. I'm not entirely sure at the moment, either, but ideally something else nice= and hierarchical. >> I, too, find it less awkward without the double-plural, but sticking with= >> only singular or only plural is still a vast improvement. >=20 > I'm not overly concerned which one we pick. If there's a general preferenc= e for singular over plural, I'm happy to go with that. The main thing is it'= s consistent. Yes. Thanks, Stan > The reason I picked plural is because the methods all operate on multiple i= tems at once, but I agree it is slightly more awkward when combined with oth= er plural words. >=20 > Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --Apple-Mail-F31EDB79-027A-4F0A-9676-20E51E6F2BCB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On Nov 28, 2017, at 10:24 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:

For completeness, copying to the list another suggestion from the GitHub ticket:

Mailbox.get
Mailbox.getUpdates
Mailbox.getList
Mailbox.getListUpdates
Mailbox.set

(You could also replace the "." with a slash, e.g. "Mailbox/get", which I think I slightly prefer for readability.)

I like this.  I think the hierarchical nature of the syntax actually makes the plural now more desirable than the singular and walks the reader of the spec through the idea that each of these actions is to be applied to multiple items, which of course is what you wanted in the first place.

Not sure what response names you would use with this.

I'm not entirely sure at the moment, either, but ideally something else nice and hierarchical.

I, too, find it less awkward without the double-plural, but sticking with
only singular or only plural is still a vast improvement.

I'm not overly concerned which one we pick. If there's a general preference for singular over plural, I'm happy to go with that. The main thing is it's consistent.

Yes.


Thanks,
Stan

The reason I picked plural is because the methods all operate on multiple items at once, but I agree it is slightly more awkward when combined with other plural words.

Neil.
_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--Apple-Mail-F31EDB79-027A-4F0A-9676-20E51E6F2BCB-- From nobody Sun Dec 3 10:25:27 2017 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 0368F1270A3 for ; Sun, 3 Dec 2017 10:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=lFmtWqC0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kyj664Za 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 82bCs3vNyN1Y for ; Sun, 3 Dec 2017 10:25:24 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12548127077 for ; Sun, 3 Dec 2017 10:25:24 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 79FB9209B1 for ; Sun, 3 Dec 2017 13:25:23 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Sun, 03 Dec 2017 13:25:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=EKNJqX725DBInCqk8SNOlpwngutYP 7ucq+UB+G1lWFE=; b=lFmtWqC0lK3kzSzqRQLL8VyVXz9zPzY8wHuFPlz5apWRY BV+w6oPfiRipcSeLO0gnfE3H4l5DRAT6HwpMtCokgEVMFYtZIkq9MI4BTCdrmKtP x9gICuHWz99yRomRv1IMZouV5+HNZOEluaFnEGTZW4DM5GY+TmyOpoQXfDC6Ta9Q oHDOT48JKQ1nWrsTLezfjlQsSY/qL1fZJXIdkRcE3DHMEV+hQPaTfTTK5KGBTBH9 OVHFnZjNiFQb+Dpl6lCkLdqL9BeuoxC/YDqIHqvaYJk6trqtfeZS/r8WN7+mwebf r2Q4u6DKOmxwVgezxVCOVgMPWPt14+tX4IYyC/Cdw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=EKNJqX 725DBInCqk8SNOlpwngutYP7ucq+UB+G1lWFE=; b=kyj664ZaUO8zamaMG2aYSZ s8AD0JapUZjiZobhHD8dkrM9IAZTGBwEyBJ2kZNF+55mtcBBjx6PCAH9AqwrooS6 5Pp6Lz/cVYaPmHEKiEtLEs6MbD9HD8PF9mikvEv2WrO3QWKRtwzbURZa44LFiWj3 rPZrq0ECfQZvdUiyTb0+K9s/a/pR+hKzimLpwW/0AN0K9CK2LoUVT6kyX0yLpIa1 5mz8xErZRx6/OizIPnjhgG+b4jJGpPT3dro9bv7Bq6cXocgzGGoGmZPSmnrQ4QG+ 2ejxqdH0kg86SXGCDfmxawS6rDpJEabr04G9yfXm1ziurA1GSVixjNwYk5bl6VbA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4E0E09E1F1; Sun, 3 Dec 2017 13:25:23 -0500 (EST) Message-Id: <1512325523.1708452.1192487368.4835BE41@webmail.messagingengine.com> From: Ken Murchison To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151232552317084520" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a169161c References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> <20171128135837.GB2390@meili> <1511925847.2214786.1187644272.47957DBF@webmail.messagingengine.com> <8535394E-075E-4F83-8166-7ACB472860B8@glyphein.mailforce.net> In-Reply-To: <8535394E-075E-4F83-8166-7ACB472860B8@glyphein.mailforce.net> Date: Sun, 03 Dec 2017 13:25:23 -0500 Archived-At: Subject: Re: [Jmap] Call for objections - standardising on plural names everywhere X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 18:25:26 -0000 This is a multi-part message in MIME format. --_----------=_151232552317084520 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I=E2=80=99m fine with plural. It=E2=80=99s just syntactic sugar anyways.=20 -- Kenneth Murchison Cyrus Development Team murch@fastmail.com On Sun, Dec 3, 2017, at 01:15 PM, Stan Kalisch wrote: >=20 > On Nov 28, 2017, at 10:24 PM, Neil Jenkins > wrote:>> For completeness, copying to the list a= nother suggestion from the >> GitHub ticket[1]:>>=20 >> Mailbox.get >> Mailbox.getUpdates >> Mailbox.getList >> Mailbox.getListUpdates >> Mailbox.set >>=20 >> (You could also replace the "." with a slash, e.g. "Mailbox/get", >> which I think I slightly prefer for readability.)>=20 > I like this. I think the hierarchical nature of the syntax actually > makes the plural now more desirable than the singular and walks the > reader of the spec through the idea that each of these actions is to > be applied to multiple items, which of course is what you wanted in > the first place.>=20 >> Not sure what response names you would use with this. >=20 > I'm not entirely sure at the moment, either, but ideally something > else nice and hierarchical.>=20 >>> I, too, find it less awkward without the double-plural, but >>> sticking with>>> only singular or only plural is still a vast improveme= nt. >>=20 >> I'm not overly concerned which one we pick. If there's a general >> preference for singular over plural, I'm happy to go with that. The >> main thing is it's consistent.>=20 > Yes. >=20 >=20 > Thanks, > Stan >=20 >> The reason I picked plural is because the methods all operate on >> multiple items at once, but I agree it is slightly more awkward when >> combined with other plural words.>>=20 >> Neil. >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap Links: 1. https://github.com/jmapio/jmap/issues/164 --_----------=_151232552317084520 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
I=E2=80=99m fine with plural. It=E2=80=99s just syntactic sugar = anyways. 

--
  Kenneth Murchison
  Cyrus Development Team
  murch@fastmail.com



On Sun, Dec 3, 2017, at 01:15 PM, Stan Kalisch wrote:

On Nov 28, 2017, at 10:24 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:
For completeness, copying to the list a= nother suggestion from the GitHub ticket:

Mailbox.get
Mailbox.getUpdates
Mailbox.getList
Mailbox.getListUpdates
Mailbox.set

(You could also replace the "." with a slash, e.g. "Mailbox/get", whic= h I think I slightly prefer for readability.)

I like this.  I think the hierarchical nature of the syntax actua= lly makes the plural now more desirable than the singular and walks the rea= der of the spec through the idea that each of these actions is to be applie= d to multiple items, which of course is what you wanted in the first place.=

Not sure what response names you would = use with this.

I'm not entirely sure at the moment, either, but ideally something els= e nice and hierarchical.

I, too, find = it less awkward without the double-plural, but sticking with
only singular or only plural is still a vast improvement.

I'm not overly concerned which one we pick. If there's a general prefe= rence for singular over plural, I'm happy to go with that. The main thing i= s it's consistent.

Yes.


Thanks,
Stan

The reason I picked plural is beca= use the methods all operate on multiple items at once, but I agree it is sl= ightly more awkward when combined with other plural words.

Neil.
____________________= ___________________________
Jmap mailing list
_______________________________________________
Jmap mailing list

--_----------=_151232552317084520-- From nobody Mon Dec 4 21:35:57 2017 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 EDD74124234 for ; Mon, 4 Dec 2017 21:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=oracle.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 6RBHLUNVwqoa for ; Mon, 4 Dec 2017 21:35:54 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 1C0FC124B18 for ; Mon, 4 Dec 2017 21:35:54 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vB55WKfS124437; Tue, 5 Dec 2017 05:35:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2017-10-26; bh=w7M9y3MGeZt/AAG4bft2QHLW578PPRaz7qX6qOeXHpo=; b=QBEV3gYjjfzquS5iQ/HbhuWxT5PNMXLPWcwRH65SCQi11oRrKzhZavZNQBIErs0A+glO N7RM2hrzwsA+G0iKSJolfyuUnKBP6qQMxhPi5b/+rH5Ijx9al+xnSVDOJaE184uuigU6 3lAMRHTf0d8dAUA32CzQyYLcSEDyIj2K4c/3HAlZ6Yy8+ga8YhCtlgKCeTZCXSNb1+K8 VZ8fA0kNcDqcrZRSB/XWykdMM0eVmirgI45ZT+Hw0wxsCdol2RqFrKPZ0XI9MPeSYilC wNX4sFKUSwQpXRul4tHPlTTKhPwOuKwoI+zMVMEGiWjcJ72T6HayZVneGnCUlCCAjhRd Ng== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2en9pgssqu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Dec 2017 05:35:49 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vB55ZmWC003407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 5 Dec 2017 05:35:48 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vB55ZmiQ020976; Tue, 5 Dec 2017 05:35:48 GMT Received: from [10.159.224.239] (/10.159.224.239) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Dec 2017 21:35:47 -0800 From: "Chris Newman" To: "Neil Jenkins" Cc: "IETF JMAP Mailing List" Date: Mon, 04 Dec 2017 21:35:43 -0800 Message-ID: In-Reply-To: <1512001201.3289077.1188813640.53BFE5FE@webmail.messagingengine.com> References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <01CCF1A2-A709-412C-90F7-6DAC3A71AD39@oracle.com> <1505698131.2041914.1109222872.6A22DCE0@webmail.messagingengine.com> <49FEE67A-747A-447B-840C-675E2EE23101@fugue.com> <1512001201.3289077.1188813640.53BFE5FE@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_233FBA10-CEF7-4C52-9E7D-19944203555C_=" Embedded-HTML: [{"HTML":[1408, 1279], "plain":[75, 1050], "uuid":"C845342B-F38E-484B-8B42-0FB410C86067"}] X-Mailer: MailMate (1.9.7r5425) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8735 signatures=668637 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712050083 Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 05:35:56 -0000 --=_MailMate_233FBA10-CEF7-4C52-9E7D-19944203555C_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable Works for me. - Chris On 29 Nov 2017, at 16:20, Neil Jenkins wrote: > There was a bit more discussion of this at IETF100, and I think the > consensus was the current proposed solution was a bit of overkill. = > I've > revised the pull request so there's now a simpler > onDestroyRemoveMessages: Boolean (default: false) argument to > setMailboxes. If not set, or set explicitly to false, you get an error > if you try to destroy a mailbox that has messages in it. If it's set = > to > true, you get IMAP-like behaviour: messages are automatically removed > from it and destroyed if in no other mailbox. > If the client wants to do something else, it can explicitly fetch the > messages and move them wherever it wants before destroying the = > mailbox. > You can see the diff here[1]. How does this look to people? > > Neil. > > Links: > > 1. = > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_jmapi= o_jmap_pull_145_files&d=3DDwICaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e= apI_JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DgT_sdlwR-21IB= l4Pxzj2_ZCdxrCtS7ESNcEkgbc0zHE&s=3D67XY_HF3ESDTAi6n9Bf_GU6QiRgTye29_RDNre= LARps&e=3D > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_jmap&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3DK_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DgT_sdlwR-21IBl4P= xzj2_ZCdxrCtS7ESNcEkgbc0zHE&s=3DftzMK9B95TruHTTY-GA1Vq7mBHiSqdX-3hMOcud19= x0&e=3D --=_MailMate_233FBA10-CEF7-4C52-9E7D-19944203555C_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Works for me.

- Chris

On 29 Nov 2017, at 16:20, Neil Jenkins wrote:

There was a bit more discussion of this at IETF100, and I think the = consensus was the current proposed solution was a bit of overkill. I've r= evised the pull request so there's now a simpler onDestroyRemo= veMessages: Boolean (default: false) argument to setMailboxes. If = not set, or set explicitly to false, you get an error if you try to destr= oy a mailbox that has messages in it. If it's set to true, you get IMAP-l= ike behaviour: messages are automatically removed from it and destroyed i= f in no other mailbox.

If the client wants to do something else, it can explicitly fetch th= e messages and move them wherever it wants before destroying the mailbox.=

You can see the diff here. How does this lo= ok to people?

Neil.

________________________________= _______________
Jmap mailing list
Jmap@ietf.org
https://urldefense.proofpoint.c= om/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_jmap&d=3DDwICAg= &c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3DK_BObr5Kfkr3= rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=3DgT_sdlwR-21IBl4Pxzj2_ZCdxrCtS7ESN= cEkgbc0zHE&s=3DftzMK9B95TruHTTY-GA1Vq7mBHiSqdX-3hMOcud19x0&e=3D

--=_MailMate_233FBA10-CEF7-4C52-9E7D-19944203555C_=-- From nobody Wed Dec 6 21:42:22 2017 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 41124126FB3 for ; Wed, 6 Dec 2017 21:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=BQHvVdTu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d2R7PKzd 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 kdZ8mKHZwV6h for ; Wed, 6 Dec 2017 21:42:19 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10A4124D85 for ; Wed, 6 Dec 2017 21:42:18 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 37D13219F4 for ; Thu, 7 Dec 2017 00:42:18 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 07 Dec 2017 00:42:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=/FtNgpjCxdi6K4yYS JPbMSuKBxSeAIp0yIo32SU9uQY=; b=BQHvVdTuNhJ/nRak8bY1t+zElz0SqxX1Z kUz9Whho/HhVCkv+x5fAy2Q4O9Nt7IdpeBWv1+fnNtj1ZpNIM5usPgw56BxgKhzp K0mlolxUu1wQ0fZ7UaH7lAfoTSwkzwmi2zBvRujn+f7dHk6KgoaQfr4Gl1Jz3EaQ w4t3fOjTDJpIG2FfBcG/3Jl/7IDY6jYyYyvBe0j9jBgi5GxGmaSojlN6T4BMF4m6 8VjVP1OGJFx05EC4fy2qWa8Y6wsusUYpfKdKK6uj25yvCfj3UcAzA8rv15ZMG+FA bDzClN8xB4DDxeV3Uqjq/inAPM/9FcEYLsnEhERTj2Rp6JPaD77cQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=/FtNgp jCxdi6K4yYSJPbMSuKBxSeAIp0yIo32SU9uQY=; b=d2R7PKzdasAFtNi0AXyBlS 6NV5KAi4HGIX1vcte3quaOMU89BgVvbBmC3AHa7Gnbr0x1TYa8kT3iBY+2R4EEef LYGREpvo/xCkh3lKCLDMHATYjQBu/41xrl6GOM190oSv3l/WelQ/vwIgZiuTTU97 XWfIZglRGTocQSkuDjQczARisbIRWX459stqhYtfZeuAUhMerC2f6OplbS9pNILv cecAIF4wYwEVku8uAw6qZGy0AHZ1+6+Ct6I2fZCjsgk4sSfruqW4AtfMZSQPDA5g ONOJzwLevg3LkaPZEuro5T6tWZh5xNzMh2Cz9KH5jG4H4vmWmTCTpyH0uxjgz1bA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D39F0E25FF; Thu, 7 Dec 2017 00:42:17 -0500 (EST) Message-Id: <1512625337.274010.1196837376.65DB99C6@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15126253372740100" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c2671619 References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> <20171128135837.GB2390@meili> <1511925847.2214786.1187644272.47957DBF@webmail.messagingengine.com> <8535394E-075E-4F83-8166-7ACB472860B8@glyphein.mailforce.net> <1512325523.1708452.1192487368.4835BE41@webmail.messagingengine.com> In-Reply-To: <1512325523.1708452.1192487368.4835BE41@webmail.messagingengine.com> Date: Thu, 07 Dec 2017 16:42:17 +1100 Archived-At: Subject: Re: [Jmap] Call for objections - standardising on plural names everywhere X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 05:42:21 -0000 This is a multi-part message in MIME format. --_----------=_15126253372740100 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" So, thinking and talking to people about this a bit more, I've decided that I prefer the following: getMailboxes -> Mailbox/get getMailboxUpdates -> Mailbox/changes getMailboxList -> Mailbox/query getMailboxListUpdates -> Mailbox/queryChanges setMailboxes -> Mailbox/set The response name is *the same* as the method call name. My reasoning: 1. Properties that reference other objects use the singular name (e.g. threadId property on an email). This makes no sense to be plural, so better to standardise absolutely everywhere on singular, as everyone agrees we should use just one or the other. 2. The (non-error) response name being the same as the method name simplifies the spec and means you don't need to know how to conjugate English verbs to derive the response names for methods. 3. The form is clear and easy to refer to standard types of method calls (e.g. a standard /get call). 4. I used "changes" instead of "updates" because it differentiates it from the crud (create, *update*, destroy) part of /set. 5. I used "query" instead of "list" because it's less ambiguous and a closer to match to what's happening. Example fetching from/date/subject for first 10 threads in Inbox (which also has Message renamed to Email as discussed before): [[ "Email/query", { "filter": { inMailbox: "id_of_inbox" }, "sort": [ "receivedAt desc" ], "collapseThreads": true, "position": 0, "limit": 10 }, "t0" ], [ "Email/get", { "#ids": { "resultOf": "t0", "name": "Email/query", "path": "/ids" }, "properties": [ "threadId" ] }, "t1" ], [ "Thread/get", { "#ids": { "resultOf": "t1", "name": "Email/get", "path": "/list/*/threadId" } }, "t2" ], [ "Email/get", { "#ids": { "resultOf": "t2", "name": "Thread/get", "path": "/list/*/emailIds" }, "properties": [ "from", "receivedAt", "subject" ] }, "t3" ]] with response: [[ "Email/query", { "accountId": "1", "filter": { inMailbox: "id_of_inbox" }, "sort": [ "receivedAt desc" ], "collapseThreads": true, "state": "abcdefg", "canCalculateChanges": true, "position": 0, "total": 101, "ids": [ "msg1023", "msg223", "msg110", "msg93", "msg91", "msg38", "msg36", "msg33", "msg11", "msg1" ] }, "t0" ], [ "Email/get", { "accountId": "1", "state": "123456", "list": [{ "id": "msg1023", "threadId": "trd194", }, { "id": "msg223", "threadId": "trd114" }, ... etc... ], "notFound": null }, "t1" ], [ "Thread/get", { "accountId": "1", "state": "123456", "list": [{ "id: "trd194", "emailIds": [ "msg1020", "msg1021", "msg1023" ] }, { "id: "trd114", "emailIds": [ "msg201", "msg223" ] }, ... etc... ], "notFound": null }, "t2" ], [ "Email/get", { "accountId": "1", "state": "123456", "list": [{ "id: "msg1020", "from": [{ "name": "Joe Bloggs", "email": "joe@example.com"}], "receivedAt": "2017-11-01T14:03= :01Z", "subject": "Let's talk JMAP" }, ... etc... ], "notFound": null }, "t3" ]] I have updated the pull request with the new form: https://github.com/jmapio/jmap/pull/166 =E2=80=93 I'll leave it a few days = just in case there are any final comments on this, then merge. Neil. --_----------=_15126253372740100 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
So, thinking and talking to people about this a bit more, I've d= ecided that I prefer the following:

getMailboxes          -> Mailbox/ge= t
getMailboxUpdates     -> Mailbox/changes
getMailboxList        -> Mailbox/query
getMailboxListUpdates -> Mailbox/queryChanges
setMailboxes          -> Mailbox/se= t

The response name is the same as the method call name.
=

My reasoning:
  1. Properties that reference other objects use the singular name (e.g.= threadId property on an email). This makes no sense to be plural, so bette= r to standardise absolutely everywhere on singular, as everyone agrees we s= hould use just one or the other.
  2. The (non-error) response name = being the same as the method name simplifies the spec and means you don't n= eed to know how to conjugate English verbs to derive the response names for= methods.
  3. The form is clear and easy to refer to standard types= of method calls (e.g. a standard /get call).
  4. I used "changes" = instead of "updates" because it differentiates it from the crud (create, update, destroy) part of /set.
  5. I used "query" instead of "= list" because it's less ambiguous and a closer to match to what's happening= .

Example fetching from/date/subject for first 10 threads in Inbox (whic= h also has Message renamed to Email as discussed before):

    [[ "Email/query", {
      "filter": { inMailbox: "id_of_in= box" },
      "sort": [ "receivedAt desc" ],
      "collapseThreads": true,<= br>
      "position": 0,
      "limit": 10
    }, "t0" ],
    [ "Email/get", {
      "#ids": {
        "resultOf": "t0",
        "name": "Email/query= ",
        "path": "/ids"
      },
      "properties": [ "threadId" ]
    }, "t1" ],
    [ "Thread/get", {
      "#ids": {
        "resultOf": "t1",
        "name": "Email/get",=
        "path": "/list/*/thr= eadId"
      }
    }, "t2" ],
    [ "Email/get", {
      "#ids": {
        "resultOf": "t2",
        "name": "Thread/get"= ,
        "path": "/list/*/ema= ilIds"
      },
      "properties": [ "from", "receive= dAt", "subject" ]
    }, "t3" ]]

with response:

    [[ "Email/query", {
        "accountId": "1",
        "filter": { inMailbo= x: "id_of_inbox" },
        "sort": [ "receivedA= t desc" ],
        "collapseThreads": t= rue,
        "state": "abcdefg",<= /span>
        "canCalculateChanges= ": true,
        "position": 0,
        "total": 101,=
        "ids": [ "msg1023", = "msg223", "msg110", "msg93", "msg91", "msg38", "msg36", "msg33", "msg11", "= msg1" ]
    }, "t0" ],
    [ "Email/get", {
        "accountId": "1",
        "state": "123456",
        "list": [{
          &nb= sp; "id": "msg1023",
          &nb= sp; "threadId": "trd194",
        }, {
          &nb= sp; "id": "msg223",
          &nb= sp; "threadId": "trd114"
        },
        ... etc...
        ],
        "notFound": null
    }, "t1" ],
    [ "Thread/get", {
        "accountId": "1",
        "state": "123456",
        "list": [{
          &nb= sp; "id: "trd194",
          &nb= sp; "emailIds": [ "msg1020", "msg1021", "msg1023" ]
        }, {
          &nb= sp; "id: "trd114",
          &nb= sp; "emailIds": [ "msg201", "msg223" ]
        },
        ... etc...
        ],
        "notFound": null
    }, "t2" ],
    [ "Email/get", {
        "accountId": "1",
        "state": "123456",
        "list": [{
          &nb= sp; "id: "msg1020",
          &nb= sp; "receivedAt": "2017-11-01T14:03:01Z",
          &nb= sp; "subject": "Let's talk JMAP"
        },
        ... etc...
        ],
        "notFound": null
    }, "t3" ]]


Neil.
--_----------=_15126253372740100-- From nobody Thu Dec 7 07:10:23 2017 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 7DD8B129464 for ; Thu, 7 Dec 2017 07:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Wx75nigEIJ8g for ; Thu, 7 Dec 2017 07:10:20 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3B91712945C for ; Thu, 7 Dec 2017 07:10:20 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id 35E962B3CD1; Thu, 7 Dec 2017 17:10:18 +0200 (EET) Date: Thu, 7 Dec 2017 10:10:16 -0500 From: Josef 'Jeff' Sipek To: Neil Jenkins Cc: IETF JMAP Mailing List Message-ID: <20171207151015.GG1632@meili> References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> <20171128135837.GB2390@meili> <1511925847.2214786.1187644272.47957DBF@webmail.messagingengine.com> <8535394E-075E-4F83-8166-7ACB472860B8@glyphein.mailforce.net> <1512325523.1708452.1192487368.4835BE41@webmail.messagingengine.com> <1512625337.274010.1196837376.65DB99C6@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1512625337.274010.1196837376.65DB99C6@webmail.messagingengine.com> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] Call for objections - standardising on plural names everywhere X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 15:10:21 -0000 On Thu, Dec 07, 2017 at 16:42:17 +1100, Neil Jenkins wrote: > So, thinking and talking to people about this a bit more, I've decided > that I prefer the following: > getMailboxes -> Mailbox/get > getMailboxUpdates -> Mailbox/changes > getMailboxList -> Mailbox/query > getMailboxListUpdates -> Mailbox/queryChanges > setMailboxes -> Mailbox/set > > The response name is *the same* as the method call name. > > My reasoning: > 1. Properties that reference other objects use the singular name (e.g. > threadId property on an email). This makes no sense to be plural, so > better to standardise absolutely everywhere on singular, as everyone > agrees we should use just one or the other. Good. > 2. The (non-error) response name being the same as the method name > simplifies the spec and means you don't need to know how to > conjugate English verbs to derive the response names for methods. Good. > 3. The form is clear and easy to refer to standard types of method > calls (e.g. a standard /get call). Good. > 4. I used "changes" instead of "updates" because it differentiates it > from the crud (create, *update*, destroy) part of /set. Fine by me. > 5. I used "query" instead of "list" because it's less ambiguous and a > closer to match to what's happening. Alright. I thought that list (with optional filter) was plenty clear. Would calling it "search" instead be even clearer? Jeff. -- A CRAY is the only computer that runs an endless loop in just 4 hours... From nobody Thu Dec 7 14:07:58 2017 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 1B5301294F4 for ; Thu, 7 Dec 2017 14:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 I5aTnSj9KM4R for ; Thu, 7 Dec 2017 14:07:35 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8755D1294FA for ; Thu, 7 Dec 2017 14:07:29 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id 549842A6900 for ; Fri, 8 Dec 2017 00:07:28 +0200 (EET) Date: Thu, 7 Dec 2017 17:07:27 -0500 From: Josef 'Jeff' Sipek To: jmap@ietf.org Message-ID: <20171207220727.GH1632@meili> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: [Jmap] back references X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 22:07:44 -0000 I had two thoughts related to back references. 1. As far as I can tell, the result of an action is always sent to the client. That is, the value is sent even if the client doesn't actually care about the value and only does the action to provide a value via a back reference. (This is different from IMAP's RETURN SAVE, which suppresses the transmission of the result to the client.) So, would it make sense to add a "suppress" field to the commands to avoid sending back data that is needed only for backrefs? 2. Currently, the use of a back reference is indicated by mangling the key name by prepending a '#'. If the value produced is always an array, couldn't we use the *type* of the field (instead of the name) to indicate that it is a back reference? E.g., [[ "getFooUpdates", { "sinceState": "abcdef" }, "t0" ], [ "getFoos", { "ids": { "resultOf": "t0", "name": "fooUpdates", "path": "/changed" } }, "t1" ]] Normally, "ids" is supposed to be an array of strings but here we are given an object. Therefore, we are dealing with a back reference. Compare that to this example, where the "id"'s value is an array and therefore not a back reference. [[ "getFooUpdates", { "sinceState": "abcdef" }, "t0" ], [ "getFoos", { "ids": [ "f1", "f4" ] }, "t1" ]] This would work for most fields - certainly for all id fields. The only place this breaks down is with "patch semantics" fields (e.g., keywords). With those, the value is supposed to be an object. Is there a real use case of using back references to fill keywords or other patch semantics fields? If not, should we change back reference indication from the '#' prefix to a value type check? Jeff. -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use a hammer. — IBM Manual, 1925 From nobody Thu Dec 7 14:32:14 2017 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 5298E12717E for ; Thu, 7 Dec 2017 14:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 sNgZlkZI2dfC for ; Thu, 7 Dec 2017 14:32:11 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8313C120227 for ; Thu, 7 Dec 2017 14:32:11 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id 4784D2A6900; Fri, 8 Dec 2017 00:32:10 +0200 (EET) Date: Thu, 7 Dec 2017 17:32:09 -0500 From: Josef 'Jeff' Sipek To: Neil Jenkins Cc: IETF JMAP Mailing List Message-ID: <20171207223209.GI1632@meili> References: <1511757555.96678.1185035608.5CC353FA@webmail.messagingengine.com> <20171128141105.GC2390@meili> <9ef19c08-d314-c22b-e628-d07936fa5d39@isode.com> <1511927937.2243688.1187666736.7A1F4129@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1511927937.2243688.1187666736.7A1F4129@webmail.messagingengine.com> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] Decoding of unknown headers X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 22:32:13 -0000 On Wed, Nov 29, 2017 at 14:58:57 +1100, Neil Jenkins wrote: > Some thoughts: > > We currently have the following properties which represent parsed forms > of headers: sender, from, to, cc, bcc, replyTo, subject, date. You can > also request (decoded but otherwise unparsed) headers using the > "headers" property. Perhaps what we should do is remove the special case > properties and instead have the client request header names + how to > process each one (raw base64, decoded, parsed as name/email list, parsed > as date; may be extensible in the future). The syntax would need to be > usable for setMessages too in some way. > The other thing to think about is what to do when you have multiple > headers of the same name; maybe you can explicitly request to receive > all (as an array), otherwise you get the last one of that name. I like this idea, but I'd say always return all. The extra two chars of JSON won't make much of a difference. > One possible syntax: > > "getMessages", { > ... > "properties": [ > "headers.received:decoded+all" > "headers.from:raw", > "headers.to:emails", > "headers.subject:decoded", > "headers.date:date" The only downside I can think of vs. the special cased properties is that the properties implied the correct decoding/parsing. For example, the "date" property was always decoded at a date but with the scheme this email proposes the client has to explicitly ask for :date format. I think it is still worth it to explore this header centric approach. (This gets us back on the message representation discussion.) > ], > } > > and then the Message object would look something like: > ... > > This gives a lot of flexibility to clients, but is a bit verbose. I don't think it is that bad. The client will likely always want to request the same headers with the same encoding, so it shouldn't increase code complexity in a significant way. The repeateded "type" and "value" strings shouldn't take up that much bandwidth. (And if bandwidth is really that tight that the repetition would matter, the HTTP server will compress the responses anyway.) ... > You could also default to type "decoded" if no other processing explicitly > requested, and possibly even drop the {type, value} wrapper for headers > with the default decoding. Defaulting to "decoded" sounds fine. One note about using "decoded" - it sounds a bit generic. Decoded *how*? I realize it is likely RFC 2047, but I'm not sure it is obvious from the proposed name. Would "text" make more sense? Since we are dealing with JSON, the encoding sent in the response has to be UTF8. What happens if the server cannot decode a header? (The Date or To header is malformed, or the header contains something that's a bad attempt at RFC 2047, and so on.) If the client requests decoding "X", what does the server have to do? MUST the server respond with "X"? Or MAY the server respond with "Y"? E.g., if I ask the server for headers.subject:date, can the server respond with a value as if I asked for headers.subject:text? Jeff. -- I'm somewhere between geek and normal. - Linus Torvalds From nobody Thu Dec 7 18:10:03 2017 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 0A259127698 for ; Thu, 7 Dec 2017 18:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=hIhiYQ0s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EiGcCWFF 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 43ma9O_KzE3b for ; Thu, 7 Dec 2017 18:10:00 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C431200F1 for ; Thu, 7 Dec 2017 18:10:00 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 82A1420BE7; Thu, 7 Dec 2017 21:09:59 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 07 Dec 2017 21:09:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=k1WF31 c0KxTnQzjlk8UMjIPrLmvq7UNNcLLs9an2kfQ=; b=hIhiYQ0s+eS7xvz+nIXZ9K whkXElq6TdtoOkPBJ7kUq43MsiVdusVlyV1tLiyc51hW0eW1ceyKkiy+FhaWqKgl H2Jpay/HZuO1c8+E8ttns0ovE/FoyXKEeBGXcQKyUbnRuZ8gdqvLdZhHoDXGme+1 RLOp3eTKYA1CcGi7yr4Ouc8rx2aP1qEX/ABZ8oicQl4d4UDwDEM4ppsK/eo3uUnn flDKe1aWcMW5Zf8pm5x+obQPbl4ZtQG01aavr6+uOxeEMlAxB1aIOIOAdgflTG4X zw6lPZnQHNPq/r49yluHtVIEkPH2RFzWuRsIvSXXCQV1e6qAw/jJs8tod/L6bCDA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=k1WF31 c0KxTnQzjlk8UMjIPrLmvq7UNNcLLs9an2kfQ=; b=EiGcCWFFQNdpeRhYdmJZj5 APDM8AmAcrZ6961xPUcLme4pyq3Uw39Pzs/LmbZuf1n8J0dRMblbngODvi80G1hF beqJ3fteLTN0yZooqCV0hdFcqgzIDvaeeOuaK/b0w9YeIh28VS6KYmJj12srqapQ cAhWZBwb3IJekUBx3kCO1cmDucRHMgN2cSjAoC/B8FyP1qUeOzyZQc0CL8JSm9JJ PCXLHtzIdKJVN+mbITfGluwpe395Qt9+zMH9wESIXTRWpD3FYXQoNdZiPhNBrj8+ oUtjJALtyi7BJ6B9d3cRbXB4KtGg8+GYw8iBeAAsd9t7TI550GttrLPjPC8iKe/A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 3A6A7E2441; Thu, 7 Dec 2017 21:09:59 -0500 (EST) Message-Id: <1512698999.1424753.1198010792.12C06420@webmail.messagingengine.com> From: Neil Jenkins To: Josef Jeff Sipek Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151269899914247530" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4b495bae References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> <20171128135837.GB2390@meili> <1511925847.2214786.1187644272.47957DBF@webmail.messagingengine.com> <8535394E-075E-4F83-8166-7ACB472860B8@glyphein.mailforce.net> <1512325523.1708452.1192487368.4835BE41@webmail.messagingengine.com> <1512625337.274010.1196837376.65DB99C6@webmail.messagingengine.com> <20171207151015.GG1632@meili> Date: Fri, 08 Dec 2017 13:09:59 +1100 In-Reply-To: <20171207151015.GG1632@meili> Archived-At: Subject: Re: [Jmap] Call for objections - standardising on plural names everywhere X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 02:10:02 -0000 This is a multi-part message in MIME format. --_----------=_151269899914247530 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Fri, 8 Dec 2017, at 02:10 AM, Josef 'Jeff' Sipek wrote: >> 5. I used "query" instead of "list" because it's less ambiguous and a>> = closer to match to what's happening. >=20 > Alright. I thought that list (with optional filter) was plenty clear.> W= ould calling it "search" instead be even clearer? Yeh, we considered all these options. Bron didn't like /search to avoid any potential for confusion with the IMAP SEARCH command (which doesn't do sorting etc.). I think /query is a good name, but /search is also fine. I don't really care, and I suspect this is the common opinion, so I just picked one which seemed to have a very slight advantage. If someone has a strong argument for one, I can change it=E2=80=A6 Neil. --_----------=_151269899914247530 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Fri, 8 Dec 2017, at 02:10 AM, Josef 'Jeff' Sipek wrote:
5. I used "query" = instead of "list" because it's less ambiguous and a
  closer to match to what's happening.

Alright.  I thought that list (with optional filter) was plenty c= lear.
Would calling it "search" instead be even clearer?

Yeh, we considered all these options. Bron didn't like /search to avoi= d any potential for confusion with the IMAP SEARCH command (which doesn't d= o sorting etc.).

I think /query is a good name, but /search is also fine. I don't reall= y care, and I suspect this is the common opinion, so I just picked one whic= h seemed to have a very slight advantage. If someone has a strong argument = for one, I can change it=E2=80=A6

Neil.
--_----------=_151269899914247530-- From nobody Thu Dec 7 18:31:32 2017 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 A32AD12871F for ; Thu, 7 Dec 2017 18:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=NhiWdX2L; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OTSmJWX5 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 PCkQ6yo3BBPm for ; Thu, 7 Dec 2017 18:31:28 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5579128B8D for ; Thu, 7 Dec 2017 18:31:28 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 15A3520754 for ; Thu, 7 Dec 2017 21:31:28 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 07 Dec 2017 21:31:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RqzT6hXTDvP0RpzBD /9o3StoIPf9/kh994671VvqYwo=; b=NhiWdX2LoHbLi0pIeRE+wXEfYDsSpfNV3 MxZUw1s3f2ahZFWX/nvxr0Rbc0c2GzvBvpBuxyByJnHbOYLNpr6WmgFi7TfEbDCN YeeqiANuM61BJ3UaBNq9OCE3tSa2/zTqPP0SCY6XEh4ru5SDzBDWSdv2XN5hz/7W p2FPtenYui/CA/YD9MYGEbpCS/6Z2RbyI7sz/JwUtO8rSYdAlrSe+u63p3e729Au DId0nSUx+BQ7MN/5eclAcNcqXDwHS6z0voSo/pGrnys7D9CU9RXr9cQfJ2mncCeH RdUoulU3LiN3r+/TzL/dVPxwfjMfJE3P13klCvvSAM7tQScPH3EoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RqzT6h XTDvP0RpzBD/9o3StoIPf9/kh994671VvqYwo=; b=OTSmJWX5GxRb2PtQ5o91p9 O9g+iRvNjl2DmywZ64dN6YBSbnmI301XFC3N7usy5n2wiGhoYz4HyvdnwUa1YGSy pGUFyqxAe08Dk2AvDJI7VC4KDk5K4FXLxtxWZucw9JM0YVtAWootJwLkpmUFHDah qo0uqNNbJja9JddH+TxeWzjAkCv0WLSzlDprCgbog9YdqrpwvWcM//4AW9UwBC0F 08d6P1KUloA//I1GFoPEREBMzHeMhvP6IUwFZks6M7gi0U1iFW6E78Mtnyxu+aIN STnfZpEFr+nYVZS0ChdjI8GY0CpOIWCTRt448H1BQeF0qezwOGORdq/uLWhd2/JA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C68D6E2441; Thu, 7 Dec 2017 21:31:27 -0500 (EST) Message-Id: <1512700287.1449469.1198029264.61E2D43F@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151270028714494690" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4b495bae Date: Fri, 08 Dec 2017 13:31:27 +1100 In-Reply-To: <20171207220727.GH1632@meili> References: <20171207220727.GH1632@meili> Archived-At: Subject: Re: [Jmap] back references X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 02:31:31 -0000 This is a multi-part message in MIME format. --_----------=_151270028714494690 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 8 Dec 2017, at 09:07 AM, Josef 'Jeff' Sipek wrote: > 1. As far as I can tell, the result of an action is always sent to the > client. Correct. > So, would it make sense to add a "suppress" field to the commands to> avoid sending back data that is needed only for backrefs? The overhead is not great, but on the other hand this is easy to implement and does save a bit of unnecessary overhead. Implementation wise you'd have to just strip the responses at the end, *after* making all the method calls so that back references could resolve into them correctly. I guess this could either be an "omitResponse: Boolean" (or isSilent) argument to each of the standard methods, or we come up with some different way of attaching metadata to the method calls. I'm not sure if this is worth it; anyone else got strong opinions on whether we should add this? > 2. Currently, the use of a back reference is indicated by mangling > the key> name by prepending a '#'. If the value produced is always an array,> couldn't we use the **type** of the field (instead of the name) to > indicate> that it is a back reference? You could look at the type, and we considered this, but it's much easier to implement in the current form, because you don't need to know the type of the argument so a generic preprocessor can run to result the back references before dispatching the method. The back reference could resolve to any type, including an object (if that's what this argument wanted). The current system just requires you to loop through the argument names and look for a starting '#' then replace this argument in a very straight-forward way. To do it based on type, this preprocessor would have to be more tightly coupled to the method being executed as it would need to know the exact types for each of the arguments. Neil. --_----------=_151270028714494690 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 8 Dec 2017, at 09:07 AM, Josef 'Jeff' Sipek wrote:
1. As far as I can tell, the result of an action is always sent to the client.

Correct. 

  So, would it make sense to add a "suppress" field to the commands to
  avoid sending back data that is needed only for backrefs?

The overhead is not great, but on the other hand this is easy to implement and does save a bit of unnecessary overhead. Implementation wise you'd have to just strip the responses at the end, after making all the method calls so that back references could resolve into them correctly.

I guess this could either be an "omitResponse: Boolean" (or isSilent) argument to each of the standard methods, or we come up with some different way of attaching metadata to the method calls.

I'm not sure if this is worth it; anyone else got strong opinions on whether we should add this?

2. Currently, the use of a back reference is indicated by mangling the key
  name by prepending a '#'.  If the value produced is always an array,
  couldn't we use the *type* of the field (instead of the name) to indicate
  that it is a back reference?

You could look at the type, and we considered this, but it's much easier to implement in the current form, because you don't need to know the type of the argument so a generic preprocessor can run to result the back references before dispatching the method.

The back reference could resolve to any type, including an object (if that's what this argument wanted). The current system just requires you to loop through the argument names and look for a starting '#' then replace this argument in a very straight-forward way. To do it based on type, this preprocessor would have to be more tightly coupled to the method being executed as it would need to know the exact types for each of the arguments.

Neil.
--_----------=_151270028714494690-- From nobody Thu Dec 7 19:05:50 2017 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 3C905127735 for ; Thu, 7 Dec 2017 19:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=o/8AIKot; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Yf9lUY9J 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 1prhLdE__895 for ; Thu, 7 Dec 2017 19:05:48 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0613B1276AF for ; Thu, 7 Dec 2017 19:05:48 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6333F20BFF; Thu, 7 Dec 2017 22:05:47 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 07 Dec 2017 22:05:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ESHi6WB96O1MaxUhW 49VKj7Bzq6o5uLNl6XjJjnubE8=; b=o/8AIKot1Z+tUedRaHUPCwmivlnuIFzTt 0Dy52Cv8eArQboOsHwFEkhHMHGCyev7pugToOl6B7CrNRbXMPq+wXbJeEiPGHsHw tQRMhURg9c2yRyCxS+e/3K425ln4Rvc7ZirofPUfaq7O1FZ4FB2hkPWYy+2+ubWn d21E7g4vGcP440fh+HqhCEUDxcD9JLIhd7uX878oRI0kckZc2lc760vVo2f4UgxU AxMaf+VytImiUalQmwWi1zEuHd1nD6PpsI6iRzA0NiMDqJOukUwAW9ZMhvdQ38Ff prweQyd3LJk+1l4fPoLwtxs6py+UHIOt+K8CMFRWVCL1RFiLrLIOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ESHi6W B96O1MaxUhW49VKj7Bzq6o5uLNl6XjJjnubE8=; b=Yf9lUY9JvbEkV1iRGKH2P1 Od0Whl8z2jdFbISKraVGwqtvqkFHU+FyElz2SKE+WFwu6FbWaBGZNdhWhlH7i7Fw vqLhvNStR6D7aTkFODHX6U/h0jWLel/B9UHPG/CPGfmM3KOiba/Jfqclns1luKs2 NVHIRb2kbLhygc6unBPpR5mzPBfnFYOTbmVDK9R3PWJp22sJQ5Trz9IJzHcidIfK CYQ0XWsasUMTTD1IEznlIE9HUVi3KbWDlfbCf845Bwo5oVWCUJtPVv6jMEmghJJ9 +Fh1t1/FO76XD81iHRsJZSRLLQ03CZqLlI3p52OqKEUwvJnF7UMUIk+OouvqkZkg == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id 16C947FAC9; Thu, 7 Dec 2017 22:05:47 -0500 (EST) References: <1511757555.96678.1185035608.5CC353FA@webmail.messagingengine.com> <20171128141105.GC2390@meili> <9ef19c08-d314-c22b-e628-d07936fa5d39@isode.com> <1511927937.2243688.1187666736.7A1F4129@webmail.messagingengine.com> <20171207223209.GI1632@meili> In-Reply-To: <20171207223209.GI1632@meili> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0AA8BA71-F9A2-4684-BB97-790E30C49637@glyphein.mailforce.net> Cc: Neil Jenkins , IETF JMAP Mailing List X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Thu, 7 Dec 2017 22:05:45 -0500 To: Josef 'Jeff' Sipek Archived-At: Subject: Re: [Jmap] Decoding of unknown headers X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 03:05:49 -0000 >> On Dec 7, 2017, at 5:32 PM, Josef 'Jeff' Sipek wr= ote: >>=20 >> On Wed, Nov 29, 2017 at 14:58:57 +1100, Neil Jenkins wrote: >> Some thoughts: >>=20 >> We currently have the following properties which represent parsed forms >> of headers: sender, from, to, cc, bcc, replyTo, subject, date. You can >> also request (decoded but otherwise unparsed) headers using the >> "headers" property. Perhaps what we should do is remove the special case >> properties and instead have the client request header names + how to >> process each one (raw base64, decoded, parsed as name/email list, parsed >> as date; may be extensible in the future). The syntax would need to be >> usable for setMessages too in some way. >> The other thing to think about is what to do when you have multiple >> headers of the same name; maybe you can explicitly request to receive >> all (as an array), otherwise you get the last one of that name. >=20 > I like this idea, but I'd say always return all. The extra two chars of JS= ON > won't make much of a difference. I agree that always return all really is the more desirable behavior here. Thanks, Stan From nobody Thu Dec 7 19:18:21 2017 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 D52CA126CD6 for ; Thu, 7 Dec 2017 19:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=qw/bFddv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AHSCW+fP 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 7ewk5Hh8nn6z for ; Thu, 7 Dec 2017 19:18:18 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819121250B8 for ; Thu, 7 Dec 2017 19:18:18 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E860920BB3; Thu, 7 Dec 2017 22:18:17 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 07 Dec 2017 22:18:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gwzywzb0OQpHehpuC +crGeZjA2VzokImlXpKbsSip34=; b=qw/bFddvTqzQTSW2nTuziljZ2ck9froBW oVn/SUWj6eUzMeke2KJAoHxavhdz52DD9rctE3DBTTw52Xvyhp5+Hh0VixDVB++k xwM0PJBgnvWZmNUqqhflPtfOmuVS3nQXxPUxlp+q2FM7zS5hWKwDQ0iAVNasrllb 1r7zE/RaaIS428cphTLJcq32Fr+8LiywtVkIkL08PVulWpqMj4pJNTi8FEExEums lArOxWK+o8GTGGSjHuHfSG9EkVFSORygCO67g92gq5vF1ka0asFVVdpubwF3iD3X w16BtKPSlwgfN2rKazX+wUXsOpUFNP/7AXMaBRxHW0l1y5YhyjfAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=gwzywz b0OQpHehpuC+crGeZjA2VzokImlXpKbsSip34=; b=AHSCW+fPW2+aQIs1pO7z8m VoFk2dRC9/X312IguRnlqMIz7XNpGg5rZzCfuqPPxrCrSQFqVAgCVFqgsVCy3+5p O2h6+pM1uHv15ZPhonPB/anNb/+VO8/GFBmmfcKAq1H9DeKxL98Vubeq28ts5XAG um1jWyoXKP9aJq6MMWC/UFsp549Z4GI8GJ7Loi2onJMyhb8JirvqB8N8SeVNH2OP tEbOub/h9oWBVLd/btxf/EkZxfOa13L7d7AiGs1Yn1VMsMoEYD+9o0fxKnMTiWLy QGqFKeyUsV8nNknEzztYLHNGJDK7PVoda0RVjSeeOCISzRwL7VesqvQYO4Ec1+fA == X-ME-Sender: Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id 963C97E688; Thu, 7 Dec 2017 22:18:17 -0500 (EST) References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> <20171128135837.GB2390@meili> <1511925847.2214786.1187644272.47957DBF@webmail.messagingengine.com> <8535394E-075E-4F83-8166-7ACB472860B8@glyphein.mailforce.net> <1512325523.1708452.1192487368.4835BE41@webmail.messagingengine.com> <1512625337.274010.1196837376.65DB99C6@webmail.messagingengine.com> <20171207151015.GG1632@meili> <1512698999.1424753.1198010792.12C06420@webmail.messagingengine.com> In-Reply-To: <1512698999.1424753.1198010792.12C06420@webmail.messagingengine.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <286637FA-ADAB-4D6F-91BE-5B08E770F901@glyphein.mailforce.net> Cc: Josef Jeff Sipek , IETF JMAP Mailing List X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Thu, 7 Dec 2017 22:18:15 -0500 To: Neil Jenkins Archived-At: Subject: Re: [Jmap] Call for objections - standardising on plural names everywhere X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 03:18:20 -0000 > On Dec 7, 2017, at 9:09 PM, Neil Jenkins wrote: >=20 > Yeh, we considered all these options. Bron didn't like /search to avoid an= y potential for confusion with the IMAP SEARCH command (which doesn't do sor= ting etc.). >=20 > I think /query is a good name, but /search is also fine. I don't really ca= re, and I suspect this is the common opinion, so I just picked one which see= med to have a very slight advantage. If someone has a strong argument for on= e, I can change it=E2=80=A6 I'm not opposed to /search, but I think /query suffices. As for the rest of= it, it looks fine to me. Stan= From nobody Wed Dec 13 19:38:57 2017 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 70186126C22 for ; Wed, 13 Dec 2017 19:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=n11qXrQS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NxhKd4+m 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 SG8YUumRVCLk for ; Wed, 13 Dec 2017 19:38:54 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F4C126DD9 for ; Wed, 13 Dec 2017 19:38:54 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 88A5620AF7 for ; Wed, 13 Dec 2017 22:38:53 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 13 Dec 2017 22:38:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=N+L46Wgn9hHKfVNEo3X5k44UyG+54F148raQ0TNSr k0=; b=n11qXrQSAEbZmCYUYE37Qftgx7fdkBJfzjldOp9tPtQxmXcFSFYnWygK9 FbfGPvaeF/7rMwIFTI4/RR1GM+p3EIkkBIojc8drN9hi6TwCerHRn3CLt1Fj7fLg z24uKRW+BkTBR50rsQIpL+Sh8ZU4B1XEVFdDe8yqyL6zfBF/LBVzRNiu4tE/dL/x WtN/E5GdDjQnH3K157/I0K2zNOeCTd9VsLzDcC6k/Rwd9ifQGlrjAXjHGhL13BbP 9B/P2XfwPV0r9hjnpyZ8DPXz43cObUUExX9ULF0WRSb8YIPcVkZZ/IjxliJZIY7m uF4QrKEI77sQMUo00Lx9nkpWOfepQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=N+L46Wgn9hHKfVNEo3X5k44UyG+54 F148raQ0TNSrk0=; b=NxhKd4+mP8jqqNCZjfc7dWNELv0/FDHaY0OTaJmkXKmwP JIi4A4Mqz4Xz2SFE/hYrntCgxwX2OyXvPQOhywiXehUP20GO1KMeUfxF6EuiM0EB yiL8LGds/y3khU3d+E9/NJHHNYE/UIWjYGoWBIdURRin6iElXEBmHrgWzMzvMYo3 jT5lU/REFSsW7eQMA91ID0kKh2zk6W3/Q7In0rftBdD63NXA5EoP3xR6LVEWPfPK IDcaFWKkMf0F+cGZurCWEPCs5m0SFpCYocPOkmUgVTRChtVS7kAvw2mBKbAOz9sg 9DVHBSFPBuqUDhrlBfw834qF6yT4uNc/copeMT1oQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 43C29E21A8; Wed, 13 Dec 2017 22:38:53 -0500 (EST) Message-Id: <1513222733.562048.1204501864.2B4A2737@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15132227335620480" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4cfca31d Date: Thu, 14 Dec 2017 14:38:53 +1100 Archived-At: Subject: [Jmap] JMAP Core X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 03:38:56 -0000 This is a multi-part message in MIME format. --_----------=_15132227335620480 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" There are currently only two issues left open for JMAP core[1]! I'm hoping we can basically be done with this spec by Christmas, and then finish off the JMAP Mail issues in the beginning of next year to have both done by IETF 101. The two open issues are: *#86*[2]* Do we need to define a minimum allowed maxCallsInRequest value? * I'm not sure we do, as a client could operate with maxCallsInRequest = 1, it just couldn't make as efficient use of the network. Any value we did pick would of course be arbitrary. Any thoughts on this? *#89*[3]* Do we need a registry of error types? * Possibly? There are errors that may be returned by any method[4], and it's possible we may want to expand this list in the future; not requiring a new spec to do that could be good. I don't know whether method- specific errors should go in such a registry as well. Thoughts? How do I go about creating a registry presuming we decide we do need one? I'd also like to invite members of this list to do a final review of the core spec[5] and raise any other issues you think still need addressing earlier rather than later. Thanks! Neil. Links: 1. https://github.com/jmapio/jmap/labels/Core 2. https://github.com/jmapio/jmap/issues/86 3. https://github.com/jmapio/jmap/issues/89 4. http://jmap.io/spec-core.html#errors 5. http://jmap.io/spec-core.html --_----------=_15132227335620480 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
There are currently only two issues left open for JMAP core! I'm hoping we can basically be done with this spec by Christmas, and then finish off the JMAP Mail issues in the beginning of next year to have both done by IETF 101.

The two open issues are:

#86 Do we need to define a minimum allowed maxCallsInRequest value?

I'm not sure we do, as a client could operate with maxCallsInRequest = 1, it just couldn't make as efficient use of the network. Any value we did pick would of course be arbitrary. Any thoughts on this?

#89 Do we need a registry of error types?

Possibly? There are errors that may be returned by any method, and it's possible we may want to expand this list in the future; not requiring a new spec to do that could be good. I don't know whether method-specific errors should go in such a registry as well. Thoughts? How do I go about creating a registry presuming we decide we do need one?

I'd also like to invite members of this list to do a final review of the core spec and raise any other issues you think still need addressing earlier rather than later. Thanks!

Neil.
--_----------=_15132227335620480-- From nobody Fri Dec 22 03:45:23 2017 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 86BE2120227 for ; Fri, 22 Dec 2017 03:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nYihaT2ifPES for ; Fri, 22 Dec 2017 03:45:19 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF41124239 for ; Fri, 22 Dec 2017 03:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1513943118; d=isode.com; s=june2016; i=@isode.com; bh=eClz9mexm/Kn9IPc73Ibb1X3L8AS/GnBy65rEjsiCIk=; 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=loL6GT0PxxjghG/Jwl4MacW6dVivxMEVJvLEnLgX8UsMoS9b60oKi1u4vJGAcFVslxC+7B OKwmK9egzA3MCvb0N5l74gm3PSm5GpOgUC0p/zVGAvsxve2BVcGkAb6DasWD8P8GdFo5j3 BRawozByx6i4EQ88zAAczeBaZjo7Ubk=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 22 Dec 2017 11:45:18 +0000 To: Neil Jenkins References: <1513222733.562048.1204501864.2B4A2737@webmail.messagingengine.com> From: Alexey Melnikov Cc: IETF JMAP Mailing List Message-ID: Date: Fri, 22 Dec 2017 11:43:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: <1513222733.562048.1204501864.2B4A2737@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------2C2168E7C60755A11BF2E8D4" Content-Language: en-US Archived-At: Subject: Re: [Jmap] JMAP Core X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 11:45:21 -0000 --------------2C2168E7C60755A11BF2E8D4 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi Neil, On 14/12/2017 03:38, Neil Jenkins wrote: > There are currently only two issues left open for JMAP core=20 > ! I'm hoping we can=20 > basically be done with this spec by Christmas, and then finish off the=20 > JMAP Mail issues in the beginning of next year to have both done by=20 > IETF 101. > > The two open issues are: > > *#86* *Do we=C2=A0need to define= =20 > a minimum allowed maxCallsInRequest value? * > > I'm not sure we do, as a client could operate with maxCallsInRequest =3D= =20 > 1, it just couldn't make as efficient use of the network. Any value we=20 > did pick would of course be arbitrary. Any thoughts on this? I think value 1 is rather limiting and will prevent the protocol from=20 being useful, because clients might have to potentially have multiple=20 code paths to cope with maxCallsInRequest =3D=3D 1 and more capable servers. I suggest picking a value > 1 which is relatively common from common use=20 cases and mandate it. Maybe the value is 3 or slightly higher than that. > *#89* *=C2=A0Do we need a=20 > registry of error types? * > > Possibly? There are errors that may be returned by any method=20 > , and it's possible we may want=20 > to expand this list in the future; not requiring a new spec to do that=20 > could be good. Yes, I think we need to have a registry. I find IANA registries to be=20 useful for implementing things and finding out what was already registered. > I don't know whether method-specific errors should go in such a=20 > registry as well. Thoughts? I think so. If you want to have errors which mean (slightly) different=20 things for different methods, it would be useful to be able to get this=20 information from the registry. If different methods can't have the same=20 error codes that mean different things, it would be good to know this=20 information as well. > How do I go about creating a registry presuming we decide we do need one? I can suggest some text on this. I think the main thing to decide first=20 is the registration policy. Do we want some kind of expert review for them? > I'd also like to invite members of this list to do a final review of=20 > the core spec =C2=A0and raise any other=20 > issues you think still need addressing earlier rather than later. Thanks! Best Regards, Alexey --------------2C2168E7C60755A11BF2E8D4 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi Neil,


On 14/12/2017 03:38, Neil Jenkins wrote:
There are currently only two issues left open for JMAP core! I'm hoping we can basically be done with this spec by Christmas, and then finish off the JMAP Mail issues in the beginning of next year to have both done by IETF 101.

The two open issues are:

#86 Do we=C2=A0need to defi= ne a minimum allowed maxCallsInRequest value?

I'm not sure we do, as a client could operate with maxCallsInRequest =3D 1, it just couldn't make as efficient use of the network. Any value we did pick would of course be arbitrary. Any thoughts on this?
I think value 1 is rather limiting and will prevent the protocol from being useful, because clients might have to potentially have multiple code paths to cope with maxCallsInRequest =3D=3D 1 and more capable servers.

I suggest picking a value > 1 which is relatively common from common use cases and mandate it. Maybe the value is 3 or slightly higher than that.

#89=C2=A0Do we need a regis= try of error types?

Possibly? There are errors that may be returned by any method, and it's possible we may want to expand this list in the future; not requiring a new spec to do that could be good.

Yes, I think we need to have a registry. I find IANA registries to be useful for implementing things and finding out what was already registered.

I don't know whether method-specific errors should go in such a registry as well. Thoughts?

I think so. If you want to have errors which mean (slightly) different things for different methods, it would be useful to be able to get this information from the registry. If different methods can't have the same error codes that mean different things, it would be good to know this information as well.

How do I go about creating a registry presuming we decide we do need one?

I can suggest some text on this. I think the main thing to decide first is the registration policy. Do we want some kind of expert review for them?

I'd also like to invite members of this list to do a final review of the core spec=C2=A0and raise any othe= r issues you think still need addressing earlier rather than later. Thanks!

Best Regards,
Alexey


--------------2C2168E7C60755A11BF2E8D4-- From nobody Fri Dec 22 03:54:28 2017 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 DDC9B124239 for ; Fri, 22 Dec 2017 03:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HYDzELSu1JbL for ; Fri, 22 Dec 2017 03:54:25 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id EE2E5120227 for ; Fri, 22 Dec 2017 03:54:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1513943664; d=isode.com; s=june2016; i=@isode.com; bh=ee52TVbJmsNrbshPy/WtCMHKl/HBcYX9oMgV4weRkdo=; 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=m4cOEmiQxpCv5tK6YOWE/cGGaQF/DysliyFz6gZv9cr/P/shuSGFXMyEYHu7sxKZAnB6iA dEnMgtwKMoVaUBkoGobKjQr2s9rrJqGL6NL78DAxgftzaty3l4zV4wUxGkf5B3/uNoC6Jb oL1w/4XbaPUdSwOzSBlpxZg+499wilI=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 22 Dec 2017 11:54:23 +0000 To: Chris Newman , Neil Jenkins Cc: IETF JMAP Mailing List References: <1504500853.1631039.1094266568.3F13ADA8@webmail.messagingengine.com> <01CCF1A2-A709-412C-90F7-6DAC3A71AD39@oracle.com> <1505698131.2041914.1109222872.6A22DCE0@webmail.messagingengine.com> <49FEE67A-747A-447B-840C-675E2EE23101@fugue.com> <1512001201.3289077.1188813640.53BFE5FE@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: Date: Fri, 22 Dec 2017 11:52:44 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5CD45BE11FABA1C75F6C6C12" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Destroying mailboxes: how this affects messages X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 11:54:27 -0000 This is a multi-part message in MIME format. --------------5CD45BE11FABA1C75F6C6C12 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 05/12/2017 05:35, Chris Newman wrote: > Works for me. > +1. This is much simpler. > > - Chris > > On 29 Nov 2017, at 16:20, Neil Jenkins wrote: > > There was a bit more discussion of this at IETF100, and I think > the consensus was the current proposed solution was a bit of > overkill. I've revised the pull request so there's now a simpler > onDestroyRemoveMessages: Boolean (default: false) argument to > setMailboxes. If not set, or set explicitly to false, you get an > error if you try to destroy a mailbox that has messages in it. If > it's set to true, you get IMAP-like behaviour: messages are > automatically removed from it and destroyed if in no other mailbox. > > If the client wants to do something else, it can explicitly fetch > the messages and move them wherever it wants before destroying the > mailbox. > > You can see the diff here > . > How does this look to people? > > Neil. > --------------5CD45BE11FABA1C75F6C6C12 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 05/12/2017 05:35, Chris Newman wrote:

Works for me.

+1. This is much simpler.

- Chris

On 29 Nov 2017, at 16:20, Neil Jenkins wrote:

There was a bit more discussion of this at IETF100, and I think the consensus was the current proposed solution was a bit of overkill. I've revised the pull request so there's now a simpler onDestroyRemoveMessages: Boolean (default: false) argument to setMailboxes. If not set, or set explicitly to false, you get an error if you try to destroy a mailbox that has messages in it. If it's set to true, you get IMAP-like behaviour: messages are automatically removed from it and destroyed if in no other mailbox.

If the client wants to do something else, it can explicitly fetch the messages and move them wherever it wants before destroying the mailbox.

You can see the diff here. How does this look to people?

Neil.

--------------5CD45BE11FABA1C75F6C6C12-- From nobody Fri Dec 22 05:19:37 2017 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 EE25112E85E for ; Fri, 22 Dec 2017 05:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 puH2dDoEzA2F for ; Fri, 22 Dec 2017 05:19:33 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7A212E858 for ; Fri, 22 Dec 2017 05:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1513948772; d=isode.com; s=june2016; i=@isode.com; bh=5A78gSIqwErFVZNRz0J79awpSt9gXStmSU7Llskd2Rs=; 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=urZDO8jwts5pfgfSWnXVMm1zwo0HtxYd6etcv/0ZrDNWv7WLi/oC5TtEV9mE/gzVJffLrG MIB3avySI+vAYn0cg8hADlp863bhqp7JVRPtjBMBUgqmjB0cIvH8GhraKfAbW+NVB39WWN hwE3wD+FkoG7F9ihcvX5/9KbdZjWJA4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 22 Dec 2017 13:19:32 +0000 From: Alexey Melnikov To: Josef 'Jeff' Sipek , Neil Jenkins Cc: IETF JMAP Mailing List References: <1511757555.96678.1185035608.5CC353FA@webmail.messagingengine.com> <20171128141105.GC2390@meili> <9ef19c08-d314-c22b-e628-d07936fa5d39@isode.com> <1511927937.2243688.1187666736.7A1F4129@webmail.messagingengine.com> <20171207223209.GI1632@meili> Message-ID: <7309cee9-ba55-9efa-567c-d6259b9705cf@isode.com> Date: Fri, 22 Dec 2017 13:17:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: <20171207223209.GI1632@meili> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] Decoding of unknown headers X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 13:19:36 -0000 On 07/12/2017 22:32, Josef 'Jeff' Sipek wrote: > On Wed, Nov 29, 2017 at 14:58:57 +1100, Neil Jenkins wrote: >> Some thoughts: >> >> We currently have the following properties which represent parsed forms >> of headers: sender, from, to, cc, bcc, replyTo, subject, date. You can >> also request (decoded but otherwise unparsed) headers using the >> "headers" property. Perhaps what we should do is remove the special case >> properties and instead have the client request header names + how to >> process each one (raw base64, decoded, parsed as name/email list, parsed >> as date; may be extensible in the future). The syntax would need to be >> usable for setMessages too in some way. >> The other thing to think about is what to do when you have multiple >> headers of the same name; maybe you can explicitly request to receive >> all (as an array), otherwise you get the last one of that name. > I like this idea, but I'd say always return all. The extra two chars of JSON > won't make much of a difference. Always returning all is fine. We just need to have examples in the draft showing multiple values, so that people don't forget to write code to support this. From nobody Fri Dec 22 06:44:44 2017 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 363DE12EAF0 for ; Fri, 22 Dec 2017 06:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=xgenplus.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 3FwJzRaAdarP for ; Fri, 22 Dec 2017 06:44:33 -0800 (PST) Received: from a.tbms.in (a.tbms.in [202.157.72.21]) by ietfa.amsl.com (Postfix) with ESMTP id C502212EAEC for ; Fri, 22 Dec 2017 06:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt; c=simple/relaxed; t=1513953864; s=xgen; d=xgenplus.com; h=Date:From:Message-ID:MIME-Version; z=Date:Fri,=2022=20Dec=202017=2020:13:58=20+0530|From:ajay@xgenplus.com|Message-ID:<12352638.531741513953864800.JavaMail.root@mx2.datainfosys.com>|MIME-Version:1.0; l=5036; bh=5YpyBAqP4DKsc3TZGBE8TdPbMiY=; b=Id/cJ/cJm4r/d5slMBbojTx40Mctw5rdfU4FPFbW0mYh88nPRO88vITIH1BnmdGZ 3VEREsUEULWVlmXr3vjHpvVoEsniFMrfQSGc/WGLh1FUYWb662tEsh4oPaRYDcWsfKq pGVUGhVhj/WO0A9b49dBUjKhepw6dkPgn+CGGeoM= Received: From 202.157.83.44[202.157.83.44] by [202.157.83.51] [mx2.datainfosys.com] [mta] with SMTP id ../InBoxS/20171222/20/60413.6261323749(1513953863477); Fri, 22 Dec 2017 14:44:23 +0000 Received: From 202.157.87.20[202.157.87.20] by [202.157.87.20] [DataMailApp-2] [mta] with SMTP id 97038.98297239927(1513953863405); Fri, 22 Dec 2017 14:44:23 +0000 Received: From[9c365f6ade93d2ec480c9a39a918d5eb] [202.157.76.62] with SMTP id 91310.3053369439(1513953839523); Fri, 22 Dec 2017 14:43:59 +0000 Date: Fri, 22 Dec 2017 20:13:58 +0530 From: ajay@xgenplus.com To: alexey.melnikov@isode.com Cc: jeff.sipek@dovecot.fi, neilj@fastmailteam.com, jmap@ietf.org Message-ID: <12352638.531741513953864800.JavaMail.root@mx2.datainfosys.com> X-SentFromIP: 192.168.0.102- Jio-wifi X_Xgen_Device_Id: BE2B7A71-BDCD-47C7-9F46-A10BB9D168C7 X-SentFromDate: 2017-12-22 14:43:58 +0000 X-Mailer: XgenPlus iOS App 4.5 X-SendType: REPLYALL X_Xgen_Delivery_Report: YES X-Priority: 3 X-BrowserType: iPhone 11.2.1 XMessage-Id: XGenPlusMessageID:97831513953838 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5a3d1a2e_6b8b4567_198" Archived-At: Subject: Re: [Jmap] Decoding of unknown headers X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 14:44:42 -0000 --5a3d1a2e_6b8b4567_198 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline While decoding the headers. If the FROM,TO,CC headers are are containing ACE encoding or punycode or utf8 local part, how its expected to be returned. On 22-Dec-2017 at 18:47:50 Alexey Melnikov 'alexey.melnikov@isode.com' wrote: From: Alexey Melnikov To: Josef 'Jeff' Sipek , Neil Jenkins Cc: IETF JMAP Mailing List Subject: [Jmap] Decoding of unknown headers Date: 22 December 2017 at 18:47:50 IST On 07/12/2017 22:32, Josef 'Jeff' Sipek wrote: > On Wed, Nov 29, 2017 at 14:58:57 +1100, Neil Jenkins wrote: > > Some thoughts: > > > > We currently have the following properties which represent parsed forms > > of headers: sender, from, to, cc, bcc, replyTo, subject, date. You can > > also request (decoded but otherwise unparsed) headers using the > > "headers" property. Perhaps what we should do is remove the special case > > properties and instead have the client request header names + how to > > process each one (raw base64, decoded, parsed as name/email list, parsed > > as date; may be extensible in the future). The syntax would need to be > > usable for setMessages too in some way. > > The other thing to think about is what to do when you have multiple > > headers of the same name; maybe you can explicitly request to receive > > all (as an array), otherwise you get the last one of that name. > I like this idea, but I'd say always return all. The extra two chars of JSON > won't make much of a difference. Always returning all is fine. We just need to have examples in the draft showing multiple values, so that people don't forget to write code to support this. _______________________________________________ Jmap mailing list Jmap@ietf.org https://www.ietf.org/mailman/listinfo/jmap --5a3d1a2e_6b8b4567_198 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
While decoding the headers. If the =46ROM,TO,CC headers are are co= ntaining ACE encoding or punycode or utf8 local part, how its expected to= be returned.




On 22-Dec-2017 at 18:47:50
Alexey= Melnikov 'alexey.melnikov=40isode.com' wrote:
=46= rom: Alexey Melnikov <alexey.melnikov=40isode.com>
<= b>To: Josef 'Jeff' Sipek <jeff.sipek=40dovecot.fi>, Neil Jenkin= s <neilj=40fastmailteam.com>
Cc: IET=46 JMAP Mail= ing List <jmap=40ietf.org>
Subject: =5BJmap=5D De= coding of unknown headers
Date: 22 December 2017 at 18:= 47:50 IST
On 07/12/2017 22:32, Josef 'Jeff' Sipek = wrote: <=21--N-->
<=21--N-->
On We= d, Nov 29, 2017 at 14:58:57 +1100, Neil Jenkins wrote: <=21--N-->
Some thoughts: <=21--N-->
<=21--N-->
= We currently have the following properties which represent parsed forms <= =21--N-->
of headers: sender, from, to, cc, bcc, replyTo, subject, da= te. You can <=21--N-->
also request (decoded but otherwise unparsed) = headers using the <=21--N-->
=22headers=22 property. Perhaps what we = should do is remove the special case <=21--N-->
properties and instea= d have the client request header names + how to <=21--N-->
process ea= ch one (raw base64, decoded, parsed as name/email list, parsed <=21--N-->=
as date; may be extensible in the future). The syntax would need to = be <=21--N-->
usable for setMessages too in some way. <=21--N-->
= The other thing to think about is what to do when you have multiple <=21-= -N-->
headers of the same name; maybe you can explicitly request to r= eceive <=21--N-->
all (as an array), otherwise you get the last one o= f that name. <=21--N-->
I like this idea, but I'd say al= ways return all. The extra two chars of JSON <=21--N-->
won't make mu= ch of a difference. <=21--N-->
<=21--N-->
Always re= turning all is fine. We just need to have examples in the draft <=21--N--= >
showing multiple values, so that people don't forget to write code = to <=21--N-->
support this. <=21--N-->
<=21--N-->
<=21--N--= >
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F = <=21--N-->
Jmap mailing list <=21--N-->
Jmap=40ietf.org <=21--N--= >
https://www.ietf.org/mailman/listinfo/jmap <=21--N-->
. <=21--N= -->
--5a3d1a2e_6b8b4567_198-- From nobody Fri Dec 22 06:50:31 2017 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 EF5FC12D7E2 for ; Fri, 22 Dec 2017 06:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 dEMweVfMakEB for ; Fri, 22 Dec 2017 06:50:29 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id B40D712DA3E for ; Fri, 22 Dec 2017 06:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1513954224; d=isode.com; s=june2016; i=@isode.com; bh=sq9s1HArAmbHSTIkKBAsVZF8PbRGP/BVpuEKbvDs4aA=; 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=WIQk52GVi0NPnAM3S+Bui1WSAm8bUKknYgesNGgPg/SZJ4lbax49mhopVz1zAkPk4yZBac PGWoWEtQ4OElXjqqcBiV9x4cUpMk86wj2YcYjJz3FHI0pMgJEQZiILy7XX1V3Fby4UkWBB E2x2wGGLIjBLWxsV5IQZDUa2mbG5r1Q=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 22 Dec 2017 14:50:23 +0000 To: ajay@xgenplus.com Cc: jeff.sipek@dovecot.fi, neilj@fastmailteam.com, jmap@ietf.org References: <2114688808.531771513953864812.JavaMail.root@mx2.datainfosys.com> From: Alexey Melnikov Message-ID: <4eab3846-0bb1-c1b0-a293-fd66a36cb187@isode.com> Date: Fri, 22 Dec 2017 14:48:41 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: <2114688808.531771513953864812.JavaMail.root@mx2.datainfosys.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------909E894062BE41C405624800" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Decoding of unknown headers X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 14:50:31 -0000 This is a multi-part message in MIME format. --------------909E894062BE41C405624800 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 22/12/2017 14:43, ajay@xgenplus.com wrote: > While decoding the headers. If the FROM,TO,CC headers are are > containing ACE encoding or punycode or utf8 local part, how its > expected to be returned. No changes to the local part of email addresses must be done by JMAP server. If we want to support EAI email, we need to say how this is handled by JMAP servers. Decoding punycode in domain part of email addresses is Ok, but shouldn't be required. > On 22-Dec-2017 at 18:47:50 > Alexey Melnikov 'alexey.melnikov@isode.com' wrote: > *From:* Alexey Melnikov > *To:* Josef 'Jeff' Sipek , Neil Jenkins > > *Cc:* IETF JMAP Mailing List > *Subject:* [Jmap] Decoding of unknown headers > *Date:* 22 December 2017 at 18:47:50 IST > On 07/12/2017 22:32, Josef 'Jeff' Sipek wrote: > >> On Wed, Nov 29, 2017 at 14:58:57 +1100, Neil Jenkins wrote: >>> Some thoughts: >>> >>> We currently have the following properties which represent parsed forms >>> of headers: sender, from, to, cc, bcc, replyTo, subject, date. You can >>> also request (decoded but otherwise unparsed) headers using the >>> "headers" property. Perhaps what we should do is remove the special >>> case >>> properties and instead have the client request header names + how to >>> process each one (raw base64, decoded, parsed as name/email list, >>> parsed >>> as date; may be extensible in the future). The syntax would need to be >>> usable for setMessages too in some way. >>> The other thing to think about is what to do when you have multiple >>> headers of the same name; maybe you can explicitly request to receive >>> all (as an array), otherwise you get the last one of that name. >> I like this idea, but I'd say always return all. The extra two chars >> of JSON >> won't make much of a difference. > > Always returning all is fine. We just need to have examples in the draft > showing multiple values, so that people don't forget to write code to > support this. > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > . --------------909E894062BE41C405624800 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 22/12/2017 14:43, ajay@xgenplus.com wrote:

While decoding the headers. If the FROM,TO,CC headers are are containing ACE encoding or punycode or utf8 local part, how its expected to be returned.
No changes to the local part of email addresses must be done by JMAP server.

If we want to support EAI email, we need to say how this is handled by JMAP servers. Decoding punycode in domain part of email addresses is Ok, but shouldn't be required.

On 22-Dec-2017 at 18:47:50
Alexey Melnikov 'alexey.melnikov@isode.com' wrote:
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi>, Neil Jenkins <neilj@fastmailteam.com>
Cc: IETF JMAP Mailing List <jmap@ietf.org>
Subject: [Jmap] Decoding of unknown headers
Date: 22 December 2017 at 18:47:50 IST
On 07/12/2017 22:32, Josef 'Jeff' Sipek wrote:

On Wed, Nov 29, 2017 at 14:58:57 +1100, Neil Jenkins wrote:
Some thoughts:

We currently have the following properties which represent parsed forms
of headers: sender, from, to, cc, bcc, replyTo, subject, date. You can
also request (decoded but otherwise unparsed) headers using the
"headers" property. Perhaps what we should do is remove the special case
properties and instead have the client request header names + how to
process each one (raw base64, decoded, parsed as name/email list, parsed
as date; may be extensible in the future). The syntax would need to be
usable for setMessages too in some way.
The other thing to think about is what to do when you have multiple
headers of the same name; maybe you can explicitly request to receive
all (as an array), otherwise you get the last one of that name.
I like this idea, but I'd say always return all. The extra two chars of JSON
won't make much of a difference.

Always returning all is fine. We just need to have examples in the draft
showing multiple values, so that people don't forget to write code to
support this.


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

--------------909E894062BE41C405624800-- From nobody Fri Dec 22 06:50:44 2017 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 6447D12D7E2 for ; Fri, 22 Dec 2017 06:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=xgenplus.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 Bfr5pMyP2mCM for ; Fri, 22 Dec 2017 06:50:33 -0800 (PST) Received: from a.tbms.in (a.tbms.in [202.157.72.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4B97812AF6E for ; Fri, 22 Dec 2017 06:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt; c=simple/relaxed; t=1513954224; s=xgen; d=xgenplus.com; h=Date:From:Message-ID:MIME-Version; z=Date:Fri,=2022=20Dec=202017=2020:20:01=20+0530|From:ajay@xgenplus.com|Message-ID:<191954301.533281513954224689.JavaMail.root@mx2.datainfosys.com>|MIME-Version:1.0; l=5301; bh=8i09AzUdnnpAAY51Xvm8iaLdpeA=; b=azG1EZPfG3jqP7wSokfGMkmip1vePrXRFTttIXJVlRsrv43YKsOD4a5N4hUgPoIv t70l7Si0jFYiPKS9DcYmVrLu54B6Fw+GxkIYAvTWyTmlX/nX1FJJw3ZvH5OWs5oKyzj vOHr5xhwTFTK4IB7LheRjBmPFt8jLggFjTZzaBB8= Received: From 202.157.83.44[202.157.83.44] by [202.157.83.51] [mx2.datainfosys.com] [mta] with SMTP id ../InBoxS/20171222/20/60977.37384119091(1513954223480); Fri, 22 Dec 2017 14:50:23 +0000 Received: From 202.157.87.20[202.157.87.20] by [202.157.87.20] [DataMailApp-2] [mta] with SMTP id 8947.43849804348(1513954223415); Fri, 22 Dec 2017 14:50:23 +0000 Received: From[9c365f6ade93d2ec480c9a39a918d5eb] [202.157.76.62] with SMTP id 38323.30154866275(1513954202518); Fri, 22 Dec 2017 14:50:02 +0000 Date: Fri, 22 Dec 2017 20:20:01 +0530 From: ajay@xgenplus.com To: alexey.melnikov@isode.com Cc: jeff.sipek@dovecot.fi, neilj@fastmailteam.com, jmap@ietf.org Message-ID: <191954301.533281513954224689.JavaMail.root@mx2.datainfosys.com> X-SentFromIP: 192.168.0.102- Jio-wifi X_Xgen_Device_Id: BE2B7A71-BDCD-47C7-9F46-A10BB9D168C7 X-SentFromDate: 2017-12-22 14:50:01 +0000 X-Mailer: XgenPlus iOS App 4.5 X-SendType: REPLYALL X_Xgen_Delivery_Report: YES X-Priority: 3 X-BrowserType: iPhone 11.2.1 XMessage-Id: XGenPlusMessageID:25681513954201 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5a3d1b99_327b23c6_198" Archived-At: Subject: Re: [Jmap] Decoding of unknown headers X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 14:50:35 -0000 --5a3d1b99_327b23c6_198 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46or example, =46rom: =3D=3Futf-8=3FB=3F4KS=464KSc4KSv=3F=3D=40=E0=A4=A1= =E0=A4=BE=E0=A4=9F=E0=A4=BE.=E0=A4=AD=E0=A4=BE=E0=A4=B0=E0=A4=A4 or =46rom: =3D=3Futf-8=3FB=3F4KS=464KSc4KSv=3F=3Dxn=E2=80=94 On 22-Dec-2017 at 18:47:50 Alexey Melnikov 'alexey.melnikov=40isode.com' wrote: =46rom: Alexey Melnikov To: Josef 'Jeff' Sipek , Neil Jenkins Cc: IET=46 JMAP Mailing List Subject: =5BJmap=5D Decoding of unknown headers Date: 22 December 2017 at 18:47:50 IST On 07/12/2017 22:32, Josef 'Jeff' Sipek wrote: > On Wed, Nov 29, 2017 at 14:58:57 +1100, Neil Jenkins wrote: > > Some thoughts: > > > > We currently have the following properties which represent parsed for= ms > > of headers: sender, from, to, cc, bcc, replyTo, subject, date. You ca= n > > also request (decoded but otherwise unparsed) headers using the > > =22headers=22 property. Perhaps what we should do is remove the speci= al case > > properties and instead have the client request header names + how to > > process each one (raw base64, decoded, parsed as name/email list, par= sed > > as date; may be extensible in the future). The syntax would need to b= e > > usable for setMessages too in some way. > > The other thing to think about is what to do when you have multiple > > headers of the same name; maybe you can explicitly request to receive= > > all (as an array), otherwise you get the last one of that name. > I like this idea, but I'd say always return all. The extra two chars of= JSON > won't make much of a difference. Always returning all is fine. We just need to have examples in the draft showing multiple values, so that people don't forget to write code to support this. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Jmap mailing list Jmap=40ietf.org https://www.ietf.org/mailman/listinfo/jmap --5a3d1b99_327b23c6_198 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=46or example, =46rom: =3D=3Futf-8=3FB=3F4KS=464KSc4KSv=3F=3D=40=E0= =A4=A1=E0=A4=BE=E0=A4=9F=E0=A4=BE.=E0=A4=AD=E0=A4=BE=E0=A4=B0=E0=A4=A4 or=

=46rom: =3D=3Futf-8=3FB=3F4KS=464KSc4KSv=3F=3Dxn=E2=80=94
<= br />


On 22-Dec-2017 at 18:47:50
Alexey Melnikov 'alexey.me= lnikov=40isode.com' wrote:
=46rom: Alexey Meln= ikov <alexey.melnikov=40isode.com>
To: Josef 'Jef= f' Sipek <jeff.sipek=40dovecot.fi>, Neil Jenkins <neilj=40fastma= ilteam.com>
Cc: IET=46 JMAP Mailing List <jmap=40= ietf.org>
Subject: =5BJmap=5D Decoding of unknown he= aders
Date: 22 December 2017 at 18:47:50 IST
On 07/12/2017 22:32, Josef 'Jeff' Sipek wrote: <=21--N--> <=21--N-->
On Wed, Nov 29, 2017 at 1= 4:58:57 +1100, Neil Jenkins wrote: <=21--N-->
Some thoughts: <=21--N-->
<=21--N-->
We currently have th= e following properties which represent parsed forms <=21--N-->
of hea= ders: sender, from, to, cc, bcc, replyTo, subject, date. You can <=21--N-= ->
also request (decoded but otherwise unparsed) headers using the <=21= --N-->
=22headers=22 property. Perhaps what we should do is remove th= e special case <=21--N-->
properties and instead have the client requ= est header names + how to <=21--N-->
process each one (raw base64, de= coded, parsed as name/email list, parsed <=21--N-->
as date; may be e= xtensible in the future). The syntax would need to be <=21--N-->
usab= le for setMessages too in some way. <=21--N-->
The other thing to thi= nk about is what to do when you have multiple <=21--N-->
headers of t= he same name; maybe you can explicitly request to receive <=21--N-->
= all (as an array), otherwise you get the last one of that name. <=21--N--= >
I like this idea, but I'd say always return all. The e= xtra two chars of JSON <=21--N-->
won't make much of a difference. <=21= --N-->
<=21--N-->
Always returning all is fine. We = just need to have examples in the draft <=21--N-->
showing multiple v= alues, so that people don't forget to write code to <=21--N-->
suppor= t this. <=21--N-->
<=21--N-->
<=21--N-->
=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F <=21--N-->
Jmap mail= ing list <=21--N-->
Jmap=40ietf.org <=21--N-->
https://www.ietf.o= rg/mailman/listinfo/jmap <=21--N-->
. <=21--N-->
--5a3d1b99_327b23c6_198-- From nobody Fri Dec 22 07:30:43 2017 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 BA0D512EB0A for ; Fri, 22 Dec 2017 07:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 860eqxhGwt2X for ; Fri, 22 Dec 2017 07:30:39 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AF312EB09 for ; Fri, 22 Dec 2017 07:30:38 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2FA2BFA0092; Fri, 22 Dec 2017 15:30:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1513956637; bh=zF6jO+y77peXCq0140XFtE/xPhW9QQWvS/FQjxIRtNs=; h=From:To:Subject:Date:References:From; b=spiA70h//gZTlsE+i1RfJVUqodhfSDDmV9a6KRT7kHuNwHYEKn4Ny20pdQaBAtoK8 /s6NjAwpzCb5gR3pvCCtm9R1uQs78vl+27uIfpxQdDiqtcPu6zFPJRLmeq2oJy6WhP VoQs7/FCdktRCZvzkqp74MoEnnyOiHboTOdrcsCQ= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1513956636-12346-22429/12/2898; Fri, 22 Dec 2017 15:30:36 +0000 From: Arnt Gulbrandsen To: jeff.sipek@dovecot.fi, neilj@fastmailteam.com, jmap@ietf.org, Alexey Melnikov , ajay@xgenplus.com Date: Fri, 22 Dec 2017 15:30:36 +0000 Message-Id: References: <2114688808.531771513953864812.JavaMail.root@mx2.datainfosys.com> <4eab3846-0bb1-c1b0-a293-fd66a36cb187@isode.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Jmap] Decoding of unknown headers X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 15:30:42 -0000 The EAI RFCs do not specify that punycode is to be handled in any particular way, so it would be inappropriate for the JMAP document to specify more. BTW, I know that several programs ignore punycode when replying, recognising the user's own address and/or expanding aliases, so sending punycode in header fieldd seems unwise. Arnt From nobody Fri Dec 22 07:34:33 2017 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 637E912EB12 for ; Fri, 22 Dec 2017 07:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=xgenplus.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 LNBJOzfar78U for ; Fri, 22 Dec 2017 07:34:31 -0800 (PST) Received: from a.tbms.in (a.tbms.in [202.157.72.21]) by ietfa.amsl.com (Postfix) with ESMTP id 558D912EB0F for ; Fri, 22 Dec 2017 07:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt; c=simple/relaxed; t=1513956864; s=xgen; d=xgenplus.com; h=Date:From:Message-ID:MIME-Version; z=Date:Fri,=2022=20Dec=202017=2021:03:46=20+0530|From:ajay@xgenplus.com|Message-ID:<395918911.542891513956864690.JavaMail.root@mx2.datainfosys.com>|MIME-Version:1.0; l=3130; bh=BXkEyvmez/5pD38hHZDQaUguEws=; b=SqFgc2v13IFlX6tGK8ri087cTKyl38kZ/HqUDp1IPol70m/XqAqTKYa2BL3Lv5rA jusr/AGXbvfUHdWVvAMkTTBAw4nfBQOxG/vXRJgrw5WREpwDYfM29Oxn2K7JtS8hDif LI1M5bx062a7tkIsC47cHHmd++MupzjTTwu7IDMo= Received: From 202.157.83.44[202.157.83.44] by [202.157.83.51] [mx2.datainfosys.com] [mta] with SMTP id ../InBoxS/20171222/21/2381.4624247449733(1513956863545); Fri, 22 Dec 2017 15:34:23 +0000 Received: From 202.157.87.20[202.157.87.20] by [202.157.87.20] [DataMailApp-2] [mta] with SMTP id 42527.78398493201(1513956863476); Fri, 22 Dec 2017 15:34:23 +0000 Received: From[9c365f6ade93d2ec480c9a39a918d5eb] [202.157.76.62] with SMTP id 39540.989139702986(1513956827626); Fri, 22 Dec 2017 15:33:47 +0000 Date: Fri, 22 Dec 2017 21:03:46 +0530 From: ajay@xgenplus.com To: arnt@gulbrandsen.priv.no Cc: jeff.sipek@dovecot.fi, neilj@fastmailteam.com, jmap@ietf.org, alexey.melnikov@isode.com, ajay@xgenplus.com Message-ID: <395918911.542891513956864690.JavaMail.root@mx2.datainfosys.com> X-SentFromIP: 192.168.0.102- Jio-wifi X_Xgen_Device_Id: BE2B7A71-BDCD-47C7-9F46-A10BB9D168C7 X-SentFromDate: 2017-12-22 15:33:46 +0000 X-Mailer: XgenPlus iOS App 4.5 X-SendType: REPLYALL X_Xgen_Delivery_Report: YES X-Priority: 3 X-BrowserType: iPhone 11.2.1 XMessage-Id: XGenPlusMessageID:40771513956826 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5a3d25da_6b8b4567_200" Archived-At: Subject: Re: [Jmap] Decoding of unknown headers X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 15:34:32 -0000 --5a3d25da_6b8b4567_200 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline I think RFC 6530 explictly talks about downgrading domain name to punycode and encoding of local part when the receipient server do not support SMTPUTF8. So i guess jmap shall deal with both thr scenerios. On 22-Dec-2017 at 21:00:36 Arnt Gulbrandsen 'arnt@gulbrandsen.priv.no' wrote: From: Arnt Gulbrandsen To: jeff.sipek@dovecot.fi, neilj@fastmailteam.com, jmap@ietf.org, Alexey Melnikov , ajay@xgenplus.com Subject: [Jmap] Decoding of unknown headers Date: 22 December 2017 at 21:00:36 IST The EAI RFCs do not specify that punycode is to be handled in any particular way, so it would be inappropriate for the JMAP document to specify more. BTW, I know that several programs ignore punycode when replying, recognising the user's own address and/or expanding aliases, so sending punycode in header fieldd seems unwise. Arnt _______________________________________________ Jmap mailing list Jmap@ietf.org https://www.ietf.org/mailman/listinfo/jmap --5a3d25da_6b8b4567_200 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I think R=46C 6530 explictly talks about downgrading domain name to= punycode and encoding of local part when the receipient server do not su= pport SMTPUT=468.

So i guess jmap shall deal with both thr scener= ios.




On 22-Dec-2017 at 21:00:36
Arnt Gulbrandse= n 'arnt=40gulbrandsen.priv.no' wrote:
=46rom: = Arnt Gulbrandsen <arnt=40gulbrandsen.priv.no>
To:= jeff.sipek=40dovecot.fi, neilj=40fastmailteam.com, jmap=40ietf.org, Alex= ey Melnikov <alexey.melnikov=40isode.com>, ajay=40xgenplus.com
Subject: =5BJmap=5D Decoding of unknown headers
= Date: 22 December 2017 at 21:00:36 IST
The = EAI R=46Cs do not specify that punycode is to be handled in any <=21--N--= >
particular way, so it would be inappropriate for the JMAP document = to <=21--N-->
specify more. <=21--N-->
<=21--N-->
BTW, I kno= w that several programs ignore punycode when <=21--N-->
replying, rec= ognising the user's own address and/or expanding aliases, <=21--N-->
= so sending punycode in header fieldd seems unwise. <=21--N-->
<=21--= N-->
Arnt <=21--N-->
<=21--N-->
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F <=21--N-->
Jmap mailing list <=21= --N-->
Jmap=40ietf.org <=21--N-->
https://www.ietf.org/mailman/li= stinfo/jmap <=21--N-->
. <=21--N-->
--5a3d25da_6b8b4567_200-- From nobody Fri Dec 22 08:59:00 2017 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 7690A12785F for ; Fri, 22 Dec 2017 08:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 lNR3qxfauUSL for ; Fri, 22 Dec 2017 08:58:56 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B131271FD for ; Fri, 22 Dec 2017 08:58:55 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 09984FA0092; Fri, 22 Dec 2017 16:58:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1513961934; bh=7xuHPFhUbSA4f2rsDmT6uzsCRmg5qjG0SxMOD52QUnU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kw4y5omIqFnDIQpHbLuKk6n2O3dt5I29M666gu4IVcV7EGxvDZuV0sk4vnbkYPNyB X+0F4pwXmFvE2aDPZ93F5hh4Q0pxmNjirUfoyAtC3urepeHhpGRXNKsFmKM77kXLE3 i0hLzupHDUr4FZNr32fZRYggeuPZcRUtuPRDV0FY= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1513961933-12346-22429/11/23; Fri, 22 Dec 2017 16:58:53 +0000 From: Arnt Gulbrandsen To: ajay@xgenplus.com Cc: jeff.sipek@dovecot.fi, neilj@fastmailteam.com, jmap@ietf.org, alexey.melnikov@isode.com Date: Fri, 22 Dec 2017 16:58:51 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <5e0e7262-001f-4730-83af-5a1b2b1bf2b1@gulbrandsen.priv.no> In-Reply-To: <1704926794.542861513956864675.JavaMail.root@mx2.datainfosys.com> References: <1704926794.542861513956864675.JavaMail.root@mx2.datainfosys.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Decoding of unknown headers X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 16:58:58 -0000 ajay@xgenplus.com writes: > I think RFC 6530 explictly talks about downgrading domain name > to punycode and encoding of local part when the receipient > server do not support SMTPUTF8. No, it talks about downgrading when the recipient does not support EAI. It never even mentions punycode. Arnt From nobody Fri Dec 22 09:34:02 2017 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 70CE4124B18 for ; Fri, 22 Dec 2017 09:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 KBmehO6hEWjA for ; Fri, 22 Dec 2017 09:33:59 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040FC124217 for ; Fri, 22 Dec 2017 09:33:58 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5A633FA0092; Fri, 22 Dec 2017 17:33:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1513964037; bh=c1UmAMmhKZ/0tx7RdHxq75iKp/MeiPIRDAEsZtDWSIs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iD8iBKVY44bw+FKxPMIpm/inATxPWnKYyyai3rhqWK3wzZkHCDp56SiIaLEIfgC7X l4VRpSW/9YfgRgNa6lDwcMNLIDDK/u2OCIwbBUQs2cNOdJkLaI64rbelNMaTZo4U9q FTm+GiE2MQiOjWrhZBL9/BkIj/U4ABCKnEnXRox4= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1513964036-12346-22429/11/24; Fri, 22 Dec 2017 17:33:56 +0000 From: Arnt Gulbrandsen To: jmap@ietf.org Date: Fri, 22 Dec 2017 17:33:56 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: <312b997f-a8da-4c74-b900-81984e5661c5@gulbrandsen.priv.no> In-Reply-To: <5e0e7262-001f-4730-83af-5a1b2b1bf2b1@gulbrandsen.priv.no> References: <1704926794.542861513956864675.JavaMail.root@mx2.datainfosys.com> <5e0e7262-001f-4730-83af-5a1b2b1bf2b1@gulbrandsen.priv.no> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Jmap] Decoding of unknown headers X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 17:34:01 -0000 I wrote: > No, it talks about downgrading when the recipient does not > support EAI. It never even mentions punycode. Maybe that needs a bit of elaboration. 6530 doesn't say "you can encode header fields using punycode when you send mail to recipients whose software apparently doesn't support SMTPUTF8", in much the same way as it doesn't say "you can encode header fields using rot13 when you send mail to recipients whose software apparently doesn't support SMTPUTF8".That's because 6530 cannot assume that such recipients have any way to decode either. Legacy software doesn't do either rot13 or punycode decoding. What 6530 does talks about is software that DOES support SMTPUTF8 and related extensions. But even for that soft of software there's nothing about punycode support in header fields. For example, look at 6855, It could have said that the when the IMAP server handles FROM/TO/CC/... search keys, it must/should decode possible punycode decoding. But it does not say that. It makes no such requirement. It doesnn't even reference the punycode RFC. Perhaps you (Ayjay) are confusing 6530 etc with the experimental and deprecated RFCs? Arnt