From nobody Sat Nov 11 20:19: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 4D6B31270A0 for ; Sat, 11 Nov 2017 20:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 hblZB5URqUEp for ; Sat, 11 Nov 2017 20:19:31 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 20E0912778D for ; Sat, 11 Nov 2017 20:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1510460370; d=isode.com; s=june2016; i=@isode.com; bh=BV1e3sIODKY9HbHYSt4NT/fcX7OlKUjD18Q1PP/1wMo=; 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=SSM5S6PR8OajCsHXuAljc0WHEde15PMzlkDoHnxpuzBE46cIXr3srMnaNvwblJmyt7AQNa mMLjmkhjpiGXJn8KLpTmegIDlrmpccL1RLFout7Td50MQVS6YRLI9IlOPaN6qu+SdYcC7x Go4nw3Hy3ZAOeCT53d0GEB2oHFgN/SA=; Received: from [31.133.129.3] (dhcp-8103.meeting.ietf.org [31.133.129.3]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 12 Nov 2017 04:19:29 +0000 To: vaibhav singh , jmap@ietf.org References: From: Alexey Melnikov Message-ID: <5A07CBCF.4090204@isode.com> Date: Sun, 12 Nov 2017 12:19:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) 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, 12 Nov 2017 04:19:32 -0000 On 29/10/2017 07:33, vaibhav singh wrote: >=20 >=20 > 1. Re: [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) > (Bron Gondwana) >=20 >=20 > ---------- Forwarded message ---------- > From: Bron Gondwana > > To: jmap@ietf.org > Cc:=20 > Bcc:=20 > Date: Thu, 26 Oct 2017 09:04:40 +1100 > Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP= ) > __ > If you want to use a JMAP server to pass opaque blobs, that works > fine. Obviously things like hasAttachment aren't going to work, > because the opaque blob doesn't have an attachment. The mail inside > may have an attachment, but the JMAP server doesn't know that. >=20 > Since the same issue exists with IMAP, it sounds like maybe what > you're suggesting is an IANA registration of a keyword like > $HasEncryptedAttachment, which would allow multiple MUAs to share > that metadata. Of course the server couldn't add it, so it would > only be present at the time the first MUA-with-keys connected and > downloaded the message to evaluate its contents. >=20 >=20 > Yes, I can start the process for requesting " $HasEncryptedAttachment > "be registered by IANA, in case nobody sees an issue with it. Please do. I can help you offline, if you need help. From nobody Sun Nov 12 21: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 01E3E128B4E for ; Sun, 12 Nov 2017 21:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 cR47Kzhuexyz for ; Sun, 12 Nov 2017 21:50:21 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D7812944B for ; Sun, 12 Nov 2017 21:50:14 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id m191so6127303itg.1 for ; Sun, 12 Nov 2017 21:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=9vJmyw5rpG0BxcFbXHzfMgGa6kvkDcXIvnPzCb9sF4k=; b=ElKpfM91SkSNbSeErDgncmIn5RQ8BHfC0WG+wswfNjboUl9ZauD5ARooEsHMA6JArd Sd1XiC1P4Ao9LWazf0NDVHelQgIufHi9XF9dxF/acjajAicIUUBKl4+GTVnkuQ5VQ6mz XWelUSMwg5AVm7Q6DbDRBaZfgl3QccsHMbkgT64phVFNuhAGKFKAGUSr5abcT/ekmF8T CyLMGFFomqTe4g9R1iCXobHnmh5+KM3C8XyuH/BmsXNvi2t2unTbNpvebc9S5uE1rDVd lpWQyPSV/RKmaJ/6SJUeYs0FTW78+qIWQoYA+TGn421eBJwxxxmDvAyHxUXUyH8x88+m lqOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=9vJmyw5rpG0BxcFbXHzfMgGa6kvkDcXIvnPzCb9sF4k=; b=TtdBNTJnJeY7z7HL1GkmXXRkI4ZJlIo/w/A2WkRqSEc9T8o9xZT4GISGdXzRetteIW qccagQqbnS7xpYHY4dlhzLi2YLKH+dWSopa2LIY2v9W1GgK0Hk1vUqoRByaGh82STLAD ychojIVh/YDawtpbbmTyDK/TnwMyArO2baCamErLYlhx+0PvoKPK39a7egX9i8O1FHaV LkFhPPE3HtPxVFPIXdSq+A5vdYxF3kSRDXBldnXH0a0YZ1FRzDRyi6YxPbDVvn+fjhkU uxuwTgIFlDNJCUq2Z7EpQT1EzJpRyO8Iki9FPkMCWGWDOWROA2WAsiPPW1TN/X8mRsMw y6tg== X-Gm-Message-State: AJaThX4N6nYgRwDd+SQMzH8Yr2trv5aF+72KQHq47XdMIRfax8vr0UY/ /Jlpl3kluYiF1NaUrLkHR6xR3L8SqlOXcsrXKI+V8Q== X-Google-Smtp-Source: AGs4zMayfXiok8mYRwi5eyVhB8VM4pmdYzz+u34ZYZDrdAP0EyzSVLl6A1JZlRf0UyciJbQMZmvxo4lZum9HAFYtSeE= X-Received: by 10.36.65.83 with SMTP id x80mr6361368ita.130.1510552213331; Sun, 12 Nov 2017 21:50:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.31.3 with HTTP; Sun, 12 Nov 2017 21:50:12 -0800 (PST) In-Reply-To: References: From: vaibhav singh Date: Mon, 13 Nov 2017 11:20:12 +0530 Message-ID: To: jmap@ietf.org Content-Type: multipart/alternative; boundary="001a11c1541e1723b2055dd6d835" Archived-At: Subject: Re: [Jmap] Jmap Digest, Vol 12, Issue 1 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: Mon, 13 Nov 2017 05:50:24 -0000 --001a11c1541e1723b2055dd6d835 Content-Type: text/plain; charset="UTF-8" > > From: Alexey Melnikov > To: vaibhav singh , jmap@ietf.org > Cc: > Bcc: > Date: Sun, 12 Nov 2017 12:19:27 +0800 > Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) > On 29/10/2017 07:33, vaibhav singh wrote: > > > > > > 1. Re: [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) > > (Bron Gondwana) > > > > > > ---------- Forwarded message ---------- > > From: Bron Gondwana > > > > To: jmap@ietf.org > > Cc: > > Bcc: > > Date: Thu, 26 Oct 2017 09:04:40 +1100 > > Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for > JMAP) > > __ > > If you want to use a JMAP server to pass opaque blobs, that works > > fine. Obviously things like hasAttachment aren't going to work, > > because the opaque blob doesn't have an attachment. The mail inside > > may have an attachment, but the JMAP server doesn't know that. > > > > Since the same issue exists with IMAP, it sounds like maybe what > > you're suggesting is an IANA registration of a keyword like > > $HasEncryptedAttachment, which would allow multiple MUAs to share > > that metadata. Of course the server couldn't add it, so it would > > only be present at the time the first MUA-with-keys connected and > > downloaded the message to evaluate its contents. > > > > > > Yes, I can start the process for requesting " $HasEncryptedAttachment > > "be registered by IANA, in case nobody sees an issue with it. > > Please do. I can help you offline, if you need help. Thanks a lot. I have requested for the keyword to be registered to IANA, and got feedback about it from Mr. Barry Leiba, following which I have put up the keyword up for discussion on imapext mailing group ( imapext-request@ietf.org). Relevant subject line on imapext is "[imapext] General Request for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)". Kindly have a look and suggest any modifications to the keyword, if needed. Thanks, Vaibhav > > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > > -- Regards, Vaibhav Singh --001a11c1541e1723b2055dd6d835 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From:=C2=A0Alexey Melnikov <alexey.melnikov@isode.com>
To:=C2=A0vaibhav si= ngh <va= ibhavsinghacads@gmail.com>, jmap@ietf.org
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Sun,= 12 Nov 2017 12:19:27 +0800
Subject:=C2=A0Re: [Jmap] [JMAP] SMIME Attach= ments (was: Re: S/MIME for JMAP)
On 29/10/2017 07:33, vaibhav singh wrot= e:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Re: [JMAP] SMIME Attachments (was: Re:= =C2=A0 S/MIME for JMAP)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Bron Gondwana)
>
>
>=C2=A0 =C2=A0 =C2=A0---------- Forwarded message ----------
>=C2=A0 =C2=A0 =C2=A0From: Bron Gondwana <brong@fastmailteam.com
>=C2=A0 =C2=A0 =C2=A0<mailto:brong@fastmailteam.com>>
>=C2=A0 =C2=A0 =C2=A0To: jmap@ietf.org <mailto:jmap@ietf.org>
>=C2=A0 =C2=A0 =C2=A0Cc:
>=C2=A0 =C2=A0 =C2=A0Bcc:
>=C2=A0 =C2=A0 =C2=A0Date: Thu, 26 Oct 2017 09:04:40 +1100
>=C2=A0 =C2=A0 =C2=A0Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: = Re: S/MIME for JMAP)
>=C2=A0 =C2=A0 =C2=A0__
>=C2=A0 =C2=A0 =C2=A0If you want to use a JMAP server to pass opaque blo= bs, that works
>=C2=A0 =C2=A0 =C2=A0fine.=C2=A0 Obviously things like hasAttachment are= n't going to work,
>=C2=A0 =C2=A0 =C2=A0because the opaque blob doesn't have an attachm= ent.=C2=A0 The mail inside
>=C2=A0 =C2=A0 =C2=A0may have an attachment, but the JMAP server doesn&#= 39;t know that.
>
>=C2=A0 =C2=A0 =C2=A0Since the same issue exists with IMAP, it sounds li= ke maybe what
>=C2=A0 =C2=A0 =C2=A0you're suggesting is an IANA registration of a = keyword like
>=C2=A0 =C2=A0 =C2=A0$HasEncryptedAttachment, which would allow multiple= MUAs to share
>=C2=A0 =C2=A0 =C2=A0that metadata.=C2=A0 Of course the server couldn= 9;t add it, so it would
>=C2=A0 =C2=A0 =C2=A0only be present at the time the first MUA-with-keys= connected and
>=C2=A0 =C2=A0 =C2=A0downloaded the message to evaluate its contents. >
>
> Yes, I can start the process for requesting " $HasEncryptedAttach= ment
> "be registered by IANA, in case nobody sees an issue with it.

Please do. I can help you offline, if you need help.=C2=A0
Thanks a lot. I have requested for the keyword to be registered to IAN= A, and got feedback about it from Mr. Barry Leiba, following which I have p= ut up the keyword up for discussion on imapext mailing group (imapext-request@ietf.org).

<= /div>
Relevant subject line on imapext is "[imapext] General Reque= st for Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)". Ki= ndly have a look and suggest any modifications to the keyword, if needed.
Thanks,
Vaibhav



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




--

Regards,
Vaibhav Singh
--001a11c1541e1723b2055dd6d835-- From nobody Mon Nov 13 01:41:41 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 3657D126D85 for ; Mon, 13 Nov 2017 01:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.792 X-Spam-Level: X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1iuOm1V93PeT for ; Mon, 13 Nov 2017 01:41:39 -0800 (PST) Received: from smtp.linagora.com (unknown [109.197.180.137]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36771126CC4 for ; Mon, 13 Nov 2017 01:41:39 -0800 (PST) Received: from extranet.linagora.com (ldap.linagora.com [172.16.18.50]) by smtp.linagora.com (Postfix) with ESMTP id B2FF1799 for ; Mon, 13 Nov 2017 10:41:39 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 13 Nov 2017 10:41:37 +0100 From: Raphael OUAZANA To: jmap@ietf.org Message-ID: X-Sender: rouazana@linagora.com User-Agent: Roundcube Webmail/1.1.4 Archived-At: Subject: [Jmap] MessageSubmission: removing of answered and forwarded flags handling 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: Mon, 13 Nov 2017 09:41:40 -0000 Hi, When sending a reply or a forward to a message, I'm wondering if updating the flags of the referenced message should be done by the server or the client. Looking at the specification, there was this part stating that this should be done by the server: https://github.com/jmapio/jmap/commit/8e7dd2556766b33993427b9c19b03af8aba520b2#diff-609b56570b975253b6c87561b11a871cL320 But as you can see, it has been removed during the MessageSubmission PR. Is this really wanted? Regards, Raphaël Ouazana. From nobody Mon Nov 13 04:38:18 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 77CA4129418 for ; Mon, 13 Nov 2017 04:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQdh2UxpcLvG for ; Mon, 13 Nov 2017 04:38:16 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2D09A129412 for ; Mon, 13 Nov 2017 04:38:16 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id E25A52B3CD8; Mon, 13 Nov 2017 14:38:13 +0200 (EET) Date: Mon, 13 Nov 2017 07:38:21 -0500 From: Josef 'Jeff' Sipek To: vaibhav singh Cc: jmap@ietf.org Message-ID: <20171113123820.GC3844@meili> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] Jmap Digest, Vol 12, Issue 1 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: Mon, 13 Nov 2017 12:38:17 -0000 On Mon, Nov 13, 2017 at 11:20:12 +0530, vaibhav singh wrote: ... > Thanks a lot. I have requested for the keyword to be registered to IANA, > and got feedback about it from Mr. Barry Leiba, following which I have put > up the keyword up for discussion on imapext mailing group ( > imapext-request@ietf.org). > > Relevant subject line on imapext is "[imapext] General Request for > Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)". Kindly have a > look and suggest any modifications to the keyword, if needed. I don't see it anywhere... 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 Mon Nov 13 04:44: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 B0124129418 for ; Mon, 13 Nov 2017 04:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekE4dTzepWWI for ; Mon, 13 Nov 2017 04:44:20 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5541512783A for ; Mon, 13 Nov 2017 04:44:20 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id 2D6AF2B3CD1; Mon, 13 Nov 2017 14:44:19 +0200 (EET) Date: Mon, 13 Nov 2017 07:44:28 -0500 From: Josef 'Jeff' Sipek To: vaibhav singh Cc: jmap@ietf.org Message-ID: <20171113124425.GD3844@meili> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) 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: Mon, 13 Nov 2017 12:44:22 -0000 On Sun, Oct 29, 2017 at 13:03:28 +0530, vaibhav singh wrote: > > > > 1. Re: [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) > > (Bron Gondwana) > > > > > > ---------- Forwarded message ---------- > > From: Bron Gondwana > > To: jmap@ietf.org > > Cc: > > Bcc: > > Date: Thu, 26 Oct 2017 09:04:40 +1100 > > Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) > > If you want to use a JMAP server to pass opaque blobs, that works fine. > > Obviously things like hasAttachment aren't going to work, because the > > opaque blob doesn't have an attachment. The mail inside may have an > > attachment, but the JMAP server doesn't know that. > > > > Since the same issue exists with IMAP, it sounds like maybe what you're > > suggesting is an IANA registration of a keyword like > > $HasEncryptedAttachment, which would allow multiple MUAs to share that > > metadata. Of course the server couldn't add it, so it would only be > > present at the time the first MUA-with-keys connected and downloaded the > > message to evaluate its contents. > > > > Yes, I can start the process for requesting " $HasEncryptedAttachment "be > registered by IANA, in case nobody sees an issue with it. Is the idea that $HasEncryptedAttachment would be set on S/MIME only emails? Or PGP as well? (RFC 3156 comes to mind) Jeff. -- I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. - Bjarne Stroustrup From nobody Mon Nov 13 04:53: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 DA319129422 for ; Mon, 13 Nov 2017 04:53: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 D3Xiz2dacjkE for ; Mon, 13 Nov 2017 04:53:21 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id E772612941C for ; Mon, 13 Nov 2017 04:53:20 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id D0F242B3CD1 for ; Mon, 13 Nov 2017 14:53:19 +0200 (EET) Date: Mon, 13 Nov 2017 07:53:27 -0500 From: Josef 'Jeff' Sipek To: jmap@ietf.org Message-ID: <20171113125326.GE3844@meili> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: [Jmap] hasAttachment vs. keywords 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: Mon, 13 Nov 2017 12:53:22 -0000 I was thinking about keywords in jmap, and I realized that the hasAttachment message property seems a bit special-cased and that it could be trivially replaced by a $HasAttachment keyword. (I don't care what exactly it is called.) This keyword would also nicely line up with the proposed $HasEncryptedAttachment keyword, and it would allow IMAP servers to expose it as well with little to no effort. Jeff. -- Research, n.: Consider Columbus: He didn't know where he was going. When he got there he didn't know where he was. When he got back he didn't know where he had been. And he did it all on someone else's money. From nobody Mon Nov 13 07:14: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 147D5129ADD for ; Mon, 13 Nov 2017 07:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 NLR_2tOJMAyT for ; Mon, 13 Nov 2017 07:14:18 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01680129421 for ; Mon, 13 Nov 2017 07:14:17 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id y15so9771741ita.4 for ; Mon, 13 Nov 2017 07:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=NQ6KkOscx5tQJOXhqU9nk/Fe1Tc5Rxg+Q8JbVEpZtR8=; b=gA6ya5zTzm4GzKP/qG5Ds0/RI9X9XF5MhbAbY+yk6dAK+vWLXttx53oxCC7qzvS3/E aU2gE5MG4Jdt++2dd/FmawLt87ZeAvkrrB9m3DOMx3B/MKCczL9YI5FuORB49LO/rOkg P4l5LYi5Pp8Oy10TaX79EB5JQPuqhBEgSqRq2V05odQWq6u5J3dLA7sxK6wV7wAPs7qi ZnDPg4Ibu/Amd6C03eIlv5mp6x8fQ6ylhDxZL7hX5siyt9xpRla4kZmCKP3v+whuwR6W gsLfOHL7xIhlgFINIopgyMW3ZzxGZG34BDDbey19/i2ieHJ7FaXoDteE91PRGAMXo61b ud1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=NQ6KkOscx5tQJOXhqU9nk/Fe1Tc5Rxg+Q8JbVEpZtR8=; b=TIqgrqH5Ccd2+sfdCxLvvRF7wt7zl1rCdTIs2yS0rq11gD5ItuED0IuE33+7/izuLD Cs/ngl3Y5HUsozeZEWod7079PnM6z5vTvFepIavdtwnpZFOJhF1rAymWq96gtookiHTb OVFzpS9Dl8vCrHVWbbdQcIsiTGmsGYXJgrBMk8Sp1oZ7gSA9+Jxx/7p+9JiR1ZHM5PWn g6uEoh2K117eCpVXLy1/dF8jmtxEBZL9lJLDrD3/ISA8htCF8Xg1FhFM69uoxLLxrka1 x1oyDS3Q+GkCNsYi2uj5llXmcPhEgiHSBBquWbdclzpbZxZabFsfq5EtlEJ1v8t4A+oD UAVA== X-Gm-Message-State: AJaThX6MpIL8tDn8wPnzJqJTwlGJENipttL3nFfpd7D47o46vlEngrik jccRHZg7c4+pHQLCMobXgqxluAnELa37VYcbkONCvA== X-Google-Smtp-Source: AGs4zMYefyus61TG3Mw5ZD6fQvnGyxdsoYTia+VedvnoS4032HWjKgkIzlGo46dVATSvcAP/M0dJpBn5h36STZh9+70= X-Received: by 10.36.65.83 with SMTP id x80mr7907716ita.130.1510586057103; Mon, 13 Nov 2017 07:14:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.31.3 with HTTP; Mon, 13 Nov 2017 07:14:16 -0800 (PST) In-Reply-To: <1510579374724.424952967@boxbe> References: <1510579374724.424952967@boxbe> From: vaibhav singh Date: Mon, 13 Nov 2017 20:44:16 +0530 Message-ID: To: jmap@ietf.org Content-Type: multipart/alternative; boundary="001a11c1541e561e55055ddeb910" Archived-At: Subject: Re: [Jmap] Jmap Digest, Vol 12, Issue 1 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: Mon, 13 Nov 2017 15:14:21 -0000 --001a11c1541e561e55055ddeb910 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 13, 2017 at 6:08 PM, Josef 'Jeff' Sipek wrote: > [image: Boxbe] Josef 'Jeff' Sipek ( > jeff.sipek@dovecot.fi) is not on your Guest List > > | Approve sender > > | Approve domain > > > On Mon, Nov 13, 2017 at 11:20:12 +0530, vaibhav singh wrote: > ... > > Thanks a lot. I have requested for the keyword to be registered to IANA= , > > and got feedback about it from Mr. Barry Leiba, following which I have > put > > up the keyword up for discussion on imapext mailing group ( > > imapext-request@ietf.org). > > > > Relevant subject line on imapext is "[imapext] General Request for > > Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)". Kindly hav= e > a > > look and suggest any modifications to the keyword, if needed. > > I don't see it anywhere... > > Jeff. > Whoops, accidently sent the request to imapext-request@ietf.org, should have sent it to imapext@ietf.org. Have resent the request to the correct mailing list now. Thanks for pointing it out. -Vaibhav > > -- > All parts should go together without forcing. You must remember that the > parts you are reassembling were disassembled by you. Therefore, if you > can=C3=A2=E2=82=AC=E2=84=A2t get them together again, there must be a rea= son. By all means, do > not > use a hammer. > =C3=A2=E2=82=AC=E2=80=9D IBM Manual, 1925 > > --001a11c1541e561e55055ddeb910 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Nov 13, 2017 at 6:08 PM, Josef 'Jeff' Sipek <jef= f.sipek@dovecot.fi> wrote:

On Mon, Nov 13, 2017 at 11:20:12 +0530, vaibhav singh wrote:
...
> Thanks a lot. I have requested for the keyword to be registered to IAN= A,
> and got feedback about it from Mr. Barry Leiba, following which I have= put
> up the keyword up for discussion on imapext mailing group (
> imapext-request@ietf.org).
>
> Relevant subject line on imapext is "[imapext] General Request fo= r
> Assignment (imap-keywords) (was: [JMAP] SMIME Attachments)". Kind= ly have a
> look and suggest any modifications to the keyword, if needed.

I don't see it anywhere...

Jeff.

Whoops, accidently sent the reque= st to imapext-request@ietf.org<= /a>, should have sent it to imapext@iet= f.org. Have resent the request to the correct mailing list now. Thanks = for pointing it out.
-Vaibhav

--
All parts should go together without forcing.=C2=A0 You must remember that = the
parts you are reassembling were disassembled by you.=C2=A0 Therefore, if yo= u
can=C3=A2=E2=82=AC=E2=84=A2t get them together again, there must be a reaso= n.=C2=A0 By all means, do not
use a hammer.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C3=A2=E2=82=AC=E2= =80=9D IBM Manual, 1925


--001a11c1541e561e55055ddeb910-- From nobody Mon Nov 13 07:21:41 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 50119129AE9 for ; Mon, 13 Nov 2017 07:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 8xYv3kGO1W9C for ; Mon, 13 Nov 2017 07:21:37 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C7C129449 for ; Mon, 13 Nov 2017 07:21:37 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id x63so8790068ioe.6 for ; Mon, 13 Nov 2017 07:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4eYA+WtEigPQ5b9y5c+98iQ21nm+LILVTDnbHL82He4=; b=RO+qGAaL2pKy6F0Zole9LW27N7GlWOBmqhBLw7NWMrNPXEmkSCQb9mWzuZUqAsuZty hCPYoXkco0raxWR4y+0Y0pVv5zYTxK5DCDKqSfBz/aBuuL9JenhuH6ocWBsdn4ZN9XBJ 906uDBlAOQqLLPvu4COe2Asar0cFqYyR0jXFBdQNT6M+OpdAxpK8JHJ8la94bNLgFm/m cwJ6l9jvpkzwkhj46biK8Zc0mCvXwNPZ3dwHsuMpyzAtVCpSzb2L/vo0Z5b5DqeaBsQK TqV+kgnN14euqmNlgDQzswnGFOW1wt/GwvKTVBglT9TfmhgVaxto+xsJZlqsUjcNmT5q tqvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4eYA+WtEigPQ5b9y5c+98iQ21nm+LILVTDnbHL82He4=; b=VENixkWHmInIovypwvLLODVHuTRneXBfIweVTA1zwNMbSHgTO9cB5ZgMo9S5QgsQvf 3ZwmsJdNZso+/wotYswWMtq8ATFTUnMPS2ME0gaqGaqnIs6sjzDdRxuPwuZb8Dlo4Csm nJ1MkQbuZ/KR2BMB1guUsL9yfyYmyhGnQ5jK85Af+gOOmZCd4ygFCqtl86jSMoLT4UnJ 6UHgDxepBLAWIctTLJ46e49cidu1kyX1PV0wxhvrsYV4gRUQey9GlKDbJbgUbBfZTv+W uACyUP/BsZr3vZad5vP8+c02BlgUQq12MVhrbEaAxlp6W9IjuG6fRBUqSg+qcwD1+tTA KgXw== X-Gm-Message-State: AJaThX6M5P+PNiuvolhJSV8WvKTLkER6J3sHQ8MZMdZU5RcRWbLNOGJP PMjtdu2r9KlcHlALsrI7aX5e0xD6Zv2uAD48KQ0= X-Google-Smtp-Source: AGs4zMYpGU/O47OLNjnC9ZpsOOirU8pZFsnpMA7fPy7JbRKs5XhD8HGIbG9zriJFHe2xcruhMzzfI7pfGXH2uCYLjck= X-Received: by 10.107.178.135 with SMTP id b129mr605081iof.276.1510586496221; Mon, 13 Nov 2017 07:21:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.31.3 with HTTP; Mon, 13 Nov 2017 07:21:35 -0800 (PST) From: vaibhav singh Date: Mon, 13 Nov 2017 20:51:35 +0530 Message-ID: To: jmap@ietf.org Content-Type: multipart/alternative; boundary="001a114c9d0c8285c5055dded32d" Archived-At: Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) 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: Mon, 13 Nov 2017 15:21:39 -0000 --001a114c9d0c8285c5055dded32d Content-Type: text/plain; charset="UTF-8" > > ---------- Forwarded message ---------- > From: "Josef 'Jeff' Sipek" > To: vaibhav singh > Cc: jmap@ietf.org > Bcc: > Date: Mon, 13 Nov 2017 07:44:28 -0500 > Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) > On Sun, Oct 29, 2017 at 13:03:28 +0530, vaibhav singh wrote: > > > > > > 1. Re: [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) > > > (Bron Gondwana) > > > > > > > > > ---------- Forwarded message ---------- > > > From: Bron Gondwana > > > To: jmap@ietf.org > > > Cc: > > > Bcc: > > > Date: Thu, 26 Oct 2017 09:04:40 +1100 > > > Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP) > > > If you want to use a JMAP server to pass opaque blobs, that works fine. > > > Obviously things like hasAttachment aren't going to work, because the > > > opaque blob doesn't have an attachment. The mail inside may have an > > > attachment, but the JMAP server doesn't know that. > > > > > > Since the same issue exists with IMAP, it sounds like maybe what you're > > > suggesting is an IANA registration of a keyword like > > > $HasEncryptedAttachment, which would allow multiple MUAs to share that > > > metadata. Of course the server couldn't add it, so it would only be > > > present at the time the first MUA-with-keys connected and downloaded > the > > > message to evaluate its contents. > > > > > > > Yes, I can start the process for requesting " $HasEncryptedAttachment "be > > registered by IANA, in case nobody sees an issue with it. > > Is the idea that $HasEncryptedAttachment would be set on S/MIME only > emails? > Or PGP as well? (RFC 3156 comes to mind) > > Jeff. > The keyword could be used for PGP as well, unless someone sees some issue I have not thought about. Thanks, Vaibhav --001a114c9d0c8285c5055dded32d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=

---------- Forwarded message ----------<= br>From:=C2=A0"Josef 'Jeff' Sipek" <jeff.sipek@dovecot.fi>
To:=C2=A0vaibhav si= ngh <vaibhavsinghacads@gm= ail.com>
Cc:=C2=A0jmap@ietf.org<= /a>
Bcc:=C2=A0
Date:=C2=A0Mon, 13 Nov 2017 07:44:28 -0500
Subject:= =C2=A0Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for JMAP)
On = Sun, Oct 29, 2017 at 13:03:28 +0530, vaibhav singh wrote:
> >
> >=C2=A0 =C2=A0 1. Re: [JMAP] SMIME Attachments (was: Re:=C2=A0 S/MI= ME for JMAP)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(Bron Gondwana)
> >
> >
> > ---------- Forwarded message ----------
> > From: Bron Gondwana <brong@fastmailteam.com>
> > To: jmap@ietf.org
> > Cc:
> > Bcc:
> > Date: Thu, 26 Oct 2017 09:04:40 +1100
> > Subject: Re: [Jmap] [JMAP] SMIME Attachments (was: Re: S/MIME for= JMAP)
> > If you want to use a JMAP server to pass opaque blobs, that works= fine.
> > Obviously things like hasAttachment aren't going to work, bec= ause the
> > opaque blob doesn't have an attachment.=C2=A0 The mail inside= may have an
> > attachment, but the JMAP server doesn't know that.
> >
> > Since the same issue exists with IMAP, it sounds like maybe what = you're
> > suggesting is an IANA registration of a keyword like
> > $HasEncryptedAttachment, which would allow multiple MUAs to share= that
> > metadata.=C2=A0 Of course the server couldn't add it, so it w= ould only be
> > present at the time the first MUA-with-keys connected and downloa= ded the
> > message to evaluate its contents.
> >
>
> Yes, I can start the process for requesting " $HasEncryptedAttach= ment "be
> registered by IANA, in case nobody sees an issue with it.

Is the idea that $HasEncryptedAttachment would be set on S/MIME only emails= ?
Or PGP as well?=C2=A0 (RFC 3156 comes to mind)

Jeff.

The keyword could be used for PGP= as well, unless someone sees some issue I have not thought about.

Thanks,
Vaibhav
--001a114c9d0c8285c5055dded32d-- From nobody Mon Nov 13 18:57: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 89BD4129AFE for ; Mon, 13 Nov 2017 18:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=fastmailteam.com header.b=tPPWxF8g; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QFitonk0 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 4I23Dy5v4Ac3 for ; Mon, 13 Nov 2017 18:57:23 -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 AC2F512944C for ; Mon, 13 Nov 2017 18:57:23 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 2866620DD3 for ; Mon, 13 Nov 2017 21:57:23 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 13 Nov 2017 21:57:23 -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=YL8X2xc7sTG4FHTl9 C0hQ+t8XwGGzSlgZObI5oBqlLg=; b=tPPWxF8g1xlVBhN7iR1h8NZhxTjEQ/Vcf 8V63r+iWqPKPq+lSetNgu0S2hlagE9eG3gtzEGqSMGJEOcU6qgL1lZ7HoQtVfCvU Th957bD5JFycaF7inoogp0YCNGikbkDsnvibj4+XMrmtuPoXEQqPMIBd9S6/bN/w RsG1EUZ++/FxpGnx8vHtS+obj0jiwkcRI590F4AlrT1l4zV9uild2EG0Ny3Iubyf hx8B1/tYhxsDLe1JEp75/I0yLdaHDsSeQFJ/V0XJjrphMVAbNHHZ1M7+DInv4fVj Et3Dzv9nbNi9wm388v7HEiK6Vzdm6qeu0eEog8Ekyew69TMW/9Q4g== 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=YL8X2x c7sTG4FHTl9C0hQ+t8XwGGzSlgZObI5oBqlLg=; b=QFitonk06xPHLygMHMhKsQ u7SnfZ9eLMsY7EwulDfJUhDpuWL5XJQFbxSYNieJlPfdWg4qrQTVw026fPh0eob/ wotlSHfo/g+UGXkPhugCGrvuYm+QTzLgt6wj12t5qGVMKjIShHoJLdo+l7UASn9U /KctOGI/JcUGIEJ8GJO48XouYCNDZ74X5PESBMM6OA8b3S2TGYNZj1fe7cglfc/j AUXu8N/Hy/LWaLNuFAa5KBPJ8i7LIZJMsAM4ng5TkgcaKw2JjaPq9gmdrQRWQVfk T7wALhIAeCKyV0gfIpYV9EPBGEZ8ENCqEl0FdcOQUqqC62qtZvfGpPYbFis7PcAw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id DC3B5E270D; Mon, 13 Nov 2017 21:57:22 -0500 (EST) Message-Id: <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151062824213384684" X-Mailer: MessagingEngine.com Webmail Interface - ajax-70982e4c References: <20171113125326.GE3844@meili> Date: Tue, 14 Nov 2017 10:57:22 +0800 In-Reply-To: <20171113125326.GE3844@meili> Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 14 Nov 2017 02:57:25 -0000 This is a multi-part message in MIME format. --_----------=_151062824213384684 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" The issue with using a keyword is that if it's not guaranteed to be set by the server on message creation the client can't rely on it. Most clients display an indication of whether a message has an attachment when listing the contents of a mailbox/search, and the hasAttachment property provides an efficient way to fetch this information without having to download more until the user opens the message. If this doesn't match what the user sees when they open the full message, it's a bug. So if you can't rely on the keyword, the client would have to fetch the full *attachments* property for each message just to show the listing, and the keyword is irrelevant. This feeds into the Message object format discussion which is on the agenda for the session on Thursday. Generally this comes down to MIME being a tree of documents, but all email clients presenting a model of display body + attachments. Given this, I believe it makes more sense for the Message object format to be closer to the model used in clients rather than a simple JSON interpretation of MIME. This still leaves open questions such as what MIME parts should be considered "attachments" and what parts are "body" (should be displayed immediately inline when opening the message)? I think we might want to not prescribe a precise algorithm for this, but rather provide a specification of intent, with guidance for implementors on what they might want to consider. For example, at FastMail our current algorithm for this is roughly: * Consider each MIME part, recursing into multipart/* * Ignore images < 600px in either dimension in either a multipart/related or multipart/alternative (because Outlook screws this up); they're probably an inline header/logo. * Otherwise, the part is an attachment if any of: * it's not text (according to MIME-Type) * it has a filename (from Content-Disposition) * it has Disposition-Type of "attachment" Note, this algorithm means that if you embed a large(ish) image into an HTML message, we still show a "has attachment" icon and include it in searches for has:attachment. This is clearly a judgement call, but it captures the common case of users sending each others images which happen to be shown inline, but also may be considered a downloadable resource by the recipient. Neil. --_----------=_151062824213384684 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
The issue with using a keyword is that if it's not guaranteed to be set by the server on message creation the client can't rely on it. Most clients display an indication of whether a message has an attachment when listing the contents of a mailbox/search, and the hasAttachment property provides an efficient way to fetch this information without having to download more until the user opens the message. If this doesn't match what the user sees when they open the full message, it's a bug. So if you can't rely on the keyword, the client would have to fetch the full attachments property for each message just to show the listing, and the keyword is irrelevant.

This feeds into the Message object format discussion which is on the agenda for the session on Thursday. Generally this comes down to MIME being a tree of documents, but all email clients presenting a model of display body + attachments. Given this, I believe it makes more sense for the Message object format to be closer to the model used in clients rather than a simple JSON interpretation of MIME.

This still leaves open questions such as what MIME parts should be considered "attachments" and what parts are "body" (should be displayed immediately inline when opening the message)? I think we might want to not prescribe a precise algorithm for this, but rather provide a specification of intent, with guidance for implementors on what they might want to consider. For example, at FastMail our current algorithm for this is roughly:

  • Consider each MIME part, recursing into multipart/*
  • Ignore images < 600px in either dimension in either a multipart/related or multipart/alternative (because Outlook screws this up); they're probably an inline header/logo.
  • Otherwise, the part is an attachment if any of:
    • it's not text (according to MIME-Type)
    • it has a filename (from Content-Disposition)
    • it has Disposition-Type of "attachment"

Note, this algorithm means that if you embed a large(ish) image into an HTML message, we still show a "has attachment" icon and include it in searches for has:attachment. This is clearly a judgement call, but it captures the common case of users sending each others images which happen to be shown inline, but also may be considered a downloadable resource by the recipient.

Neil.
--_----------=_151062824213384684-- From nobody Tue Nov 14 06:32: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 493A7126C89 for ; Tue, 14 Nov 2017 06:32:25 -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 m1ejZmO2YhmD for ; Tue, 14 Nov 2017 06:32:24 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 03559124B0A for ; Tue, 14 Nov 2017 06:32:23 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id 9E56C2B3CD1; Tue, 14 Nov 2017 16:32:22 +0200 (EET) Date: Tue, 14 Nov 2017 09:32:21 -0500 From: Josef 'Jeff' Sipek To: Neil Jenkins Cc: IETF JMAP Mailing List Message-ID: <20171114143220.GC1733@meili> References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 14 Nov 2017 14:32:25 -0000 On Tue, Nov 14, 2017 at 10:57:22 +0800, Neil Jenkins wrote: > The issue with using a keyword is that if it's not guaranteed to be set > by the server on message creation the client can't rely on it. Agreed, but the same applies to the hasAttachment property. The server must set it on creation or the client can't rely on it. (Of course the server can be lazy about it either way.) I was assuming that the server would set $HasAttachment/$HasNoAttachment and $HasEncryptedAttachment/$HasNoEncryptedAttachment on creation as necessary. Not doing it automatically, would make the keywords a bit useless and the protocol inefficient. > This feeds into the Message object format discussion which is on the > agenda for the session on Thursday. FWIW, datatracker doesn't seem to have any info about the agenda. > Generally this comes down to MIME > being a tree of documents, but all email clients presenting a model of > display body + attachments. Given this, I believe it makes more sense > for the Message object format to be closer to the model used in clients > rather than a simple JSON interpretation of MIME. I don't think the two are mutually exclusive. By the way, it looks like many non-IMAP clients already have to deal with per-parsed MIME structures anyway, since the gmail API seems to provide raw blobs and pre-parsed MIME but not a higher-level concept like "attachments". ... > For example, at FastMail our current algorithm for this is roughly: ... > Note, this algorithm means that if you embed a large(ish) image into an > HTML message, we still show a "has attachment" icon and include it in > searches for has:attachment. This is clearly a judgement call, but it > captures the common case of users sending each others images which > happen to be shown inline, but also may be considered a downloadable > resource by the recipient. Given the higher-level attachment API, this seems like a reasonable algorithm. Assuming the attachment API remains, I'm ok with not specifying it as required behavior, but rather as guidance. Jeff. -- If I have trouble installing Linux, something is wrong. Very wrong. - Linus Torvalds From nobody Tue Nov 14 06:46:51 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 08A2012426E for ; Tue, 14 Nov 2017 06:46:49 -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 CZKJnglS0wEi for ; Tue, 14 Nov 2017 06:46:43 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 101AB1241FC for ; Tue, 14 Nov 2017 06:46:43 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id C79452B3CD1; Tue, 14 Nov 2017 16:46:41 +0200 (EET) Date: Tue, 14 Nov 2017 09:46:38 -0500 From: Josef 'Jeff' Sipek To: Neil Jenkins Cc: IETF JMAP Mailing List Message-ID: <20171114144637.GD1733@meili> References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <20171114143220.GC1733@meili> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171114143220.GC1733@meili> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 14 Nov 2017 14:46:49 -0000 On Tue, Nov 14, 2017 at 09:32:21 -0500, Josef 'Jeff' Sipek wrote: > On Tue, Nov 14, 2017 at 10:57:22 +0800, Neil Jenkins wrote: > > The issue with using a keyword is that if it's not guaranteed to be set > > by the server on message creation the client can't rely on it. > > Agreed, but the same applies to the hasAttachment property. The server must > set it on creation or the client can't rely on it. (Of course the server > can be lazy about it either way.) > > I was assuming that the server would set $HasAttachment/$HasNoAttachment and > $HasEncryptedAttachment/$HasNoEncryptedAttachment on creation as necessary. I just saw the discussion on imapext... I suppose the server may not be able to set $HasEncryptedAttachment/$HasNoEncryptedAttachment because of not having the keys. However, I don't think this changes anything about $HasAttachment/$HasNoAttachment. Jeff. -- Ready; T=0.01/0.01 09:44:37 From nobody Tue Nov 14 22:59: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 2F55F12951F for ; Tue, 14 Nov 2017 22:59:21 -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, 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, 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=n/M5McrJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NqdZvnly 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 4Ea-aHxKJIwP for ; Tue, 14 Nov 2017 22:59:19 -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 C01CC1270A0 for ; Tue, 14 Nov 2017 22:59:19 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 299D220A86; Wed, 15 Nov 2017 01:59:19 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 15 Nov 2017 01:59:19 -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=fIQBZD rrW8Z1qWhox+KPGGkTyKzUfQrR34XgCKay/Cg=; b=n/M5McrJR4mRHYh25XfHrF ovR8cWryhxZHxqzY3hu+Ecq0uHILc0KXjBhHzruLhjQfrXtjkybMp81pc0n7CY24 yG4KYWFYWvslsiZQR/B945IH8frxuKqllGEBJ6Pcb4LJ4XFPggvzZml358o59lfL wbH8gGmib1YaFNu63smXACR2P3DlZQ+r5raK/9DmUyQQofUVFZ2/gOZ4vF/ekBnW BHDZRt127n/J/WDWcaMrn6z/T3KGw1fB3Ufd44Zii7QNo4cCUDvUbA9//q2FCC/0 3MTFuYKRT37UTlkvuyDzxBJqE5zEa6td1GTGCdqzWhBysFAIBmgZ2uU4jT4xEF6A == 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=fIQBZD rrW8Z1qWhox+KPGGkTyKzUfQrR34XgCKay/Cg=; b=NqdZvnlywvSii2xhCuxEI+ Cj7S1d+D5H9Yru3S+5K20TrOIlCJHbjAYVyzg0bsYDsByvau13X0xWLxqJzeunev Lr8H9lkcK7bTp4mViS1DFzLuEqeU5XsASw1VnRFBLp8FNRkHi4uiYIlVI8W1Q6zN Oie6qnNFDR5gOkZvCFT9SK9590dd1aA7TT0iCLmYnE5A+2iZlrDLxir69/eVSLep Rc9lNDJvjCM/8V5RRSx5/Z46vck1e2pTfhGSRrCQlSsdsoNLQf/djOem16szxVoQ z88kLMcd1hP7YBIXKrdk+SZy6s0iQ5XpfXSnX97A3b6pqc4JLM0giAdgoj8VJn5Q == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D6F7CE2998; Wed, 15 Nov 2017 01:59:18 -0500 (EST) Message-Id: <1510729158.2694898.1173023256.3EF17092@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="_----------=_151072915826948981" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bd3ce600 Date: Wed, 15 Nov 2017 14:59:18 +0800 References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <20171114143220.GC1733@meili> In-Reply-To: <20171114143220.GC1733@meili> Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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: Wed, 15 Nov 2017 06:59:21 -0000 This is a multi-part message in MIME format. --_----------=_151072915826948981 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 14 Nov 2017, at 10:32 PM, Josef 'Jeff' Sipek wrote: > On Tue, Nov 14, 2017 at 10:57:22 +0800, Neil Jenkins wrote: >> The issue with using a keyword is that if it's not guaranteed >> to be set>> by the server on message creation the client can't rely on it. > > Agreed, but the same applies to the hasAttachment property. > The server> must set it on creation or the client can't rely on it. It's different because (as currently specified) hasAttachment is not a mutable property (metadata); it's a part of the parsed representation of the (immutable) RFC5322. So by definition, it must be present if the client tries to fetch it (I agree it could be lazily computed by the server, but you also need to know it to be able to return the response to getMessageList if filter =={ hasAttachment: true }, so you probably want to do it on delivery). > FWIW, datatracker doesn't seem to have any info about the agenda. Sorry about that; Bron has now finally uploaded it: https://datatracker.ietf.org/meeting/100/materials/agenda-100-jmap/ >> Generally this comes down to MIME >> being a tree of documents, but all email clients presenting a >> model of>> display body + attachments. Given this, I believe it makes more sense>> for the Message object format to be closer to the model used in >> clients>> rather than a simple JSON interpretation of MIME. > > I don't think the two are mutually exclusive. It's possibly to offer both in some way based on different properties the client can optionally choose to fetch. That's one option we should consider as part of the discussion on this. Neil. --_----------=_151072915826948981 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 14 Nov 2017, at 10:32 PM, Josef 'Jeff' Sipek wrote:
On Tue, Nov 14, 2017 at 10:57:22 +0800, Neil Jenkins wrote:
The issue with using a keyword is that if it's not guaranteed to be set
by the server on message creation the client can't rely on it.

Agreed, but the same applies to the hasAttachment property.  The server
must set it on creation or the client can't rely on it.

It's different because (as currently specified) hasAttachment is not a mutable property (metadata); it's a part of the parsed representation of the (immutable) RFC5322. So by definition, it must be present if the client tries to fetch it (I agree it could be lazily computed by the server, but you also need to know it to be able to return the response to getMessageList if filter =={ hasAttachment: true }, so you probably want to do it on delivery).

FWIW, datatracker doesn't seem to have any info about the agenda.

Sorry about that; Bron has now finally uploaded it: https://datatracker.ietf.org/meeting/100/materials/agenda-100-jmap/

Generally this comes down to MIME
being a tree of documents, but all email clients presenting a model of
display body + attachments. Given this, I believe it makes more sense
for the Message object format to be closer to the model used in clients
rather than a simple JSON interpretation of MIME.

I don't think the two are mutually exclusive.

It's possibly to offer both in some way based on different properties the client can optionally choose to fetch. That's one option we should consider as part of the discussion on this.

Neil.
--_----------=_151072915826948981-- From nobody Wed Nov 15 06:48:47 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 512DC127A90 for ; Wed, 15 Nov 2017 06:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE6DhbvmU3ab for ; Wed, 15 Nov 2017 06:48:43 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id A7A9A120713 for ; Wed, 15 Nov 2017 06:48:43 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id CC4182B3CD1; Wed, 15 Nov 2017 16:48:41 +0200 (EET) Date: Wed, 15 Nov 2017 09:48:37 -0500 From: Josef Jeff Sipek To: Neil Jenkins Cc: IETF JMAP Mailing List Message-ID: <20171115144837.GB17058@meili> References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <20171114143220.GC1733@meili> <1510729158.2694898.1173023256.3EF17092@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1510729158.2694898.1173023256.3EF17092@webmail.messagingengine.com> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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: Wed, 15 Nov 2017 14:48:45 -0000 On Wed, Nov 15, 2017 at 14:59:18 +0800, Neil Jenkins wrote: > On Tue, 14 Nov 2017, at 10:32 PM, Josef 'Jeff' Sipek wrote: > > On Tue, Nov 14, 2017 at 10:57:22 +0800, Neil Jenkins wrote: > >> The issue with using a keyword is that if it's not guaranteed > >> to be set>> by the server on message creation the client can't rely on it. > > > > Agreed, but the same applies to the hasAttachment property. > > The server> must set it on creation or the client can't rely on it. > > It's different because (as currently specified) hasAttachment is not a > mutable property (metadata); it's a part of the parsed representation of > the (immutable) RFC5322. So by definition, it must be present if the > client tries to fetch it Conceptually, I don't see a problem with the server setting keywords on delivery. Making the $hasAttachment keyword immutable feels a bit dirty, but it would work. Another option would be to leave it mutable and if a client messes with it... well, it gets what it asked for. ... > > FWIW, datatracker doesn't seem to have any info about the agenda. > > Sorry about that; Bron has now finally uploaded it: > https://datatracker.ietf.org/meeting/100/materials/agenda-100-jmap/ Thanks. > >> Generally this comes down to MIME > >> being a tree of documents, but all email clients presenting a > >> model of>> display body + attachments. Given this, I believe it makes more sense>> for the Message object format to be closer to the model used in > >> clients>> rather than a simple JSON interpretation of MIME. > > > > I don't think the two are mutually exclusive. > > It's possibly to offer both in some way based on different properties > the client can optionally choose to fetch. That's one option we should > consider as part of the discussion on this. Agreed. Jeff. -- Fact: 97.4% of all statistics are generated randomly. From nobody Wed Nov 15 07:35:29 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 16EFA1204DA for ; Wed, 15 Nov 2017 07:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.293 X-Spam-Level: X-Spam-Status: No, score=0.293 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 YQonHu8KFGSh for ; Wed, 15 Nov 2017 07:35:26 -0800 (PST) Received: from smtp.linagora.com (unknown [109.197.180.137]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367631200FC for ; Wed, 15 Nov 2017 07:35:25 -0800 (PST) Received: from extranet.linagora.com (ldap.linagora.com [172.16.18.50]) by smtp.linagora.com (Postfix) with ESMTP id BEAF92656 for ; Wed, 15 Nov 2017 16:35:25 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 15 Nov 2017 16:35:23 +0100 From: Raphael OUAZANA To: jmap@ietf.org In-Reply-To: References: Message-ID: X-Sender: rouazana@linagora.com User-Agent: Roundcube Webmail/1.1.4 Archived-At: Subject: Re: [Jmap] MessageSubmission: removing of answered and forwarded flags handling 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: Wed, 15 Nov 2017 15:35:28 -0000 Hi, Le 2017-11-13 10:41, Raphael OUAZANA a écrit : > Hi, > > When sending a reply or a forward to a message, I'm wondering if > updating the flags of the referenced message should be done by the > server or the client. > > Looking at the specification, there was this part stating that this > should be done by the server: > > https://github.com/jmapio/jmap/commit/8e7dd2556766b33993427b9c19b03af8aba520b2#diff-609b56570b975253b6c87561b11a871cL320 > > But as you can see, it has been removed during the MessageSubmission > PR. > Is this really wanted? I finally got my answer. It is a mix between client side and server side, as client should explicitly ask server to do the operation with a hook (onSuccessUpdateMessage or onSuccessDestroyMessage). Regards, Raphaël Ouazana. From nobody Wed Nov 15 18:45: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 53B96129407 for ; Wed, 15 Nov 2017 18:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=fastmailteam.com header.b=paOHaz+r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hdKkHFu/ 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 tBpOJKf_0zIe for ; Wed, 15 Nov 2017 18:45:00 -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 75329126CC4 for ; Wed, 15 Nov 2017 18:45:00 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id A49D420BEE; Wed, 15 Nov 2017 21:44:59 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 15 Nov 2017 21:44: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=gFSjs5 +c48JDvPtIIZAyt81GmcrdkmLqbu0N0ndKI1g=; b=paOHaz+r/G3X0/mEBgbxjc fvYCnPJfNNK2KT2ClNXP1h5/MGpY7tdoYc710GWrjZCYTLpEYNx3Zk3ZsHTJOYAi vURnBiUNXhhg8BAcVmWjsShuNCP6NeoslJV1BVh0FY3O46CZUlCMKgOcp0xIqy3Z tRD2VoZBasCsOkaXK9VNYLhJ6CVt2Ba0b9dVdkv9eodUeA0ltOkGZDttKX8GvtfV kbE36NK+rOfKM2l7/O+JxW4DZgQPKSFcnobgQANf0CZrXNeGIsoOKYziXkmCcafW +JSWeHBturJM96yObgWofZk3fuon4mHoGAAyK0ShmVjxKgqhxSdbPJ567AaYXgqg == 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=gFSjs5 +c48JDvPtIIZAyt81GmcrdkmLqbu0N0ndKI1g=; b=hdKkHFu/Wztl/qADKhnfm4 47iA3ja7XyWgjMHst4MZBxIGgnuoR8CpTATF20nI1vKGobBIKMyyeWpKZTspL066 sbjzquL1SLFyDgI9QS1ukF1lIuThYB4zxTPGE6w3A3W6Bpc4iZkEYaCF3P9s+R0y og5ivQeWvK/JyepbQmX/CEMp7dRPHsElQcCBfDzh5LNqM+0YHHiyvJ1KAHlMhVOp VnCcb6Gez8M0yVK7hgg/c1ycg2ZHt7EHZVhnu4T+LKw2fMVeSM8lFLQgriQHvwsK zzizc4qkqPkhe9GT1jUdpnzG3JPBhJGK0nSML66CzGs17uYkNK/RaA2J0BcrQ7Ow == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 34A1CE2576; Wed, 15 Nov 2017 21:44:59 -0500 (EST) Message-Id: <1510800299.3657152.1174146072.3D53EC9B@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="_----------=_151080029936571520" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bd3ce600 References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <20171114143220.GC1733@meili> <1510729158.2694898.1173023256.3EF17092@webmail.messagingengine.com> <20171115144837.GB17058@meili> In-Reply-To: <20171115144837.GB17058@meili> Date: Thu, 16 Nov 2017 10:44:59 +0800 Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 16 Nov 2017 02:45:02 -0000 This is a multi-part message in MIME format. --_----------=_151080029936571520 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 15 Nov 2017, at 10:48 PM, Josef Jeff Sipek wrote: > Conceptually, I don't see a problem with the server setting keywords > on delivery. There's no problem doing this (in fact at FastMail we have been setting a $HasAttachment flag on delivery for years for this very purpose!), but mandating it in the spec is I think trickier than it just being a separate property which is considered part of the parsed MIME representation. > Making the $hasAttachment keyword immutable feels a bit dirty, but it > would work. Yeh, that feels really dirty to me; it's strangely different to the other keywords then. > Another option would be to leave it mutable and if a client messes > with it... well, it gets what it asked for. Yeh, although of course you might have multiple clients which could mess it up for each other. (Consider a scenario where you try out some client which turns out to have been badly authored and wipes all your keywords; now the attachment icon disappears permanently on the mailbox listing of all the other clients you use. That sounds like a support nightmare to me.) Neil. --_----------=_151080029936571520 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 15 Nov 2017, at 10:48 PM, Josef Jeff Sipek wrote:
Conceptually, I don't see a problem with the server setting keywords on delivery.

There's no problem doing this (in fact at FastMail we have been setting a $HasAttachment flag on delivery for years for this very purpose!), but mandating it in the spec is I think trickier than it just being a separate property which is considered part of the parsed MIME representation.

Making the $hasAttachment keyword immutable feels a bit dirty, but it would work.

Yeh, that feels really dirty to me; it's strangely different to the other keywords then.

Another option would be to leave it mutable and if a client messes with it... well, it gets what it asked for.

Yeh, although of course you might have multiple clients which could mess it up for each other. (Consider a scenario where you try out some client which turns out to have been badly authored and wipes all your keywords; now the attachment icon disappears permanently on the mailbox listing of all the other clients you use. That sounds like a support nightmare to me.)

Neil.
--_----------=_151080029936571520-- From nobody Wed Nov 15 21:02: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 1473A127522 for ; Wed, 15 Nov 2017 21:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neiljhaveri-com.20150623.gappssmtp.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 TUYhQDVpQW1H for ; Wed, 15 Nov 2017 21:02:46 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8B9126B72 for ; Wed, 15 Nov 2017 21:02:46 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id t10so18721005pgo.3 for ; Wed, 15 Nov 2017 21:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=J4RTP05jdPW6spkFLFKQihIX/a8Z7Vd2VflDFh3sgp4=; b=UNRaXjPgVRKT+EpkgklYnqpCP6eqJ8rrpnGFbuZbCNSGd9v6oDxitUBBF+VgkOX8Yl 5/ivm5LaINvxGu1Ef6Zs7C2J2hcKyD+odGnic+OqH6kq6rfPENeb2OOFoLnWtrSK0yGI 273s7Fgk7uelgRbKWYq2HAw5LN6XWqT3l0odEQLdsIA7BirkOiF2B7AeFf3ONfMIHGCu 8xqwwsegYF2gw8rxCwAPWLxMKMAPr6NJL63dzQtsfiP7yHtpYQ4vjzJ1h2os7/9kSzgz OTfNRmQ5z1zUZGfNl1aBV7lIfQUs3ZfPVGWdZw7AYdwigJeUWldgnDwJekPgqSg5HYBn AS6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=J4RTP05jdPW6spkFLFKQihIX/a8Z7Vd2VflDFh3sgp4=; b=uR0RJlubQ9JDHquFkHKnGhV0mXypdg5VhyOv5ldrVXedP8c2Pja5062Vqw31kyrkwJ 4iwnGfGa1k3xLsEc9dI68sWen3wAi2x7NG+CQf677qFZPK1KFxvXM5e6vd73FsLKMoGr ZF1Gxn1lrmwmfDs7ZCEhYZDSohLQRfiaNeYS/ibm6wwGdVO2tyCejQ+QnTOEJcXkyqm4 qCv7LUIezFcYdScQV33nUlGtSoWJ8qpkVyC7sURPoMx4fCtVzzK1hj4NRj8BJuOMRo8c SwvCY5GLrRfaY7MHpzJ4uGaF+i6F1BcdOfI6JP1k1NeNqpnKWROg3kjDuergnW3cLkIm zC5Q== X-Gm-Message-State: AJaThX4XBvY2llZv8+NAgU/hR6oM/ZYCSlqvlxujZmIoj+JB1/zCxBtC eqmrWLPY/rI/+f8gigEiplXiKCIZqh0= X-Google-Smtp-Source: AGs4zMa8fumGWhxRT/uL4by938w+Cacz3XSFSeS1RMlJFW3IFZ1+Z8qAw94GNrw/GFCvYaPPT5gk9w== X-Received: by 10.98.87.138 with SMTP id i10mr501267pfj.185.1510808566276; Wed, 15 Nov 2017 21:02:46 -0800 (PST) Received: from [192.168.1.7] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id v76sm524328pfk.78.2017.11.15.21.02.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 21:02:45 -0800 (PST) From: Neil Jhaveri Message-Id: <0C78AD51-EBF4-43DD-BDDB-AEFB718FAC25@neiljhaveri.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_426B1E69-1966-486F-AABB-522518B34C38" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 15 Nov 2017 22:02:43 -0700 In-Reply-To: <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> Cc: IETF JMAP Mailing List To: Neil Jenkins References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 16 Nov 2017 05:02:49 -0000 --Apple-Mail=_426B1E69-1966-486F-AABB-522518B34C38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 13, 2017, at 7:57 PM, Neil Jenkins > wrote: >=20 > Given this, I believe it makes more sense for the Message object = format to be closer to the model used in clients rather than a simple = JSON interpretation of MIME.=20 Agreed =E2=80=94 I think most MUAs want to deal with a single HTML body = + attachments array. And I think the server needs to be doing this MIME = =E2=80=94> (html, attachments[]) mapping, for reasons such as = consistency between search results and the displayed content. > This still leaves open questions such as what MIME parts should be = considered "attachments" and what parts are "body" (should be displayed = immediately inline when opening the message)? I think we might want to = not prescribe a precise algorithm for this, but rather provide a = specification of intent, with guidance for implementors on what they = might want to consider. For example, at FastMail our current algorithm = for this is roughly: >=20 > Consider each MIME part, recursing into multipart/* > Ignore images < 600px in either dimension in either a = multipart/related or multipart/alternative (because Outlook screws this = up); they're probably an inline header/logo. I don=E2=80=99t think I=E2=80=99ve encountered this one, and I=E2=80=99m = curious to hear more! > Otherwise, the part is an attachment if any of: > it's not text (according to MIME-Type) > it has a filename (from Content-Disposition) > it has Disposition-Type of "attachment" This roughly matches the Apple clients I worked on, although I recall a = number of special-cases to fix assorted bugs, along the lines of the = Outlook one you cited above. For instance, I recall a bug-fix where = Windows Live Mail apparently sent text/plain MIME messages with = pre-MIME-style UUencoded blob attachments, although maybe issues like = that aren=E2=80=99t worth worrying about for JMAP. There are other more = common issues like TNEF Winmail.dat attachments to also potentially = consider. I agree that a highly precise specification is probably not very = practical, but I think that making some effort to document the = vendor-specific cases (along with example messages) could be helpful to = implementors out there. I=E2=80=99m not sure exactly where the best = repository for something like that would be. However, I do think we can do a highly precise specification for the = mapping in the opposite direction, for the case of sending messages.= --Apple-Mail=_426B1E69-1966-486F-AABB-522518B34C38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 13, 2017, at 7:57 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:

Given this, I believe it makes more sense for the Message = object format to be closer to the model used in clients rather than a = simple JSON interpretation of MIME. 

Agreed =E2=80= =94 I think most MUAs want to deal with a single HTML body + attachments = array. And I think the server needs to be doing this MIME =E2=80=94> = (html, attachments[]) mapping, for reasons such as consistency between = search results and the displayed content.

This still leaves open = questions such as what MIME parts should be considered "attachments" and = what parts are "body" (should be displayed immediately inline when = opening the message)? I think we might want to not prescribe a precise = algorithm for this, but rather provide a specification of intent, with = guidance for implementors on what they might want to consider. For = example, at FastMail our current algorithm for this is = roughly:

    Consider each MIME part, recursing into multipart/*
  • Ignore images < 600px in either = dimension in either a multipart/related or multipart/alternative = (because Outlook screws this up); they're probably an inline = header/logo.
I = don=E2=80=99t think I=E2=80=99ve encountered this one, and I=E2=80=99m = curious to hear more!
  • Otherwise, = the part is an attachment if any of:
      • it's not text (according to MIME-Type)
    • it has a filename (from Content-Disposition)
    • it has Disposition-Type of = "attachment"
This = roughly matches the Apple clients I worked on, although I recall a = number of special-cases to fix assorted bugs, along the lines of the = Outlook one you cited above. For instance, I recall a bug-fix where = Windows Live Mail apparently sent text/plain MIME messages with = pre-MIME-style UUencoded blob attachments, although maybe issues like = that aren=E2=80=99t worth worrying about for JMAP. There are other more = common issues like TNEF Winmail.dat attachments to also potentially = consider.

I = agree that a highly precise specification is probably not very = practical, but I think that making some effort to document the = vendor-specific cases (along with example messages) could be helpful to = implementors out there. I=E2=80=99m not sure exactly where the best = repository for something like that would be.

However, I do think we can do a highly = precise specification for the mapping in the opposite direction, for the = case of sending messages.
= --Apple-Mail=_426B1E69-1966-486F-AABB-522518B34C38-- From nobody Thu Nov 16 02:54:16 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 870DF1293E1 for ; Thu, 16 Nov 2017 02:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.726 X-Spam-Level: ** X-Spam-Status: No, score=2.726 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_12=2.059, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, WEIRD_PORT=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 yphZbcTxnXo2 for ; Thu, 16 Nov 2017 02:54:10 -0800 (PST) Received: from a.tbms.in (a.tbms.in [202.157.72.21]) by ietfa.amsl.com (Postfix) with ESMTP id BCF6F127909 for ; Thu, 16 Nov 2017 02:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt; c=simple/relaxed; t=1510829648; s=xgen; d=xgenplus.com; h=Date:From:Message-ID:MIME-Version; z=Date:Thu,=2016=20Nov=202017=2016:24:08=20+0530=20(IST)|From:=E0=A4=A1=E0=A4=BE=E0=A4=9F=E0=A4=BE|Message-ID:<1564816365.107071510829648419.JavaMail.root@mx2.datainfosys.com>|MIME-Version:1.0; l=2041; bh=NfHKsLSmxmpt0Qw7kSycu7/EdTE=; b=gtJjrFE+He5zP6RoP9xdy1AiDiboNfVBnZY8J9RohrPkmkaUrQTNR0RwHw0cc7lV FsU3qEQzIa2mcPIC36RlkYoRJekrAxqBYWtJv1XP2ZZNW5yhq2Zau3qwexMTZ+4ZTfz 3rLDUfBf3VaL9/k2sfuGx1LJw4Nkkh+HSq2mat7U= Date: Thu, 16 Nov 2017 16:24:08 +0530 (IST) From: =?utf-8?B?4KSh4KS+4KSf4KS+?= To: jmap@ietf.org Message-ID: <1564816365.107071510829648419.JavaMail.root@mx2.datainfosys.com> Errors-to: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1577_1869357927.1510829648418" X-Mailer: XGen Plus INSTANT MESSAGING SYSTEM X-ScheduledMail: FALSE X-ScheduledDate: 16/11/2017 10:54:00 X-Followup: false X-FollowupTotal: 0 X-PersonalisedTag: FALSE X-Signature: FALSE X-SendType: FORWARD X-SentFromIP: 202.157.76.122 X-SentFromDate: 16/11/2017 10:54:00 X-BrowserType: Google Chrome X-Priority: 3 X-Right: X-Originating_Email_Id: X_XGEN_DLP: NO X-Alias-Id: X_Xgen_Delivery_Report: yes XMessage-Id: XGenPlusMessageID:15108296441562602 Archived-At: Subject: [Jmap] Protocol Testing Service 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, 16 Nov 2017 10:54:14 -0000 ------=_Part_1577_1869357927.1510829648418 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 ICANCkhlbGxvLEkgd2FzIGp1c3Qgd29uZGVyaW5nLCBpZiB0aGVyZSBpcyBhIHRvb2wgYXZhaWxh YmxlIHdoaWNoIGNhbiB0ZXN0IHRoZSBwcm90b2NvbCBhbmQgc3VwcG9ydCBmb3IgSU1BUCBzZXJ2 ZXIuICBQbGVhc2UgbGV0IG1lIGtub3cgcGVyc29uYWxseSwgb2ZmIHRoZSBsaXN0LiBUaGFua3NB amF5DQpbWEdFTkZPT1RFUl1bLVhHRU5GT09URVJdDQpEbyBub3QgUmVtb3ZlOltISURdMjAxNzEx MTYxMDMyNTk0NDRbLUhJRF0ADQo= ------=_Part_1577_1869357927.1510829648418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3RyaWN0Ly9FTiIg Imh0dHA6Ly93d3cudzMub3JnPS9UUi94aHRtbDEvRFREL3hodG1sMS1zdHJpY3QuZHRkIj4gPGh0 bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPiA8Ym9keSBsZWZ0bWFyZ2lu PSIwIiBtYXJnaW53aWR0aD0iMCIgdG9wbWFyZ2luPSIwIiBtYXJnaW5oZWlnaHQ9IjAiIG9mZnNl dD0iMCI+DQpIZWxsbyw8YnIgLz48YnIgLz5JIHdhcyBqdXN0IHdvbmRlcmluZywgaWYgdGhlcmUg aXMgYSB0b29sIGF2YWlsYWJsZSB3aGljaCBjYW4gdGVzdCB0aGUgcHJvdG9jb2wgYW5kIHN1cHBv cnQgZm9yIElNQVAgc2VydmVyLiZuYnNwOyBQbGVhc2UgbGV0IG1lIGtub3cgcGVyc29uYWxseSwg b2ZmIHRoZSBsaXN0LiZuYnNwOzxiciAvPjxiciAvPlRoYW5rczxiciAvPjxiciAvPkFqYXkNCjxk aXY+PGJyIC8+PHNwYW4gc3R5bGU9ImNvbG9yOiB3aGl0ZTsgZm9udC1mYW1pbHk6IHZlcmRhbmE7 IGZvbnQtc2l6ZTogeHgtc21hbGw7Ij5bWEdFTkZPT1RFUl08L3NwYW4+PGJyIC8+PGJyIC8+PHNw YW4gc3R5bGU9ImNvbG9yOiB3aGl0ZTsgZm9udC1mYW1pbHk6IHZlcmRhbmE7IGZvbnQtc2l6ZTog eHgtc21hbGw7Ij5bLVhHRU5GT09URVJdPC9zcGFuPjwvZGl2Pg0KPGRpdj48YnIgLz48c3BhbiBz dHlsZT0iY29sb3I6ICNkMmRlZWE7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiB4eC1z bWFsbDsiPkRvIG5vdCBSZW1vdmU6PGJyIC8+W0hJRF0yMDE3MTExNjEwMzI1OTQ0NFstSElEXTwv c3Bhbj48L2Rpdj48aW1nIHNyYz0naHR0cDovL3huLS1yMmJpNmQueG4tLWMyYmQxZ2IueG4tLWgy YnJqOWMvWEdlblBsdXNNZXNzYWdlSUQ6MTUxMDgyOTY0NDE1NjI2MDItI1JDUFQjLmpwZycgd2lk dGg9MXB4ICBoZWlnaHQ9MXB4PgANCjxpbWcgc3JjPSJodHRwOi8vZGxyLnRibXMuaW46ODA3Ny9Y RVQxMTE4MjoyMDE3MTEuanBnIiB3aWR0aD0iMXB4IiAgaGVpZ2h0PSIxcHgiPjwvYm9keT48L2h0 bWw+ ------=_Part_1577_1869357927.1510829648418-- From nobody Thu Nov 16 04:52:06 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 CECD11294B5 for ; Thu, 16 Nov 2017 04:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, LONG_HEX_URI=2.29, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=mXIVZVdg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CQa+mzKt 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 d7QFxASvlkYJ for ; Thu, 16 Nov 2017 04:52:01 -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 BFAE41294C8 for ; Thu, 16 Nov 2017 04:52:01 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E6AAC213DC; Thu, 16 Nov 2017 07:52:00 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Thu, 16 Nov 2017 07:52:00 -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=dLiCJ5KSD13t6z2XN 3ej8jUujeyCCm1WNS0EmwYyl54=; b=mXIVZVdgXGyGM0XOb+A6czWX3TJlmc5qE n2enJWIsw/7+9vuVynxUhVeuBsqe8VNshCktI6uUwgHaA+hskucpZVzLzgdXOkLP 28ExLKsjuK0alpkLqZH+OTKHabp0m7LSby2aVB8yXZuMfBF4HHyqfhk4YCVfsw2n G9pXgvP0G0ccAQkJaRUOaR0fp6hNyYXchWOnpRqGuic9cfwUUgxL/8s+m/lLJWFc GwOETYftIfmTdZWL7c85T1b2XO77rRRiKiIFAqSo4YeFcRJNIZOO2yVtJi9qtXl2 7DjwFbQPi22VDLOytCMgF2dwtChwciWtaAQYm5RA2bZU4Z8Kr+M+Q== 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=dLiCJ5 KSD13t6z2XN3ej8jUujeyCCm1WNS0EmwYyl54=; b=CQa+mzKt6wp6q5LVoL6VP3 2I040lEFDNvNVLaCUSHnRzzH54zm4FT0bj0Sdk+ncT7tLbJR8QnpjAWR/36cia5l o4Q1FIlWqTIZp+uSDlBJe53pUBWElPLxTSEPXf6sc1CHfkalpw/RgyfaRN8Fpg5B zFHhu1/gp4IkeFS1kodFAC/TmwvUHgOUCTa/CzfNf3agyBa2XbaIRQwQ+tS5aJ6k Q9LRkJLyslW8qVnxDhAwTK1Z95FXNgsdQURpg78p2ojC9m5tlvsc/uk4ygYTSXCo WY6vl8d56Q/FtxXojTzIiwee1mM53YTiNORuj0uOwHcaxXTaal7NybTmgkKRg/kg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C15B848020; Thu, 16 Nov 2017 07:52:00 -0500 (EST) Message-Id: <1510836720.3248021.1174574528.73D8CAA0@webmail.messagingengine.com> From: Bron Gondwana To: =?utf-8?Q?=E0=A4=A1=E0=A4=BE=E0=A4=9F=E0=A4=BE?= , jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151083672032480210" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4ef04c51 Date: Thu, 16 Nov 2017 20:52:00 +0800 In-Reply-To: <1564816365.107071510829648419.JavaMail.root@mx2.datainfosys.com> References: <1564816365.107071510829648419.JavaMail.root@mx2.datainfosys.com> Archived-At: Subject: Re: [Jmap] Protocol Testing Service 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, 16 Nov 2017 12:52:04 -0000 This is a multi-part message in MIME format. --_----------=_151083672032480210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" CCing the list because it's of general interest. There's no comprehensive public test suite for JMAP yet, because it's still changing too much. There's some early draft work here: https://github.com/fastmail/JMAP-TestSuite And a bunch of JMAP is tested by the Cassandane tests for Cyrus-IMAPd, but they're not factored out to be useful outside Cassandane: https://github.com/cyrusimap/cassandane/ In particular the mail part is tested with: https://github.com/cyrusimap/cassandane/blob/master/Cassandane/Cyrus/JMAPMa= il.pm .... But you asked about IMAP. The most comprehensive IMAP testing suite is Timo's excellent ImapTest: https://imapwiki.org/ImapTest Regards, Bron. P.S. Cassandane also includes drivers for both JMAP-TestSuite and ImapTest, so they can be run against Cyrus IMAP as part of our continuous integration tests. You've very welcome to look at how they've been hooked into a full environment there. On Thu, 16 Nov 2017, at 18:54, =E0=A4=A1=E0=A4=BE=E0=A4=9F=E0=A4=BE wrote: > Hello, >=20 > I was just wondering, if there is a tool available which can test the > protocol and support for IMAP server. Please let me know personally, > off the list.>=20 > Thanks >=20 > Ajay=20 >=20 > [XGENFOOTER] >=20 > [-XGENFOOTER] >=20 > Do not Remove: > [HID]20171116103259444[-HID] >=20=20=20=20 > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_151083672032480210 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
CCing the list because it's of gene= ral interest.

There's no comprehensive public test = suite for JMAP yet, because it's still changing too much.  There's som= e early draft work here:


And a bunch of JMAP is tested by the Cass= andane tests for Cyrus-IMAPd, but they're not factored out to be useful out= side Cassandane:


In particular the mail part is tested wit= h:


....

But you asked about IMAP.  The most = comprehensive IMAP testing suite is Timo's excellent ImapTest:


Regards,

Bron.

P.S. Cassandane also includes drivers for= both JMAP-TestSuite and ImapTest, so they can be run against Cyrus IMAP as= part of our continuous integration tests.  You've very welcome to loo= k at how they've been hooked into a full environment there.

On Thu, 16 Nov 2017, at 18:54, =E0=A4=A1=E0=A4=BE=E0=A4=9F=E0=A4=BE wr= ote:
Hello,

I was just wondering, if there is a tool = available which can test the protocol and support for IMAP server.  Pl= ease let me know personally, off the list. 

Thanks

Ajay

[XGENFOOTER]

[-XGENFOOTER]

Do not Remove:
[HID]20171116103= 259444[-HID]

_______________________________________________
Jmap mailing list

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


--_----------=_151083672032480210-- From nobody Thu Nov 16 07:53:46 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 B3A9F129501 for ; Thu, 16 Nov 2017 07:53:43 -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 (1024-bit key) header.d=drkurt.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 p1ISnCxy6_1i for ; Thu, 16 Nov 2017 07:53:42 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB467126DC2 for ; Thu, 16 Nov 2017 07:53:41 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id m1so14759278lfj.9 for ; Thu, 16 Nov 2017 07:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V5yzbTGomy3OicZhyJ8qHdTIuJIc+EGin1xUWja98oU=; b=HKkfyy6DLcpfeu85ezkN32sa4I9No+XaqyaIeTvp1uQ83koTHY+rKomv20N6+toHD2 fBjs5qoaRCTYkY4r+XbKDIF04aapDJUjxdMmw0Zs4eMXVoBl/l+A1e8+MXbUpxFmDife 9IU4TM+1xZGc3B8PZai+71QJG4obceSKJKEWs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V5yzbTGomy3OicZhyJ8qHdTIuJIc+EGin1xUWja98oU=; b=DPRYHZwoy9XGRS/vM+G4GEyRg0Tm2Rmk1H1lFM81t1QPAu3hGbKWElpQRKKeBHUcd/ dsk7jFn1r91x+2EVLY9vlELM0UZONLUQzDWOXMqTXLZvNJeWP4kWWA3f/dxjgDYa2e75 s99BPkphzn3adhoDttQDtYDKDgcgINQ+mPPOTcaaEGedz7GO78CWujM1NvQttQ2gUga9 dg9nSw/NZkf6YVh3CJZfawwH45zSjiVXjzIMW76ls7zRFbohWB6E2b+ma2VgnzSsS95x GXckN42Ghdyy8mLoV21M4Q7zPnfBIgrRm8O1sByPtRBl5XdkOcnFpFVn83CGYArv90SK Q9kQ== X-Gm-Message-State: AJaThX4U4/bW0T0CtvAfzaelBN+HwJ8rf6wYOimajBY2kxnaJR2ldZSx sWrBA9PFfXtaE+NZm7bmzkoZHFCoPdXdZ4HgwzbzxrHC X-Google-Smtp-Source: AGs4zMY/fcAW5sodpMf6f24wQKrB54uoDXgBIDjfs62pjHrImtCmAJBNzNYvjfrVsKM1b3OAqB2VcIwi/hhyQ3J8384= X-Received: by 10.46.41.212 with SMTP id p81mr930990ljp.173.1510847619877; Thu, 16 Nov 2017 07:53:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.56.9 with HTTP; Thu, 16 Nov 2017 07:53:38 -0800 (PST) In-Reply-To: <0C78AD51-EBF4-43DD-BDDB-AEFB718FAC25@neiljhaveri.com> References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <0C78AD51-EBF4-43DD-BDDB-AEFB718FAC25@neiljhaveri.com> From: Kurt Andersen Date: Thu, 16 Nov 2017 05:53:38 -1000 Message-ID: To: Neil Jhaveri Cc: Neil Jenkins , IETF JMAP Mailing List Content-Type: multipart/alternative; boundary="001a114a60b8b17a91055e1b9fa3" Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 16 Nov 2017 15:53:44 -0000 --001a114a60b8b17a91055e1b9fa3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 15, 2017 at 7:02 PM, Neil Jhaveri wrote: > > On Nov 13, 2017, at 7:57 PM, Neil Jenkins wrote: > > Given this, I believe it makes more sense for the Message object format t= o > be closer to the model used in clients rather than a simple JSON > interpretation of MIME. > > > Agreed =E2=80=94 I think most MUAs want to deal with a single HTML body + > attachments array. And I think the server needs to be doing this MIME =E2= =80=94> > (html, attachments[]) mapping, for reasons such as consistency between > search results and the displayed content. > Why do you want to force servers to interpolate HTML (or create a body ex nihilo?) if there isn't any? --Kurt --001a114a60b8b17a91055e1b9fa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 15, 2017 at 7:02 PM, Neil Jhaveri <neil@neiljhaveri.com>= wrote:

On Nov 1= 3, 2017, at 7:57 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:

Given this, I bel= ieve it makes more sense for the Message object format to be closer to the = model used in clients rather than a simple JSON interpretation of MIME.=C2=A0

Agreed =E2=80=94 I think most = MUAs want to deal with a single HTML body + attachments array. And I think = the server needs to be doing this MIME =E2=80=94> (html, attachments[]) = mapping, for reasons such as consistency between search results and the dis= played content.

Why do you want= to force servers to interpolate HTML (or create a body ex nihilo?) if ther= e isn't any?

--Kurt=C2=A0

--001a114a60b8b17a91055e1b9fa3-- From nobody Thu Nov 16 10:50:47 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 245531241F5 for ; Thu, 16 Nov 2017 10:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neiljhaveri-com.20150623.gappssmtp.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 1-Fmk_YnHSfV for ; Thu, 16 Nov 2017 10:50:43 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074E31205F1 for ; Thu, 16 Nov 2017 10:50:43 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id i15so7522pfa.3 for ; Thu, 16 Nov 2017 10:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oRbEdJaa47dMCpkrbYJW0wwxUIO9ijNyQRjxsgrSFtg=; b=t7wR3CoZZiOeKu7vni6XbotsiyWW4ZaLfA7ZAjla4296gEMNcJ33q9acWZ3tk7Yiso o6RDIzbcivlv77d+Dmr1tmp8KhZDQtWbrsMhNgh5bfHUShVu3FGGTB/mJFl2M1OtfMio KH9o4FCUHkYRcTPXf2i7C+tN15WW/hvJVGH7aVGX959GqpP/q1j0X9WsI0JaOIN/9X9F JFYAQSAX5B4uTZ/bcuow0DeBn/bVKeEYWgdgz1lAFgRvHfEdeQUpuscrIEHgWVrYIi0R pcBYh+zAlJxbb4PbeK237ck2NCqYHg4IDH3WEgEkqysFpJzlY1a9ONWZcafNRJ5Ge1a+ KyEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oRbEdJaa47dMCpkrbYJW0wwxUIO9ijNyQRjxsgrSFtg=; b=UgA0NtjsUXMpDJLHhZL0aq5KbMjDFixPcBhwQ6lwN/FLFyNMHzHFZwuDDM6TDi8D7N r26j4/4DtW4FjRttURaAaq7SFJIh1Zurd3gqxp9X90mV331NLI3oytfi/Qqds3yDhzTI JUPXIH4e0G4WbnQl69sUKiNQF3TeoGSl64oynbzLinUgbuqHJUvcEBGekMqv4w8OR8WO puu3r3xT4LU1J3TxXIz8BN866gkP0AljUu36gYFMaRmtNox5uMsR+px8sfkHpiUTITm4 LrRFvQSz7yuMyzl+AWmmWEdQ50doY+hdCVuNwm3QWwq44pgQ/LPBFb7Bs8H5pd6YOraG bCNg== X-Gm-Message-State: AJaThX6aSjyKcD+uPt8nZftebY8wXYEPpNsvXK3iE6jAoQOcW52Q4W6A jXPK/nwA8HHfZZ8zJcks1zrNlRfC+NI= X-Google-Smtp-Source: AGs4zMYi8g/z0HmXOCqvtDPMO/lzc6q7/84sA7TEX39ey+gc1VvJm1sFfXPnbnXWOcWrjCm/IcCPHA== X-Received: by 10.98.141.150 with SMTP id p22mr2817212pfk.207.1510858242344; Thu, 16 Nov 2017 10:50:42 -0800 (PST) Received: from [100.74.227.105] (ip67-155-240-118.z240-155-67.customer.algx.net. [67.155.240.118]) by smtp.gmail.com with ESMTPSA id d2sm3824474pfe.164.2017.11.16.10.50.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 10:50:41 -0800 (PST) From: Neil Jhaveri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_31474FF9-0C69-4792-9992-BB20AE2D2E41" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 16 Nov 2017 11:50:39 -0700 In-Reply-To: Cc: Neil Jenkins , IETF JMAP Mailing List To: Kurt Andersen References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <0C78AD51-EBF4-43DD-BDDB-AEFB718FAC25@neiljhaveri.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 16 Nov 2017 18:50:45 -0000 --Apple-Mail=_31474FF9-0C69-4792-9992-BB20AE2D2E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 16, 2017, at 8:53 AM, Kurt Andersen wrote: >=20 > On Wed, Nov 15, 2017 at 7:02 PM, Neil Jhaveri > wrote: >=20 >> On Nov 13, 2017, at 7:57 PM, Neil Jenkins > wrote: >>=20 >> Given this, I believe it makes more sense for the Message object = format to be closer to the model used in clients rather than a simple = JSON interpretation of MIME.=20 >=20 > Agreed =E2=80=94 I think most MUAs want to deal with a single HTML = body + attachments array. And I think the server needs to be doing this = MIME =E2=80=94> (html, attachments[]) mapping, for reasons such as = consistency between search results and the displayed content. >=20 > Why do you want to force servers to interpolate HTML (or create a body = ex nihilo?) if there isn't any? I think this is a fair question, and there are some trade-offs. I think = the standard for any modern client is that they need to be able to = display text/html. If they support text/html, I=E2=80=99d imagine that = clients are just up-converting plain text into HTML to simplify their = view-layer. Certainly all webmail clients are in this boat. I fully acknowledge the server doing the up-conversion, however, does = come at a cost and unfortunate server involvement in presentation. For = instance, quoted text may need to be up-converted to be wrapped in a =
tag, but maybe that=E2=80=99s not exactly what every client = wants at it=E2=80=99s presentation layer. I also completely sympathize with the challenges a server will face = doing this kind of conversion, and that the problem may be easier to = solve in the client. I think Neil Jenkins mentioned during the IETF 100 = JMAP session that Fastmail handled multipart/mixed messages with = multiple text/html parts by just smashing them together and letting the = browser deal with the invalid HTML=E2=80=A6 and IIRC both macOS and iOS = Mail also had a very similar reliance on the forgiving-parsing abilities = of WebKit. It all boils down to I think a lot of client authors are designing their = UIs to basically be HTML + array of attachments (with some possibly = inline), whereas the full scope of MIME is not easily mapped to that. = Sigh. I still think this is a worthwhile problem to solve on the server, so = that the single primary text/html blob that the server indexes for = search is exactly what the user sees, and you don=E2=80=99t wind up with = the never-ending bug cases of =E2=80=9Csearch found it, but the user = can=E2=80=99t see it=E2=80=9D or vice versa. But I suspect this is going = to get so messy that it has to get pushed down to the clients.= --Apple-Mail=_31474FF9-0C69-4792-9992-BB20AE2D2E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 16, 2017, at 8:53 AM, Kurt Andersen <kurta@drkurt.com> = wrote:

On Wed, Nov 15, 2017 at 7:02 PM, Neil Jhaveri = <neil@neiljhaveri.com> = wrote:

On Nov 13, 2017, at 7:57 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:

Given this, I believe it makes more sense for the Message = object format to be closer to the model used in clients rather than a = simple JSON interpretation of MIME. 

Agreed =E2=80=94 I think most MUAs want to deal = with a single HTML body + attachments array. And I think the server = needs to be doing this MIME =E2=80=94> (html, attachments[]) mapping, = for reasons such as consistency between search results and the displayed = content.

Why do you want to force servers to interpolate HTML (or = create a body ex nihilo?) if there isn't = any?

I think this is a fair question, and there are = some trade-offs. I think the standard for any modern client is that they = need to be able to display text/html. If they support text/html, I=E2=80=99= d imagine that clients are just up-converting plain text into HTML to = simplify their view-layer. Certainly all webmail clients are in this = boat.

I fully acknowledge the server = doing the up-conversion, however, does come at a cost and unfortunate = server involvement in presentation. For instance, quoted text may need = to be up-converted to be wrapped in a <blockquote> tag, but maybe = that=E2=80=99s not exactly what every client wants at it=E2=80=99s = presentation layer.

I also = completely sympathize with the challenges a server will face doing this = kind of conversion, and that the problem may be easier to solve in the = client. I think Neil Jenkins mentioned during the IETF 100 JMAP session = that Fastmail handled multipart/mixed messages with multiple text/html = parts by just smashing them together and letting the browser deal with = the invalid HTML=E2=80=A6 and IIRC both macOS and iOS Mail also had a = very similar reliance on the forgiving-parsing abilities of = WebKit.

It all boils down to I think = a lot of client authors are designing their UIs to basically be HTML + = array of attachments (with some possibly inline), whereas the full scope = of MIME is not easily mapped to that. Sigh.

I still think this is a worthwhile problem to = solve on the server, so that the single primary text/html blob that the = server indexes for search is exactly what the user sees, and you don=E2=80= =99t wind up with the never-ending bug cases of =E2=80=9Csearch found = it, but the user can=E2=80=99t see it=E2=80=9D or vice versa. But I = suspect this is going to get so messy that it has to get pushed down to = the clients.
= --Apple-Mail=_31474FF9-0C69-4792-9992-BB20AE2D2E41-- From nobody Thu Nov 16 11:54:47 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 BD75C1201F2 for ; Thu, 16 Nov 2017 11:54:46 -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 8d8lC4HttTSF for ; Thu, 16 Nov 2017 11:54:45 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF521200B9 for ; Thu, 16 Nov 2017 11:54:45 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id EDFB22AEF43; Thu, 16 Nov 2017 21:54:42 +0200 (EET) Date: Thu, 16 Nov 2017 14:54:40 -0500 From: Josef 'Jeff' Sipek To: Neil Jhaveri Cc: Kurt Andersen , Neil Jenkins , IETF JMAP Mailing List Message-ID: <20171116195439.GI17058@meili> References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <0C78AD51-EBF4-43DD-BDDB-AEFB718FAC25@neiljhaveri.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 16 Nov 2017 19:54:47 -0000 On Thu, Nov 16, 2017 at 11:50:39 -0700, Neil Jhaveri wrote: > > On Nov 16, 2017, at 8:53 AM, Kurt Andersen wrote: ... > > Why do you want to force servers to interpolate HTML (or create a body > > ex nihilo?) if there isn't any? > > I think this is a fair question, and there are some trade-offs. Agreed. ... > It all boils down to I think a lot of client authors are designing their > UIs to basically be HTML + array of attachments (with some possibly > inline), whereas the full scope of MIME is not easily mapped to that. > Sigh. For the "easy API" (compared to the just parse the raw blob client-side), I would like the server to not do the concatenation of multiple parts, but instead simply supply the client with an *array* of body parts, and the client can concat them whichever way makes sense. (I think it was Chris Newman who suggested it.) In other words, this way the whole behavior is split into two components: - a server side "identify body parts & attachments" - a client side "display parts & present attachments" Yes, it does complicate the client a tiny bit, but in general it's easy enough for a client to render more than one blob. Note that I'm *not* talking about multipart/alternative. > I still think this is a worthwhile problem to solve on the server, so that > the single primary text/html blob that the server indexes for search is > exactly what the user sees, and you don’t wind up with the never-ending > bug cases of “search found it, but the user can’t see it” or vice versa. The only case I can think of where this would happen is: server presents the client with 2 body parts to concat (e.g., body and a mailing list appended signature), the client decides to display only one. Isn't this arguably a client bug since it is not displaying the entire message? Jeff. -- NT is to UNIX what a doughnut is to a particle accelerator. From nobody Thu Nov 16 13:26:07 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 4438A128DF3 for ; Thu, 16 Nov 2017 13:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 uRRz2UhfH2Xt for ; Thu, 16 Nov 2017 13:26:05 -0800 (PST) Received: from smtp.linagora.com (unknown [109.197.180.137]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B5B21200F1 for ; Thu, 16 Nov 2017 13:26:05 -0800 (PST) Received: from extranet.linagora.com (ldap.linagora.com [172.16.18.50]) by smtp.linagora.com (Postfix) with ESMTP id 0FB631CEDF; Thu, 16 Nov 2017 22:26:06 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 16 Nov 2017 22:26:03 +0100 From: Raphael OUAZANA To: Josef 'Jeff' Sipek Cc: Neil Jhaveri , Neil Jenkins , Kurt Andersen , IETF JMAP Mailing List In-Reply-To: <20171116195439.GI17058@meili> References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <0C78AD51-EBF4-43DD-BDDB-AEFB718FAC25@neiljhaveri.com> <20171116195439.GI17058@meili> Message-ID: <865c3b1ebeade4f5e7dcd8657d1bed8d@linagora.com> X-Sender: rouazana@linagora.com User-Agent: Roundcube Webmail/1.1.4 Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 16 Nov 2017 21:26:06 -0000 Hi, Le 2017-11-16 20:54, Josef 'Jeff' Sipek a écrit : > - a server side "identify body parts & attachments" > - a client side "display parts & present attachments" In this case how do you compute the preview server side? Regards, Raphaël Ouazana. From nobody Thu Nov 16 14:20:10 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 40AC31271FD for ; Thu, 16 Nov 2017 14:20:08 -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 YF6yM54QctJz for ; Thu, 16 Nov 2017 14:20:07 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id E7471126BF3 for ; Thu, 16 Nov 2017 14:20:06 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id EA3702AEF43; Fri, 17 Nov 2017 00:20:04 +0200 (EET) Date: Thu, 16 Nov 2017 17:20:01 -0500 From: Josef 'Jeff' Sipek To: Raphael OUAZANA Cc: Neil Jenkins , Neil Jhaveri , Kurt Andersen , IETF JMAP Mailing List Message-ID: <20171116222001.GJ17058@meili> References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <0C78AD51-EBF4-43DD-BDDB-AEFB718FAC25@neiljhaveri.com> <20171116195439.GI17058@meili> <865c3b1ebeade4f5e7dcd8657d1bed8d@linagora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <865c3b1ebeade4f5e7dcd8657d1bed8d@linagora.com> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 16 Nov 2017 22:20:08 -0000 On Thu, Nov 16, 2017 at 22:26:03 +0100, Raphael OUAZANA wrote: > Hi, > > Le 2017-11-16 20:54, Josef 'Jeff' Sipek a crit: > > - a server side "identify body parts & attachments" > > - a client side "display parts & present attachments" > > In this case how do you compute the preview server side? I don't understand... what preview are you talking about? Jeff. -- Research, n.: Consider Columbus: He didn't know where he was going. When he got there he didn't know where he was. When he got back he didn't know where he had been. And he did it all on someone else's money. From nobody Thu Nov 16 18:30: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 83E1A1274A5 for ; Thu, 16 Nov 2017 18:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=fastmailteam.com header.b=Ocpz8vF+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JR03cqf3 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 dzZQA9ISO8wS for ; Thu, 16 Nov 2017 18:30:19 -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 CC8B212008A for ; Thu, 16 Nov 2017 18:30:18 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 4D3E820CBF; Thu, 16 Nov 2017 21:30:16 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 16 Nov 2017 21:30:16 -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=AETPAh yeNCVt7WOhX1Sm0sVya1oUlNKatQEj8YlbQms=; b=Ocpz8vF+Nrv9xOBjRFxZiA ArnMD0LSCFgLpbWucm47UGUeGgFfn7ZyCYpFXE4RQtWLat2lgd8uNlEXdFloW9Wm /ojRX9TjgynanKnuGR2AqUqG1GE7EBH5gSPfGG1dC9kUI2hujuGj/ujWGvyQs85v mEQEg5wOpphzNb8eX1H0lM8HTcMpXOgF6Hq4t9qLxx8qK0S+plXr0BuTdZPmbUBH CisNLRDR3nCm3xlqTeWn2xEsF67LmxNuXwuxNGpJkLfqEk05OlRTj05pCXg4enMA xnTWzCIOpnuUQDk3iyQSDYGWyouL4hASybYcG7Pkm4jYotThDC5OMoA6L2K0G97A == 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=AETPAh yeNCVt7WOhX1Sm0sVya1oUlNKatQEj8YlbQms=; b=JR03cqf3BdmujpjhWy7yXi /W3gN8lylkgcKWTSos6ZyC4hiatT+PXhwRnMBkLN8FgZpWLco09PpRD5QcvLmw2n IYHoxt9SrShMlt+1b3s9Rs7F4ypjaaKEol5C71O7pYKNKwITRXayWBY1w8AitpeA GsNx80ZC1JBiMvdKB9j2HDktgL22Me+3eWSiRqE1MYGEPC/rYBLHreZ8LsmdPTcO /sw5D46WEjGKb9jWuE7d6kGLKu0Nytj47bpMqRshI3rSw7MNoFMpkCuFvcsYxcuG Kj1BAaHFV2tgNRIPzl3yDJh+UNtd9nK4tCZkHLr3cntWhTJhxPYtkHUQKPnH/1PQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0D51FE270D; Thu, 16 Nov 2017 21:30:16 -0500 (EST) Message-Id: <1510885815.638550.1175405592.5E7EFD01@webmail.messagingengine.com> From: Neil Jenkins To: Josef Jeff Sipek , Neil Jhaveri Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15108858156385501" X-Mailer: MessagingEngine.com Webmail Interface - ajax-098261a5 Date: Fri, 17 Nov 2017 10:30:15 +0800 References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <0C78AD51-EBF4-43DD-BDDB-AEFB718FAC25@neiljhaveri.com> <20171116195439.GI17058@meili> In-Reply-To: <20171116195439.GI17058@meili> Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 17 Nov 2017 02:30:20 -0000 This is a multi-part message in MIME format. --_----------=_15108858156385501 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 17 Nov 2017, at 03:54 AM, Josef 'Jeff' Sipek wrote: > For the "easy API" (compared to the just parse the raw blob client- > side),> I would like the server to not do the concatenation of multiple > parts, but> instead simply supply the client with an **array** of body > parts, and the> client can concat them whichever way makes sense. This I think is our preferred option. This is already what happens internally in all of our implementations of this before being mushed together; but the client could concatenate them just as easily, and in many cases do a better job by rendering them separately and then displaying the rendered parts together. The server should index all of the parts it will return as "body", so it shouldn't cause any issues with search/view mismatch. > Note that I'm **not** talking about multipart/alternative. So the client will need to be able to request whether it prefers HTML or plain text when both are available. There is a question of whether it should be able to ask the server to convert HTML <-> Plain if only the non-preferred option is available. I'm not sure this is necessary these days; clients can do the conversion themselves if they want. Neil. --_----------=_15108858156385501 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 17 Nov 2017, at 03:54 AM, Josef 'Jeff' Sipek wrote:
For the "easy API" (compared to the just parse the raw blob client-side),
I would like the server to not do the concatenation of multiple parts, but
instead simply supply the client with an *array* of body parts, and the
client can concat them whichever way makes sense.

This I think is our preferred option. This is already what happens internally in all of our implementations of this before being mushed together; but the client could concatenate them just as easily, and in many cases do a better job by rendering them separately and then displaying the rendered parts together.

The server should index all of the parts it will return as "body", so it shouldn't cause any issues with search/view mismatch.

Note that I'm *not* talking about multipart/alternative.

So the client will need to be able to request whether it prefers HTML or plain text when both are available. There is a question of whether it should be able to ask the server to convert HTML <-> Plain if only the non-preferred option is available. I'm not sure this is necessary these days; clients can do the conversion themselves if they want.

Neil.
--_----------=_15108858156385501-- From nobody Thu Nov 16 18:39: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 CE61D1272E1 for ; Thu, 16 Nov 2017 18:39:30 -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, 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, 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=fjl08Bnt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BKgQGXew 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 ql5c9ivopt_Q for ; Thu, 16 Nov 2017 18:39:29 -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 F11591267BB for ; Thu, 16 Nov 2017 18:39:28 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 243AD20CCD; Thu, 16 Nov 2017 21:39:28 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 16 Nov 2017 21:39:28 -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=6pQBYV HxgnxzsvFnfTYCIoIclhEPaoDytwjeyz7ECLg=; b=fjl08BntDTFFaQeNcY7LcS PX4cAyQTBYJOOiTbtLIfgp4cLqFvtSogP/6DU37LIIAz8XlAnVnfsxajnTXQtrYL KYa46MfbHVv+2hm/7RmZAxZHyriAVteBc/fs1Yxzs9pS0WLmF0X6FR0MaDBpYJdl Vw7RPUI2vDSiLOerYML+X7atRq7K3dkU6NKL0nBpVaXySPQg7aAc1VnJnJkEEjPb Y6Xs5Mv/N2WQETBaRpIQqiB/2GJukkO92UF1KTWmKidc104hBYeAJxcNYqU+FUBF 8T5KxAO8r6jhrkbA5AhjoTWf7e/CUZugUdJWMU7jFcWL86Odju8kKDY8tqgbcqjA == 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=6pQBYV HxgnxzsvFnfTYCIoIclhEPaoDytwjeyz7ECLg=; b=BKgQGXewfNF5uZ8M+UJWva u6Z1TAsjKc7u7WQx04/3tncUcl8pdtkQako241Yk8+ZvDzbadycpZSvTH/EzphAq 6WvyoFpoX8aqH6IHwq+TsOl60oh5FxEBfOQhn68noO6B11Pe1YsnzUZS2qgL24x/ WB//6+lBM8OJIvlnELX0SvrfTkPdWvRjL5ej88ZPhEMmFXX6MdZJBJs5zra94USj lW9peTHiUg6PG1KBsXqxe2vxy4L8zrYEdxzsckQ5lr0Ad4tDxWVB9B73PmJXnqcV 9OdJ2MQ06LQYQXpEjdTity8gC0Jfz1111e6lbUxqueRMEW32ejHZec48O2zzMKEg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D0936E270D; Thu, 16 Nov 2017 21:39:27 -0500 (EST) Message-Id: <1510886367.646742.1175408384.15BA3DDC@webmail.messagingengine.com> From: Neil Jenkins To: Josef Jeff Sipek , Raphael OUAZANA , Neil Jhaveri Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15108863676467422" X-Mailer: MessagingEngine.com Webmail Interface - ajax-098261a5 In-Reply-To: <20171116222001.GJ17058@meili> Date: Fri, 17 Nov 2017 10:39:27 +0800 References: <20171113125326.GE3844@meili> <1510628242.1338468.1171572624.754A9EFF@webmail.messagingengine.com> <0C78AD51-EBF4-43DD-BDDB-AEFB718FAC25@neiljhaveri.com> <20171116195439.GI17058@meili> <865c3b1ebeade4f5e7dcd8657d1bed8d@linagora.com> <20171116222001.GJ17058@meili> Archived-At: Subject: Re: [Jmap] hasAttachment vs. keywords 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, 17 Nov 2017 02:39:31 -0000 This is a multi-part message in MIME format. --_----------=_15108863676467422 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Fri, 17 Nov 2017, at 06:20 AM, Josef 'Jeff' Sipek wrote: > On Thu, Nov 16, 2017 at 22:26:03 +0100, Raphael OUAZANA wrote: >> In this case how do you compute the preview server side? > I don't understand... what preview are you talking about? The Message#preview[1] property I presume. The answer is the server should take the text from the first body part of the array response. As in the current spec, the server may choose to skip quoted sections or salutations to return a more useful preview. On Thu, 16 Nov 2017, at 01:02 PM, Neil Jhaveri wrote: > I agree that a highly precise specification is probably not very > practical, but I think that making some effort to document the vendor- > specific cases (along with example messages) could be helpful to > implementors out there. I=E2=80=99m not sure exactly where the best repos= itory > for something like that would be. There is a server guide in the same repo, which I would like to expand with this kind of thing (if we don't think it belongs in the spec itself). This probably won't be published as an RFC (although it could be an informational one), but we want to have a whole ecosystem of test suite, (client) usage guide, server implementation guide etc. to help (interoperable) adoption. > However, I do think we can do a highly precise specification for the > mapping in the opposite direction, for the case of sending messages. Yep, agreed. Well volunteered. ;-) Neil. Links: 1. http://jmap.io/spec-mail.html#messages --_----------=_15108863676467422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Fri, 17 Nov 2017, at 06:20 AM, Josef 'Jeff' Sipek wrote:
<= /div>
On Thu, Nov 16, 2017 at 22:26:03 +0100, Raph= ael OUAZANA wrote:
In this case how do you compute the preview server side?
I don't understand... what preview are you talking about?=

The Message#preview= property I presume. The answer is the server should take the text from= the first body part of the array response. As in the current spec, the ser= ver may choose to skip quoted sections or salutations to return a more usef= ul preview.

On Thu, 16 Nov 2017, at 01:02 PM, Neil Jhaveri wrote:
I agree that a highly precise specification = is probably not very practical, but I think that making some effort to docu= ment the vendor-specific cases (along with example messages) could be helpf= ul to implementors out there. I=E2=80=99m not sure exactly where the best r= epository for something like that would be.

There is a server guide in the same repo, which I would like to expand= with this kind of thing (if we don't think it belongs in the spec itself).= This probably won't be published as an RFC (although it could be an inform= ational one), but we want to have a whole ecosystem of test suite, (client)= usage guide, server implementation guide etc. to help (interoperable) adop= tion.

However, I do think we can do a highly = precise specification for the mapping in the opposite direction, for the ca= se of sending messages.

Yep, agreed. Well volunteered. ;-)

Neil.
--_----------=_15108863676467422-- From nobody Sun Nov 26 20:08: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 356221200F3 for ; Sun, 26 Nov 2017 20:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=fastmailteam.com header.b=W2YWDsqz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Iz+ZG5jf 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 fif5HaFuiO_H for ; Sun, 26 Nov 2017 20:08:11 -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 8B6DC127275 for ; Sun, 26 Nov 2017 20:08:11 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E94D620991 for ; Sun, 26 Nov 2017 23:08:10 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sun, 26 Nov 2017 23:08:10 -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=QFQ34dSjpuAlssN+d1ALNA6TYdRqjdERDRNz1x241 7c=; b=W2YWDsqze/cOdHdEQ5+ZesGLslp1xpPF9nGTuVAnqu0QOkOZmpDPL1Xl0 EttfEuwB1arARG/bqWKjw76CASoJYcsLMXIiKnILu91j2avWLT81EbZMaDtDYxf8 /Dtj1PWNPpwr7c3ROh+Sqto23L2+A/54aWODgoa6Vvi3URGISoRHiVZBi+kuoQeN i/gVLo/2nRiPDBDH6BR6sjYmkQO2EWJQdtrROKtFWH7yAE5mZ8xbN3TpgmzJ1fhP lnzJNMBLyJNvkRjUrvrKdzh7WlM3or7PjIxxMQB+JmGjlHlK3iOWLgdMvTa0nBWX O5EvfbNT+/sLzzfBWOpib4NSIdjCg== 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=QFQ34dSjpuAlssN+d1ALNA6TYdRqj dERDRNz1x2417c=; b=Iz+ZG5jfTi3UJSbsVK4tiiuShTNVH4rVX/oh0YIK5crzW +iZYIZagsL4u8W1gWA4S78cvQyaAUnXp9Zff4l9sWxjTZfw5cDXAFCL2deKEtR2c EecOblfdFQvzdvGZ/f7Ciw+mlE77zuE2FI/WoNN2Pg6QCIZwOs8erVfSHH+PY5BA ts+cYrrkowy5mQ7xKNdhk3hZJtObXbnm8vundrKkA+N9fdWwkSmr7jsHOJIeJpR5 Ww95btOWOz8mSVw41Yo89tSkfQApq/Ihnnnf2/7c5J9VLjiAIJp5Jv37WrUDxOob PZHMpnhU9Ca00PP30nQsBy599uE/TZjp0AeSr7iiA== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A547C9E0D2; Sun, 26 Nov 2017 23:08:10 -0500 (EST) Message-Id: <1511755690.83969.1185022400.1AB2E786@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1511755690839690" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a169161c Date: Mon, 27 Nov 2017 15:08:10 +1100 Archived-At: Subject: [Jmap] Minutes from Singapore 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: Mon, 27 Nov 2017 04:08:13 -0000 This is a multi-part message in MIME format. --_----------=_1511755690839690 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Sorry about the long delay uploading these, last week disappeared into fixing all the broken things! I've uploaded a copy of these to datatracker, but here's the content inline as well: Notes from JMAP session, IETF100, Singapore 16-Nov-2017 Authentication: * security area may have comments about auth options * Neil to write up security considerations section for authentication (including BASIC) ASAP. * Barry will forward draft to security area for early review. Require/Using: * Should say URN rather than URL * Will use ietf: for standard specs, have vendors use URN in own domain for vendor extensions (like XML namespaces for *DAV) Plurals: * debate over plural vs singular naming in methods and datatypes * all agreed that one is better than two, and there were no objections in the room to going with plural Message Format: * tradeoffs between "easy for the common case" and "preserves the intent expressed in MIME structure" * core issue: IMAP clients currently have to fetch the BODYSTRUCTURE and then make grouped fetches for all the messages where the interesting text or html part has the same part number, leading to multiple round trips and client complexity. We want to avoid this issue with JMAP. * possibly an array of text or html items rather than just a single item, annotated with source MIME part number like IMAP, with a selector syntax that allows for not transferring excessive copies. The tricky area is only getting the most interesting one from multipart/alternative. * still have to solve the "return only N bytes" issue for clients that don't want to download potentially megabytes of plain text for big messages. * might have more discussion on the mailing list SMIME signature verification on server * Alexey will look at writing up something for this, possibly a separate document rather than part of JMAP-Mail itself. Security considerations: * will have to say something about HTML filtering * in particular, if an HTML part gets truncated in the middle of a URL this can be a security issue. $Seen / rights: * preference for keeping parity with IMAP ACL spec, so $Seen (\Seen) flag gets a separate ACL * can always bundle rights on server * no strong preference either way for keeping $Seen as a keyword vs splitting out to a separate top-level isUnread value, but leaning towards keeping it as a keyword. Document what "case insensitive search" means. * need to at least provide an option to specify a collation algorithm. * must support at least i;unicode-casemap * fuzzy is good as it allows servers to optimize without insisting on an exact algorithm which doesn't allow for improvements in search engine heuristics. Searching in and returning headers: * lots of debate about decoding of unknown headers, where applying RFC2047 decoding may be incorrect, both for search and for display. * header names must be ASCII, so lowercasing is safe there, it is well defined. * there was no agreement in the room, we need to take this one to the list. Should "unknown" headers be returned as raw 7bit bytes, or decoded to characters that become UTF-8 JSON? * likewise for search - does there need to a knob to do encoded/raw access to the header? Editorial note: * examples are all $Keyword, but user-specified keywords don't have to start with $. Should have some examples to demonstrate that. More confusion over emailId vs Message-Id (RFC822/5322) header. * Multiple messages with RFC822-Message-Id can be allowed by the server, but they may have different emailId. * Indeed, depending on the server, even identical blobs might have different blobIds and if they are emails, identical emails might have different emailIds. RFC822 import of invalid message: * can JMAP server modify during importMessages e/g stripping NULLs or fixing invalid headers? * everyone agreed: yes, so long as the server gives a new blobId for the message in the response. Removal of messages or parts for policy reasons (DCMA / virus) * needs to be a way to say "POLICY REFUSED" when a message or even just blob is requested, regardless of whether the server still has a copy. end. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_1511755690839690 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Sorry about the long delay uploading these, last week disappeared into fixing all the broken things!

I've uploaded a copy of these to datatracker, but here's the content inline as well:

Notes from JMAP session, IETF100, Singapore 16-Nov-2017

Authentication:
* security area may have comments about auth options
* Neil to write up security considerations section for
   authentication (including BASIC) ASAP.
* Barry will forward draft to security area for early
   review.

Require/Using:
  * Should say URN rather than URL
  * Will use ietf: for standard specs, have vendors
    use URN in own domain for vendor extensions (like
    XML namespaces for *DAV)

Plurals:
  * debate over plural vs singular naming in methods
    and datatypes
  * all agreed that one is better than two, and there
    were no objections in the room to going with plural

Message Format:
  * tradeoffs between "easy for the common case" and
    "preserves the intent expressed in MIME structure"
  * core issue: IMAP clients currently have to fetch
    the BODYSTRUCTURE and then make grouped fetches for
    all the messages where the interesting text or html
    part has the same part number, leading to multiple
    round trips and client complexity.  We want to avoid
    this issue with JMAP.
  * possibly an array of text or html items rather than
    just a single item, annotated with source MIME part
    number like IMAP, with a selector syntax that
    allows for not transferring excessive copies.  The
    tricky area is only getting the most interesting
    one from multipart/alternative.
  * still have to solve the "return only N bytes" issue
    for clients that don't want to download potentially
    megabytes of plain text for big messages.

  * might have more discussion on the mailing list

SMIME signature verification on server
  * Alexey will look at writing up something for this,
    possibly a separate document rather than part of
    JMAP-Mail itself.

Security considerations:
  * will have to say something about HTML filtering
  * in particular, if an HTML part gets truncated in
    the middle of a URL this can be a security issue.

$Seen / rights:
  * preference for keeping parity with IMAP ACL spec,
    so $Seen (\Seen) flag gets a separate ACL
  * can always bundle rights on server
  * no strong preference either way for keeping $Seen
    as a keyword vs splitting out to a separate top-level
    isUnread value, but leaning towards keeping it as
    a keyword.

Document what "case insensitive search" means.
  * need to at least provide an option to specify a
    collation algorithm.
  * must support at least i;unicode-casemap
  * fuzzy is good as it allows servers to optimize
    without insisting on an exact algorithm which
    doesn't allow for improvements in search
    engine heuristics.

Searching in and returning headers:
  * lots of debate about decoding of unknown headers, where
    applying RFC2047 decoding may be incorrect, both for search
    and for display.
  * header names must be ASCII, so lowercasing is safe there,
    it is well defined.
  * there was no agreement in the room, we need to take this one
    to the list.  Should "unknown" headers be returned as raw 7bit
    bytes, or decoded to characters that become UTF-8 JSON?
  * likewise for search - does there need to a knob to do encoded/raw
    access to the header?

Editorial note:
  * examples are all $Keyword, but user-specified keywords don't have
    to start with $.  Should have some examples to demonstrate that.

More confusion over emailId vs Message-Id (RFC822/5322) header.
  * Multiple messages with RFC822-Message-Id can be allowed by the
    server, but they may have different emailId.
  * Indeed, depending on the server, even identical blobs might have
    different blobIds and if they are emails, identical emails might
    have different emailIds.

RFC822 import of invalid message:
  * can JMAP server modify during importMessages e/g stripping NULLs
    or fixing invalid headers?
  * everyone agreed: yes, so long as the server gives a new blobId
    for the message in the response.

Removal of messages or parts for policy reasons (DCMA / virus)
  * needs to be a way to say "POLICY REFUSED" when a message or
    even just blob is requested, regardless of whether the server
    still has a copy.

end.

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


--_----------=_1511755690839690-- From nobody Sun Nov 26 20:20:39 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 921E8126B6E for ; Sun, 26 Nov 2017 20:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=fastmailteam.com header.b=ZP4KCo6p; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y1TkmgCp 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 Lqf8Y5fY3d9J for ; Sun, 26 Nov 2017 20:20:31 -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 2B9821200F3 for ; Sun, 26 Nov 2017 20:20:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4406920B0C for ; Sun, 26 Nov 2017 23:20:30 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sun, 26 Nov 2017 23:20:30 -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=4+6z+MRR73Dxpm6tnU4J9zpL+KvbbOXOxXe++zGwj ZU=; b=ZP4KCo6prZ5s2+U7bHXKva06JHFzjLQHKHMGSchYuFA3/5r6QK5/tDQKJ qFuCivZVyDLLDTiW0s5FgBmGSczS/dT+X/W/7bepJDYTu4bTCHxXOmjfixmCZaFU hiPl2WawbT/BRpoyFNilFN756OWfuR4dGxUPXbd+aHMKW2hSophWTid7aWiPyS2u zDCD4bJhnDI0Wm25kQNI4uIeoKS9xynPWzNTOw5eh13SyMiwIb2z15hdaieZaivl clRlQ8bTq7zzYpncdj4N4eHBJGE59ZeEMcS9LTfH/C4vzWILnMiSL9AfMPCWBZ0r C0dTLrIJtL/OEwzz/n7LJlcYlYL0g== 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=4+6z+MRR73Dxpm6tnU4J9zpL+Kvbb OXOxXe++zGwjZU=; b=Y1TkmgCp8SOGtvUZul3mz/PkdIcArgbkeq6SP/ssOIesi +l0SSIteQKGKdrlCnsHqxbTSkoY2z4R3r4k+cSczLZ21z7JjxiRq29ByjPwYUNRV MS4Y9fc8yFNecMvmGeGiNLt+JvIki1YAhC+g1dj+VUTtrRL6RIKFWjPonaHZU9G0 RWhZ0pZ89FeZ5fsWyLKQpWNUs76aJg04fo4aHGFWB4Y3FjeMKt1BR1w+SfVyAkq5 mWa8Q8ccLvgNJtL43OzxFozAMNoHiHKMFFhGBHhU3KhoV2LLgYGSWz5M0pX+Tk9E VPnw3sW82f+lOEC7OsZ43VoWU31xz81XLqpUMY7dw== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 13C809E0D2; Sun, 26 Nov 2017 23:20:30 -0500 (EST) Message-Id: <1511756429.89064.1185023008.73C13640@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1511756430890642" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a169161c Date: Mon, 27 Nov 2017 15:20:29 +1100 Archived-At: Subject: [Jmap] Thread for discussing body content models 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: Mon, 27 Nov 2017 04:20:34 -0000 This is a multi-part message in MIME format. --_----------=_1511756430890642 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" >From the minutes - we need to discuss the "Emails" object. There were various ideas floated, and I think it would be best to draft up some example MIME structures and how they might look in the response. Relevant issue links: https://github.com/jmapio/jmap/issues/102 (renaming Messages to Emails) https://github.com/jmapio/jmap/issues/103 https://github.com/jmapio/jmap/issues/104 https://github.com/jmapio/jmap/issues/133 I don't think we need to add another issue, probably most of the interesting work should happen against 104. Proposals from the session and in discussions afterwards seemed to be moving towards an array of text or html items, annotated with their source MIME-part number. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_1511756430890642 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
From the minutes - we need to discuss the "Emails" object.  There were various ideas floated, and I think it would be best to draft up some example MIME structures and how they might look in the response.

Relevant issue links:

https://github.com/jmapio/jmap/issues/102 (renaming Messages to Emails)




I don't think we need to add another issue, probably most of the interesting work should happen against 104.

Proposals from the session and in discussions afterwards seemed to be moving towards an array of text or html items, annotated with their source MIME-part number.

Bron.

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


--_----------=_1511756430890642-- From nobody Sun Nov 26 20:30: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 0F00612711D for ; Sun, 26 Nov 2017 20:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.414 X-Spam-Level: X-Spam-Status: No, score=-1.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=EJDPepU6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AkeogJdE 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 nKrhqdXBIrHm for ; Sun, 26 Nov 2017 20:30:42 -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 C3B3C126B6E for ; Sun, 26 Nov 2017 20:30:41 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 37D0820994 for ; Sun, 26 Nov 2017 23:30:41 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sun, 26 Nov 2017 23:30:41 -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=pvvEGc9uEdDsapwlT+Cijy2r/91QO7Nvoo84mqe7b bM=; b=EJDPepU64LurbOob4DWDSP4ofhzEgWRejNRc1627E7w2LjPXGXNzylKvI xNkCs3SvEqejkKFdhjfzBz/NV3YsqUloWttfV4dzT7qPbOUbP25vcy6RUmGu2Ybd PbzA+wFoSHZXDy2AcJogLr3WUWMj4N31441g8bkaHUzN5gqFi9/iGburNrgdEDx8 nqjJqQJCxsozyeZt3qJnOsl7XZ1Kw8rjmXmXOBjHWt8b4c+CIqes0m2yoLRo5PU6 O4DOA9nIxPcwn98QgI4PjbMywrlntz1TNuR6ybaKtd4xE+c21fhLEsWaRMhivFmi nVnUfzHm4OhBuj/AoapFpr+qnV8gg== 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=pvvEGc9uEdDsapwlT+Cijy2r/91QO 7Nvoo84mqe7bbM=; b=AkeogJdEXIhkIWg3DbXRhGzbHgxkj0o6Ff3URtZmUhpr4 sXjK5bsgKsQhsocBBAn4oRPVLNxGZcH1OuUf/lIoHZBK2oN6vE1P0EylH9iGjogt 68i6ymjoQhO5an158aehf7YdCgv2BIlLEdM3/35LiRb673QhRnjT5oft5ivvlNDh KFlGOAphdjb8atPTp/0wQzKlZmvYf4N0fy0QAH9RUXxwQ0Mm+msqshh7TUuZWVMR LDBT6I6kMVdzAPz2wt40BkuibCtsYtcphuaqbi1fjwyWLeM9GkrV17zPHmg7bKGb yCe6N8Kz78KcSPX1cxgPwR5Wniq34JzErIbfrX+hA== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 047919E0D2; Sun, 26 Nov 2017 23:30:40 -0500 (EST) Message-Id: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1511757040930170" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a169161c Date: Mon, 27 Nov 2017 15:30:40 +1100 Archived-At: Subject: [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: Mon, 27 Nov 2017 04:30:43 -0000 This is a multi-part message in MIME format. --_----------=_1511757040930170 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" There was discussion in the room in Singapore about plural names (Mailboxes) rather than singular (Mailbox) e.g. we currently have: getMailboxes getMailboxUpdates getMailboxList getMailboxListUpdates setMailboxes Different words pluralise differently, and it makes it harder than it needs to be to use automatic code generation for standard methods around an object name. The sense in the room was that nobody had a strong enough feeling to push one way or the other (singular or plural), so I'm calling for either agreement on plural, or an argument against it. Silence will be assumed to be agreement here. https://github.com/jmapio/jmap/issues/164 The difficulty is finding names which aren't too verbose: e.g. this is very regular, but long! getMailboxes getUpdatesToMailboxes getListOfMailboxes getUpdatesToListOfMailboxes setMailboxes Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_1511757040930170 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
There was discussion in the room in Singapore about plural names (Mailboxes) rather than singular (Mailbox)

e.g. we currently have:

getMailboxes
getMailboxUpdates
getMailboxList
getMailboxListUpdates
setMailboxes

Different words pluralise differently, and it makes it harder than it needs to be to use automatic code generation for standard methods around an object name.

The sense in the room was that nobody had a strong enough feeling to push one way or the other (singular or plural), so I'm calling for either agreement on plural, or an argument against it.  Silence will be assumed to be agreement here.


The difficulty is finding names which aren't too verbose:  e.g. this is very regular, but long!

getMailboxes
getUpdatesToMailboxes
getListOfMailboxes
getUpdatesToListOfMailboxes
setMailboxes

Bron.

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


--_----------=_1511757040930170-- From nobody Sun Nov 26 20:39:20 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 13D3B127866 for ; Sun, 26 Nov 2017 20:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=fastmailteam.com header.b=Dx9BJwUy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ifa8M2gm 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 w3WqgS4yH6m4 for ; Sun, 26 Nov 2017 20:39:16 -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 876C81271DF for ; Sun, 26 Nov 2017 20:39:16 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EF2A820978 for ; Sun, 26 Nov 2017 23:39:15 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sun, 26 Nov 2017 23:39:15 -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=0bl+/NgRY87NmDMlluwmki+W1hzlfhuHlY7ugV26t hY=; b=Dx9BJwUyWjLFrOXEjjouXRaq3q9ea2+TaCs7OeBQPIsJHr30C/nt8otZY D6ZKiS4QvyqylY894+MkCsZ6NHlkdPPmeXWFrFT01A5WRowBLzKV/gDuvR995/bb T64Bq/bxQZXoqeFLNOhHDrwbeDhAdK5XiGdMXbPXi9T9D+Srig3nohuhrPB7/eAH TdKmSE3Oq4y+4qP98nxOyJkpnCv7ZsX/S3DIH84CppmcibqNzlW80sZqn6cnm4lc RzKwIGVTDrzKLq/01g8PtojsRzTK29qDxuMFkFhwl4LkF4mYBZHVDvD+KL8elihI HY1QJ9D5JduMSbfaLvXikcXRTu82Q== 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=0bl+/NgRY87NmDMlluwmki+W1hzlf huHlY7ugV26thY=; b=Ifa8M2gmETvzg1XzdJGU09SJObTGmX97OI/W2dFIqJ06p Zs9ehRfLE6jTL268Nc0ZQH1jgx79b1nOKQUkYP3cpXBUkBdUfMa+Yehg6chUXlax kisUrHcQfivr5DJG1S8vgoINXYr7fZ0INYnrc03bRmiLAUjZZ+3GboOKoanFPOcf e61HIFqTEm4D2QFgOglPw4Ts8V0OZ+Ib243EzozYcYQom4exGAeWOWUMB0BZXxlc wqJvJkvFO3dV8UUxR90xjTJH6iye5AXt6u0G07mQpXFPt/MrKlEM/beaScjsyFvh q4IWW9tesqC+5D9eXCmsrxK91rzcx7SNg/riL16WA== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id BED1F9E0D2; Sun, 26 Nov 2017 23:39:15 -0500 (EST) Message-Id: <1511757555.96678.1185035608.5CC353FA@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1511757555966780" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a169161c Date: Mon, 27 Nov 2017 15:39:15 +1100 Archived-At: Subject: [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: Mon, 27 Nov 2017 04:39:18 -0000 This is a multi-part message in MIME format. --_----------=_1511757555966780 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" https://github.com/jmapio/jmap/issues/165 The interesting case is headers that contain arbitrary things (like raw message-ids) that aren't necessarily encoded in RFC2047 format. Arguments for decoding everything as it if was: * most clients do this already for everything they display * JSON only transports UTF-8/characters. * you can always fetch the raw message if you need to decode differently. Arguments against: * mostly you won't be displaying unknown headers anyway, but the client might need to use the raw value for something.* means clients have to do their own MIME parsing if they need those headers, and there's no cheap way to get just that header. A potential option is to provide rawheader and rawheader.$name fetch options as well. It adds to server complexity, but not greatly, since the server will have to handle the data in that format anyway. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_1511757555966780 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"

The interesting case is headers that contain arbitrary things (like raw message-ids) that aren't necessarily encoded in RFC2047 format.

Arguments for decoding everything as it if was:
* most clients do this already for everything they display
* JSON only transports UTF-8/characters.
* you can always fetch the raw message if you need to decode differently.

Arguments against:
* mostly you won't be displaying unknown headers anyway, but the client might need to use the raw value for something.
* means clients have to do their own MIME parsing if they need those headers, and there's no cheap way to get just that header.

A potential option is to provide rawheader and rawheader.$name fetch options as well.  It adds to server complexity, but not greatly, since the server will have to handle the data in that format anyway.

Bron.

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


--_----------=_1511757555966780-- From nobody Sun Nov 26 20:41:05 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 35E82127873 for ; Sun, 26 Nov 2017 20:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=sC+lvgUr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fCini5mK 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 trzNCA1eiI0G for ; Sun, 26 Nov 2017 20:41:03 -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 541A81271DF for ; Sun, 26 Nov 2017 20:41:03 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id BCA3B20BB3; Sun, 26 Nov 2017 23:41:02 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 26 Nov 2017 23:41:02 -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=gu27KUIs8QQCnfh35 fi0Cu3J0KSTSsLenSg7UNsUyl0=; b=sC+lvgUrpQ3/CkFQuyxC/4uKHefDOzeR7 F4t1J0a68AUhaWE2YLSjupJf72DfdzV3tgaUhlvBZ4bQKndItm2p9NvkNTm239O9 kL5y29lsX7CT0V5aabjpvfxow6zIS3XETRBqDh5a1TF4F3kVZ7I4Anuz3kNfQdwB kM/zMovNrrHAZ/xVgQ61wtAwHF66RU8oMDR5i/UvLdi4sHgm6ljNRA9793Jmkp0t 4iMr7GEGOQtZLk6YJjNosuzfxxBm2CvazJHpvlJyLEaQj6ubzVH6qDCaTBLihJj6 9iRKcfHBM86mxHDAzV/zq80Av3S0avRIgzyb8ueqbBhx3fbihvVmw== 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=gu27KU Is8QQCnfh35fi0Cu3J0KSTSsLenSg7UNsUyl0=; b=fCini5mKsB5woRU3Ft+kif y0IYKjuvogWTwi3AndIvY1UBgDm1Em0DFA/gRGMTSqb+wppAkjAbMlb+4zK+t0NC A6E3Tc/IqlaD+oqZ1pFiOLkOtDKqxEtdygO1ej/5eO9nSZX0Cxoc2Qcdff4Dy0uW fS2NoAiiXkEUJtif0I/b2zctO3qFyxvubZ2STnrV4as6p/oMJPdbtLky2/m9PHh8 oZIvZ+XKAIIhf71Zugi1rRGzSlcVLGrALjqHJxNsODJXGAUbR+0ws31lTROfpgGD xQEILLS/yDm/bQJzpn0MBeEw/Dgt06OvbSkvMHYyVgKD/DuEeyii8AMzRbl17ASA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 79D71E2584; Sun, 26 Nov 2017 23:41:02 -0500 (EST) Message-Id: <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> From: Neil Jenkins To: Bron Gondwana , IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151175766239924450" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3d96af41 Date: Mon, 27 Nov 2017 15:41:02 +1100 References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> In-Reply-To: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> 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: Mon, 27 Nov 2017 04:41:04 -0000 This is a multi-part message in MIME format. --_----------=_151175766239924450 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Unless there are any objections, I'm going to standardise on plural (because each of these methods deal with multiple instances of the record type, not just one), and go with only a slight variation on the current names (changes in *bold*): getMailboxes getMailbox*es*Updates getMailbox*es*List getMailbox*es*ListUpdates setMailboxes This is nicely consistent, and I think it's more readable than the other alternative we tried (getUpdatesToListOfMailboxes etc.). If I don't get any objections by next Monday, I'll do this. Neil. --_----------=_151175766239924450 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Unless there are any objections, I'm going to standardise on plural (because each of these methods deal with multiple instances of the record type, not just one), and go with only a slight variation on the current names (changes in bold):

getMailboxes
getMailboxesUpdates
getMailboxesList
getMailboxesListUpdates
setMailboxes

This is nicely consistent, and I think it's more readable than the other alternative we tried (getUpdatesToListOfMailboxes etc.). If I don't get any objections by next Monday, I'll do this.

Neil.
--_----------=_151175766239924450-- From nobody Sun Nov 26 20:41: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 06016127873 for ; Sun, 26 Nov 2017 20:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=fastmailteam.com header.b=fOJX1yuu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QR1VecGq 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 SWvH1cmBlQTc for ; Sun, 26 Nov 2017 20:41:19 -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 3C59C1271DF for ; Sun, 26 Nov 2017 20:41:19 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A44D820BB1 for ; Sun, 26 Nov 2017 23:41:18 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Sun, 26 Nov 2017 23:41: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=uP/XF6YOpCv2Ec4Hv vyM84oPZdQ1VQ0SB154hMElFpk=; b=fOJX1yuuSvNCA4MwTm5fXOKBMmwH0hcFg ac/5SKilD2bOk5T1zvceNDzsMcoUm5z7hTlXJBAR39yH7yODuy14bLnGPRwzAqCO h8dy6/6VwkFU4lZbeRJUlHTN2ia0Ipz2BwnzQcsAZ/ViILjLgr2daXcKDjD8w0rZ bj1ir7gBnUaEfHFk8LiImuxs29LaSGUDSAR0B7Zcc/7yIMo+f9nU/YQeV0nQTbqA N4BKUlcJx6T77Eut+gNI3biwkV9sOEhQ99H3j7UEl3vBul1AqvJHY5DQQTj5R8Uv wH4bnbrOVpsoCdkNTob05ggpp6t7Vet12j3b0Vn1Nw7C7UG+Fk52Q== 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=uP/XF6 YOpCv2Ec4HvvyM84oPZdQ1VQ0SB154hMElFpk=; b=QR1VecGq58t7XDc/TkfNY1 SBzCK8yE+Av+8+2icHjmhLrYPWClhn3fOBVXUCRHijQ83OPLp4XfLb4suwfo4FG9 smRZmtuoWHqm03ihEltHOxtTs+cc7SUvuw2e8ZZJ/Iufg38U3eNyoj18qbd0O0nU Se6bCltqRqmDIAcBqOWlwaIX6wSDSWMiJp3xTTqEmfU9L40w6b6kj6czZHbWtrgb K93jodQRtzd+V7ajspZi9nTubuc3v2/Dvx8DSIzDD/U/ErenzapLllw7ZdDhPRNX fIWddig49ARvW1xsU8dEKDd9o0lYOwrU4j29AuTF0+JuwQE8g8DwVee6MDrpje5A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 722B79E0D2; Sun, 26 Nov 2017 23:41:18 -0500 (EST) Message-Id: <1511757678.97129.1185038072.11092EF6@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1511757678971292" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a169161c In-Reply-To: <1511755690.83969.1185022400.1AB2E786@webmail.messagingengine.com> References: <1511755690.83969.1185022400.1AB2E786@webmail.messagingengine.com> Date: Mon, 27 Nov 2017 15:41:18 +1100 Archived-At: Subject: Re: [Jmap] Minutes from Singapore 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: Mon, 27 Nov 2017 04:41:21 -0000 This is a multi-part message in MIME format. --_----------=_1511757678971292 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Mon, 27 Nov 2017, at 15:08, Bron Gondwana wrote: > I've uploaded a copy of these to datatracker, but here's the content > inline as well: I've created separate threads (and github issues) where necessary for everything that felt like it needed to be taken to the list from the meeting. If there's anything else from these notes that you think I didn't capture, let us know! Otherwise we'll assume the consensus in the room was indicative of wider consensus. Thanks, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_1511757678971292 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Mon, 27 Nov 2017, at 15:08, Bron Gondwana wrote:
I've uploaded a copy of these to datatracker, but here's the content inline as well:

I've created separate threads (and github issues) where necessary for everything that felt like it needed to be taken to the list from the meeting.  If there's anything else from these notes that you think I didn't capture, let us know!  Otherwise we'll assume the consensus in the room was indicative of wider consensus.

Thanks,

Bron.

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


--_----------=_1511757678971292-- From nobody Mon Nov 27 11:22:17 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 502D41273B1 for ; Mon, 27 Nov 2017 11:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neiljhaveri-com.20150623.gappssmtp.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 aMsv6qouDogO for ; Mon, 27 Nov 2017 11:22:13 -0800 (PST) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 159FC1242F5 for ; Mon, 27 Nov 2017 11:22:12 -0800 (PST) Received: by mail-pl0-x231.google.com with SMTP id 62so9071679plc.2 for ; Mon, 27 Nov 2017 11:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6A9+K3mIA7lkHmR7vdqcUrcINdsH8aAY0w+pRye5pTM=; b=wKtOayffMurIxTMWAff8VjAsEfnN9vm0ZPa32e3klihQdcl5MAAXNBMncM/kSOAUWI ocdagc0g4DI0m3pPpTTJxhRfxXnyor4F01Reap+Nes2S/7zKL9fjfyn/EBGvWiNcAl49 5uezIAMjZOk+6lecnOk53XzHHgQWCfKNwEOp8em/FkbDEsITdee0X/t4cl0kXQmlLtwu qLvDqUMWfCFXwVs5fupG1a7Bl9h9T8WJgkY5UAhCvoRqhFlgzA4xNqfgZUoM1IBuc62w gOYg4MvEydrXIEXm3m2BTAtC5tGA3iNyRt5I2sPHBBjEufW+D3OjG7BFN6XOtRwYPM2N yfqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6A9+K3mIA7lkHmR7vdqcUrcINdsH8aAY0w+pRye5pTM=; b=Mdf/MXN+bxxEOeox16ZxPXaQIsCIu6LNSr1m1Jw0gMkNdsYCdlBiszOJV84UyIpkcU dMHsKSUPgMUhrpqvKsZdttShGCavCHToi+bEq5ExFb+M9tVy/1nPnu8tLfcoeEp33s4f MgJ+MetwVAjxXKLbTLkIE55iomZ4QNbGLSlHYhe7vfvm0GePYsynxxUcDgt2RLCpLApy TCsO7RxcBc94ItUdHthHNERKAwZXRL/GG330Kx/VUbI/YV5btWhHV6DtTA3mdZBEOrsV 6Ql9Bh5uFokn6N4rYBfPeXfIGTRiRKfe2yf1GQDNHKb6BwSIdUhkh+5IuMBeJfl1yvSS Om/w== X-Gm-Message-State: AJaThX7FrdZTQz2VcG5AzNCAgY6ibfl7w6pTiwAsRn+e1Rw1rLnk1aBE ZvX5seMozRVrD5CCBqL1aUVY+2teGr0= X-Google-Smtp-Source: AGs4zMZoU4v4V/vhJMBm5rRWlTdrEMrh9UkZRvN/ZXgseIz2wiVt4Km26BCe7F/4UI9zcIW825TuQg== X-Received: by 10.159.231.15 with SMTP id w15mr5669376plq.410.1511810532420; Mon, 27 Nov 2017 11:22:12 -0800 (PST) Received: from [192.168.1.3] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id z86sm55996745pff.4.2017.11.27.11.22.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 11:22:11 -0800 (PST) From: Neil Jhaveri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_23D3BA64-86A4-4008-9BC6-002324413708" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 27 Nov 2017 12:22:09 -0700 In-Reply-To: <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> Cc: Bron Gondwana , IETF JMAP Mailing List To: Neil Jenkins References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3273) 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: Mon, 27 Nov 2017 19:22:15 -0000 --Apple-Mail=_23D3BA64-86A4-4008-9BC6-002324413708 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Seems pretty reasonable to me. > On Nov 26, 2017, at 9:41 PM, Neil Jenkins = wrote: >=20 > Unless there are any objections, I'm going to standardise on plural = (because each of these methods deal with multiple instances of the = record type, not just one), and go with only a slight variation on the = current names (changes in bold): >=20 > getMailboxes > getMailboxesUpdates > getMailboxesList > getMailboxesListUpdates > setMailboxes >=20 > This is nicely consistent, and I think it's more readable than the = other alternative we tried (getUpdatesToListOfMailboxes etc.). If I = don't get any objections by next Monday, I'll do this. >=20 > Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap = --Apple-Mail=_23D3BA64-86A4-4008-9BC6-002324413708 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Seems pretty reasonable to me.

On = Nov 26, 2017, at 9:41 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:

Unless there are any objections, I'm going to standardise on = plural (because each of these methods deal with multiple instances of = the record type, not just one), and go with only a slight variation on = the current names (changes in bold):

getMailboxes
getMailboxesUpdates
getMailboxesList
getMailboxesListUpdates
setMailboxes

This is nicely consistent, and I think it's more readable = than the other alternative we tried (getUpdatesToListOfMailboxes etc.). = If I don't get any objections by next Monday, I'll do this.

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

= --Apple-Mail=_23D3BA64-86A4-4008-9BC6-002324413708-- From nobody Tue Nov 28 05:58:39 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 42D231243F6 for ; Tue, 28 Nov 2017 05:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O7GIUoNKlZv for ; Tue, 28 Nov 2017 05:58:37 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0B51200E5 for ; Tue, 28 Nov 2017 05:58:37 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id 250252AEF41; Tue, 28 Nov 2017 15:58:34 +0200 (EET) Date: Tue, 28 Nov 2017 08:58:38 -0500 From: Josef 'Jeff' Sipek To: Neil Jenkins Cc: Bron Gondwana , IETF JMAP Mailing List Message-ID: <20171128135837.GB2390@meili> References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1511757662.3992445.1185036616.16BB84D6@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: Tue, 28 Nov 2017 13:58:38 -0000 On Mon, Nov 27, 2017 at 15:41:02 +1100, Neil Jenkins wrote: > Unless there are any objections, I'm going to standardise on plural > (because each of these methods deal with multiple instances of the > record type, not just one), and go with only a slight variation on the > current names (changes in *bold*): > > getMailboxes > getMailbox*es*Updates > getMailbox*es*List > getMailbox*es*ListUpdates > setMailboxes Why not singular? That is: getMailbox getMailboxUpdates getMailboxList getMailboxListUpdates setMailbox After all, the object is called Mailbox and not Mailboxes. Yes, the methods return an array of them, but using the singular term seems less awkward to me since it avoids the double-plural in the get*Updates method names. I don't care that much (IOW, plural is fine), but I thought I'd point out another possible color for the bike shed :) Jeff. > This is nicely consistent, and I think it's more readable than the other > alternative we tried (getUpdatesToListOfMailboxes etc.). If I don't get > any objections by next Monday, I'll do this. > Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Fact: 26.7% of all statistics are generated randomly. From nobody Tue Nov 28 06:11:06 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 9E44F126C25 for ; Tue, 28 Nov 2017 06:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAh2xg837UHB for ; Tue, 28 Nov 2017 06:11:04 -0800 (PST) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1E55D1200E5 for ; Tue, 28 Nov 2017 06:11:04 -0800 (PST) Received: from meili (josefsipek.net [71.174.113.7]) by mail.dovecot.fi (Postfix) with ESMTPSA id E38762A6902; Tue, 28 Nov 2017 16:11:02 +0200 (EET) Date: Tue, 28 Nov 2017 09:11:06 -0500 From: Josef 'Jeff' Sipek To: Bron Gondwana Cc: jmap@ietf.org Message-ID: <20171128141105.GC2390@meili> References: <1511757555.96678.1185035608.5CC353FA@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1511757555.96678.1185035608.5CC353FA@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: Tue, 28 Nov 2017 14:11:05 -0000 On Mon, Nov 27, 2017 at 15:39:15 +1100, Bron Gondwana wrote: > https://github.com/jmapio/jmap/issues/165 > > The interesting case is headers that contain arbitrary things (like raw > message-ids) that aren't necessarily encoded in RFC2047 format. > Arguments for decoding everything as it if was: > * most clients do this already for everything they display > * JSON only transports UTF-8/characters. > * you can always fetch the raw message if you need to decode > differently. > Arguments against: > * mostly you won't be displaying unknown headers anyway, but the client > might need to use the raw value for something. > * means clients have to do their own MIME parsing if they need those > headers, and there's no cheap way to get just that header. Right now, jmap doesn't "gracefully degrade" the experience. If a client wants to do the boring few things, jmap rocks. However, the moment the client strays from just getting the subject/to/date/body for *any* reason, the client suddenly has to implement a ton of RFCs (MIME, RFC5322, etc.) and the experience degrades to something like IMAP. So, I'm a bit wary of "just fetch the raw blob and parse it yourself". (This is the same concern as with the message representation discussion.) > A potential option is to provide rawheader and rawheader.$name fetch > options as well. It adds to server complexity, but not greatly, since > the server will have to handle the data in that format anyway. rawheader should work. We could avoid dealing with UTF-8 by base64 encoding the string. (IIRC, at least one popular email API out there uses base64 encoded strings to transport potentially non-UTF-8 data to the client through JSON.) Jeff. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan From nobody Tue Nov 28 08:00:51 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 BF0D112714F for ; Tue, 28 Nov 2017 08:00:49 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_QOy5htrkzT for ; Tue, 28 Nov 2017 08:00:45 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 37CC61270B4 for ; Tue, 28 Nov 2017 08:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1511884844; d=isode.com; s=june2016; i=@isode.com; bh=/qqPdLMqI9iZXnoWSqihvk+am/DYVWJuAQDyKB/uzeU=; 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=Py7NGyk4Y+QtONwUUYaUtHqKb/t1cVsMLCfBULtL/IX2PkJe2e3mNyr6IeLoty2QN9C8OX RA6GOyO+QQkzvjRHfTCGz7qxPahhMzImn5DWFF9W7RUI57IANQc20K8oXPMhpreR/KN7o/ phyS04Va3cm1T8RlSaN10J/t+PUR8X0=; 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 ; Tue, 28 Nov 2017 16:00:44 +0000 To: Josef 'Jeff' Sipek , Bron Gondwana Cc: jmap@ietf.org References: <1511757555.96678.1185035608.5CC353FA@webmail.messagingengine.com> <20171128141105.GC2390@meili> From: Alexey Melnikov Message-ID: <9ef19c08-d314-c22b-e628-d07936fa5d39@isode.com> Date: Tue, 28 Nov 2017 16:00:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: <20171128141105.GC2390@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: Tue, 28 Nov 2017 16:00:50 -0000 On 28/11/2017 14:11, Josef 'Jeff' Sipek wrote: > On Mon, Nov 27, 2017 at 15:39:15 +1100, Bron Gondwana wrote: >> https://github.com/jmapio/jmap/issues/165 >> >> The interesting case is headers that contain arbitrary things (like raw >> message-ids) that aren't necessarily encoded in RFC2047 format. >> Arguments for decoding everything as it if was: >> * most clients do this already for everything they display >> * JSON only transports UTF-8/characters. >> * you can always fetch the raw message if you need to decode >> differently. >> Arguments against: >> * mostly you won't be displaying unknown headers anyway, but the client >> might need to use the raw value for something. >> * means clients have to do their own MIME parsing if they need those >> headers, and there's no cheap way to get just that header. > Right now, jmap doesn't "gracefully degrade" the experience. If a client > wants to do the boring few things, jmap rocks. However, the moment the > client strays from just getting the subject/to/date/body for *any* reason, > the client suddenly has to implement a ton of RFCs (MIME, RFC5322, etc.) Exactly. > and the experience degrades to something like IMAP. IMAP certainly fails to degrade gracefully in a similar way. If certain data is not easily available, the client needs to go out of its way to get the date (e.g. try to do S/MIME multipart/signed validation using IMAP without MIME parser...). But I digress. > So, I'm a bit wary of "just fetch the raw blob and parse it yourself". > (This is the same concern as with the message representation discussion.) > >> A potential option is to provide rawheader and rawheader.$name fetch >> options as well. It adds to server complexity, but not greatly, since >> the server will have to handle the data in that format anyway. > rawheader should work. I think this would be the best, as rawheader instructs the JMAP server not to be clever and just return a particular header field value. > We could avoid dealing with UTF-8 by base64 encoding > the string. (IIRC, at least one popular email API out there uses base64 > encoded strings to transport potentially non-UTF-8 data to the client > through JSON.) Works for me. From nobody Tue Nov 28 19:11:39 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 73561126E7A for ; Tue, 28 Nov 2017 19:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=BX8xR1IT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LfPAslrd 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 izHYsEf_hQoZ for ; Tue, 28 Nov 2017 19:11:36 -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 5819A1200C1 for ; Tue, 28 Nov 2017 19:11:36 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 92C4420D6A; Tue, 28 Nov 2017 22:11:35 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 28 Nov 2017 22:11:35 -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=jCqVBor2yXNm9F1Le r74IqlyIIV6cYV9Vz/ujjZqQ2U=; b=BX8xR1ITgM61RuWwECLcmSfHdmdEjOqNJ H6oh0HAFRe19SzSCISh/0GcoIaQJcMHKsE/yfDa+xY2Vv/YblTX9QBeYHLjrq0EJ Y67VJxhDg2/pn5xj6PDbp0mzCFpQVqf3u9MjpZzxmD/ZFVQunQ8c9kFNhn/myog+ B/Sss2nrLyyP+TXCTnGrAZQgzXQNq8vOV1lMqVto//zQGQ6dL/hJQoCGUpyYQ9mV MQiwk1FRvS1kjcjgq31WoB7HDI+w9PcZV17KaI5T9Xwj/Lqsumro88tATymo7i8d mefMW+7gjHYqAymdEYKGgo0w3UAEBFOyhbvuLAeGqGbYLmeYMxAyA== 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=jCqVBo r2yXNm9F1Ler74IqlyIIV6cYV9Vz/ujjZqQ2U=; b=LfPAslrdH6DrPBtve6qrPk Ls2Uobb3oFpRYpfiyXI4nAo/qXRtb+Oh1P+7gMh12fJ/rJjJGnBeoYWEDWG3pNMH i+7j50pm/o5j0ULEtpm8ssRIKKJZcbReMgFXFgzxtvp3dTGb5JhPGF8NB9rOW/37 Y2trTbQHDLBW8Tem3bKKsIJ0EASRFZ6q3+6CaPGetLUfKlgXxyzRYkX5tY6iJP35 /q0MQH/ZYHGXYqm9DVfs5rbu5l3k1eCKE/lw5YsdfQhbb2qaayK0V48lcZFG3kgZ 2a5AAQY76h+uqKuC26jEc3aH8iOwAMmEeA7nmK1DWOKkBp9wfoAmLa+XoQ77IoZQ == 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 1DFFA7EDB4; Tue, 28 Nov 2017 22:11:35 -0500 (EST) References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> <20171128135837.GB2390@meili> Mime-Version: 1.0 (1.0) In-Reply-To: <20171128135837.GB2390@meili> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: Neil Jenkins , Bron Gondwana , IETF JMAP Mailing List X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Tue, 28 Nov 2017 22:11:31 -0500 To: Josef 'Jeff' Sipek 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: Wed, 29 Nov 2017 03:11:37 -0000 > On Nov 28, 2017, at 8:58 AM, Josef 'Jeff' Sipek wr= ote: >=20 >> On Mon, Nov 27, 2017 at 15:41:02 +1100, Neil Jenkins wrote: >> Unless there are any objections, I'm going to standardise on plural >> (because each of these methods deal with multiple instances of the >> record type, not just one), and go with only a slight variation on the >> current names (changes in *bold*): >>=20 >> getMailboxes >> getMailbox*es*Updates >> getMailbox*es*List >> getMailbox*es*ListUpdates >> setMailboxes >=20 > Why not singular? That is: >=20 > getMailbox > getMailboxUpdates > getMailboxList > getMailboxListUpdates > setMailbox >=20 > After all, the object is called Mailbox and not Mailboxes. Yes, the metho= ds > return an array of them, but using the singular term seems less awkward to= > me since it avoids the double-plural in the get*Updates method names. >=20 > I don't care that much (IOW, plural is fine), but I thought I'd point out > another possible color for the bike shed :) I, too, find it less awkward without the double-plural, but sticking with on= ly singular or only plural is still a vast improvement. Thanks, Stan From nobody Tue Nov 28 19:24: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 EBD2312778E for ; Tue, 28 Nov 2017 19:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=fastmailteam.com header.b=KdRbu/bQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LiCUSIX/ 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 hmhdu8mEe2Da for ; Tue, 28 Nov 2017 19:24: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 425BC12741D for ; Tue, 28 Nov 2017 19:24:08 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 9E4A0208C0; Tue, 28 Nov 2017 22:24:07 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 28 Nov 2017 22:24:07 -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=qAM2Xe W3bdiNuuyH+wW3HMCWjeFOIfMAay22/s215Ek=; b=KdRbu/bQNA0iJbJVulPTan 6lYbG/arlfQ6iN/tWt9ZCWpO/rlbta+mk5/2Qql4KiL6cwaMIsf76ggYgrfZkmz2 YiI7vDXpWps75KNl3kaXaUpPspr4IiIfa+d+jzN35ppF6keJ4dwBoB8xGLqOMbS4 FX7vsuUNRs6nXVlOevlXQS3VImna2u32yC55FYjYT4pectFdAnuWE4cFawAgWGNI yFjTIbxGNVlA4DxzPzeCOXFFViRV9q4Ha5JjokbwKSrLyk+cKszCsemkcLmqCoO6 05yWsgnUccjXou9aHuNNG6RuNDawH2Yh6OavsYoOVLi2pJTow2nIaMKTI5ZWz/ww == 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=qAM2Xe W3bdiNuuyH+wW3HMCWjeFOIfMAay22/s215Ek=; b=LiCUSIX/d+xVN01/sWBYIK L3UDuc+RByMepQFwahuW9VHeMOZqy4eEpRTphJ9Lp9EE2ypp8UyfsppSTJo23yGO uqiOFyB7vt9UidQleRpo5dOlg9Elzr1Ucqk+iStQ5sP0VgHpzPBBZlV7aMNBgtTy 5Vz6yRfOsjCSexcSL+WAi2KIgCLSSytdJ4yW7Ij00XLboISiyCKcuyPcZXSCKcYX zVcwPFPWCBKL5+yyj27F0VwHc47UTIqYFxl3Nj2z1LqSHhoF9vqONvYM0Q4Y2EIA nL0U8d98qJtWMZdJEbKYzkDIz4n+EaGHf7g0TRzI6jfQbgqM/+q2tXsria88fNWw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 57541E226F; Tue, 28 Nov 2017 22:24:07 -0500 (EST) Message-Id: <1511925847.2214786.1187644272.47957DBF@webmail.messagingengine.com> From: Neil Jenkins To: Stan Kalisch , Josef Jeff Sipek Cc: Bron Gondwana , IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151192584722147865" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3d96af41 In-Reply-To: References: <1511757040.93017.1185031768.0A828C4D@webmail.messagingengine.com> <1511757662.3992445.1185036616.16BB84D6@webmail.messagingengine.com> <20171128135837.GB2390@meili> Date: Wed, 29 Nov 2017 14:24:07 +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: Wed, 29 Nov 2017 03:24:10 -0000 This is a multi-part message in MIME format. --_----------=_151192584722147865 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" For completeness, copying to the list another suggestion from the GitHub ticket[1]: 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.) Not sure what response names you would use with this. > 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. 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. Links: 1. https://github.com/jmapio/jmap/issues/164 --_----------=_151192584722147865 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
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.)

Not sure what response names you would use with this.

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. 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.
--_----------=_151192584722147865-- From nobody Tue Nov 28 19:59: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 AA8FC12704A for ; Tue, 28 Nov 2017 19:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=fastmailteam.com header.b=Q0vrbVuf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gP1Ar/ZP 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 jf9Kl_KXFKBK for ; Tue, 28 Nov 2017 19:58:59 -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 3413B1243F3 for ; Tue, 28 Nov 2017 19:58:59 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 5F47220A4B for ; Tue, 28 Nov 2017 22:58:58 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 28 Nov 2017 22:58:58 -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=XilPad/Inuhwv0BYc ogqPk1JNlEsHtLFIaR909ZysVo=; b=Q0vrbVufBkAlrKOkJUhVRmjvraDY8cbqV 2dJo4gWMgbUng+zcs9kHNuu/TU0brSLPMkZQSW1Vzg49/IysyNHJclWyYvWIhCNb J3RRoJlrQmNlr2lI3/r8EJdd1WIMOjjqwS9X92bHrPa1TP94nInyoxqOsEjlJvoB uNZuQK5WTvytdW7n+J13hN+I1OLtsxyesSIUH5ZllQ8WJj8FNrYaAEuZEoG+BUY8 z9Ab7g4xAYNo3EW2EQezPY3bpsvzskNQgWm0Tix0+lwp09t/+VspEzSTBr3dSdmK wozCKpuXcKL+RP/giixCvFhoBGLGG1QoimzYlgPQ/6e7D8kGtm+FQ== 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=XilPad /Inuhwv0BYcogqPk1JNlEsHtLFIaR909ZysVo=; b=gP1Ar/ZPj+JdbEBebOpvKY Sbd0ul1m3ALQkId+ciBm9Svu5vgxUyUEuu3vB1HI7lQp30zw3Z1Edbc1GlYTKZDa Ay3YI5C6jrxGoFz6u/spKsR3vmBeGuFiKgxD471Y7J1tvks/D9Ed4D+ynjh/bVGk cyrXceNtOmeeZQRiWrjjSDO5VHi2iEUwjj4Vr9EfNJqZJcIFZtSs7o63S9JwsG5b Y8EHs5OZbfBxH+0zYLF8ZoGWMShysFYN2cqd2+WOAP5ATTd1JnvveDa8LdGAKQDY msKr3ddZQW4vV3OQ2/n2bawEb7jgylkyDjQrSAqtFrhI2CRxamOT1SGunlqvZvmQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 08BB9E226F; Tue, 28 Nov 2017 22:58:57 -0500 (EST) Message-Id: <1511927937.2243688.1187666736.7A1F4129@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151192793722436882" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3d96af41 Date: Wed, 29 Nov 2017 14:58:57 +1100 References: <1511757555.96678.1185035608.5CC353FA@webmail.messagingengine.com> <20171128141105.GC2390@meili> <9ef19c08-d314-c22b-e628-d07936fa5d39@isode.com> In-Reply-To: <9ef19c08-d314-c22b-e628-d07936fa5d39@isode.com> 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: Wed, 29 Nov 2017 03:59:01 -0000 This is a multi-part message in MIME format. --_----------=_151192793722436882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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. One possible syntax: "getMessages", { ... "properties": [ "headers.received:decoded+all" "headers.from:raw", "headers.to:emails", "headers.subject:decoded", "headers.date:date" ], } and then the Message object would look something like: { "headers": { "received": { "type": "decoded+all", "value": [ "from mx2 ([10.202.2... etc.", "from mx2.messaginge... etc." ] } "from": { "type": "raw", "value": "...base64..." }, "to": { "type": "emails", "value": [ {"name": "Joe Bloggs", "email": "joe@example.com"}, {"name": "Jane Doe", "email": "jane@example.com"} ] }, "subject": { "type": "decoded", "value": "10 =C3=A5r med forn=C3=B8yde kunder" }, "date": { "type": "date", "value": "2017-11-11T18:09:31+01:00" } } } This gives a lot of flexibility to clients, but is a bit verbose. On the other hand if you kept the "from", "to", "subject" top-level properties as shortcuts for common header requests, most clients wouldn't need to fallback to the verbose form so much. 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. Thoughts? Neil. --_----------=_151192793722436882 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Some thoughts:

We currently have the following properties which represent parsed form= s of headers: sender, from, to, cc, bcc, replyTo, subject, date. You can al= so request (decoded but otherwise unparsed) headers using the "headers" pro= perty. 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 extensi= ble 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 he= aders of the same name; maybe you can explicitly request to receive all (as= an array), otherwise you get the last one of that name.

One possible syntax:

"getMessages", {
  ...
  "properties": [
    "headers.received:decoded+all"
<= /div>
    "headers.from:raw",
    "headers.to:emails",
    "headers.subject:decoded",
    "headers.date:date"
  ],
}

and then the Message object would look something like:

{
    "headers": {
        "received": {
          &= nbsp; "type": "decoded+all",
          &= nbsp; "value": [
          &= nbsp;     "from mx2 ([10.202.2... etc.",
          &= nbsp;     "from mx2.messaginge... etc."=
          &= nbsp; ]
        }<= br>
        "from": {
          &= nbsp; "type": "raw",
          &= nbsp; "value": "...base64..."
        },=
        "to": {
          &= nbsp; "type": "emails",
          &= nbsp; "value": [
          &= nbsp;     {"name": "Joe Bloggs", "email": "joe@example.com"= },
          &= nbsp;     {"name": "Jane Doe", "email": "jane@example.com"= }
          &= nbsp; ]
        },=
        "subject": {
          &= nbsp; "type": "decoded",
          &= nbsp; "value": "10 =C3=A5r med forn=C3=B8yde kunder"
        },=
        "date": {
          &= nbsp; "type": "date",
          &= nbsp; "value": "2017-11-11T18:09:31+01:00"
        }<= br>
    }
}

This gives a lot of flexibility to clients, but is a bit verbose. On = the other hand if you kept the "from", "to", "subject" top-level properties= as shortcuts for common header requests, most clients wouldn't need to fal= lback to the verbose form so much. You could also default to type "decoded"= if no other processing explicitly requested, and possibly even drop the {t= ype, value} wrapper for headers with the default decoding.

Thoughts?

Neil.
--_----------=_151192793722436882-- From nobody Tue Nov 28 21:04:26 2017 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 466EF1200F1; Tue, 28 Nov 2017 21:04:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151193186423.8078.8760535668478396068@ietfa.amsl.com> Date: Tue, 28 Nov 2017 21:04:24 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-03.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 05:04:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JSON Meta Application Protocol Author : Neil Jenkins Filename : draft-ietf-jmap-core-03.txt Pages : 44 Date : 2017-11-28 Abstract: This document specifies a protocol for synchronising JSON-based data objects efficiently, with support for push and out-of-band binary data upload/download. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-core/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-core-03 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 28 21:06:08 2017 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB771200F1; Tue, 28 Nov 2017 21:06:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151193196054.8029.2110591906550279676@ietfa.amsl.com> Date: Tue, 28 Nov 2017 21:06:00 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-03.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 05:06:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Mail Author : Neil Jenkins Filename : draft-ietf-jmap-mail-03.txt Pages : 42 Date : 2017-11-28 Abstract: This document specifies a data model for synchronising email data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mail/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mail-03 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 29 16:20: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 13D7D128B37 for ; Wed, 29 Nov 2017 16:20:10 -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, 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, 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=Kg3rzN7O; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bIFBLonj 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 ot9CCAJBwbrf for ; Wed, 29 Nov 2017 16:20:04 -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 9C2CA128B38 for ; Wed, 29 Nov 2017 16:20:02 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id D6FB6209F3 for ; Wed, 29 Nov 2017 19:20:01 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 29 Nov 2017 19:20:01 -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=sTseC+EhX2RTzOqLR 5bftXaSH1H0Y28kHjIIjGucRho=; b=Kg3rzN7O7tH3qem/tbFMGCbFAw9kltlEc B2BEGGoDwkUdqmHdiVx59Q+4gE8EO0hUH/UtXXsmVjgA1OF4aYM7Ea0VdHHd5GAf mAuCJTtVDHUnr4HpJ0UJrBVTpNF4ajGADZYtSKsttkEYSIj1qqXHkEHMellUcDVA aoIzybO5zuaKdfxJT9zxQMgDdbOWhPDeGq1vx9LMkWM0n1e0iQ08+t1Np2lrRkC1 7cyzm+f6ZhT9af6jvtsM62wGNzJd4EusuwIxKQH2v08XxALXUBnvDyNrDiHS5rVP pznQC9oD1ZV7XeE2E4T2O/tvyeLWLBpcopoQ7VPEScodszJsrPMBA== 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=sTseC+ EhX2RTzOqLR5bftXaSH1H0Y28kHjIIjGucRho=; b=bIFBLonj6KkyNaojZB8LD2 rYqZExOjJgxVUlWqG2y4FidKqYRADCC1dAtc3L7wa5NNEnjdloVt2aCQaI39Xiyf n0ddQrXMSHVy2ADhGpVGBFsp/SkCIajKCiU3T6cGhEgh3npslRiFDe9GQ6c36vBu yM8zh7G49Sn5G08qxIGLjSkAUjOT3PDRqVt+gVEJtLPNm4kj8tQKlus7fg1jjDwA noRf3sCOxtG9Y2BEX7NQTtLw4+3x60PnzvtPXuIuWFHhNrs33hlAuOt94PIyV3Qx HIZ5kmFrwPECwh371nstvbD1Igsr46rZZ8OGl3688mDJLZvfWOGnoYIPHi8snN+Q == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 76797E2944; Wed, 29 Nov 2017 19:20:01 -0500 (EST) Message-Id: <1512001201.3289077.1188813640.53BFE5FE@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151200120132890771" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3d96af41 In-Reply-To: <49FEE67A-747A-447B-840C-675E2EE23101@fugue.com> Date: Thu, 30 Nov 2017 11:20:01 +1100 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> 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: Thu, 30 Nov 2017 00:20:10 -0000 This is a multi-part message in MIME format. --_----------=_151200120132890771 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" 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://github.com/jmapio/jmap/pull/145/files --_----------=_151200120132890771 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
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.
--_----------=_151200120132890771--