From nobody Thu Mar 1 07:14:38 2018 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 456EE12E04F for ; Thu, 1 Mar 2018 07:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 fajZYWPiQfW2 for ; Thu, 1 Mar 2018 07:14:35 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 7482512D77E for ; Thu, 1 Mar 2018 07:14:35 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id s1so3871927vke.5 for ; Thu, 01 Mar 2018 07:14:35 -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=42LRw7VnhoqYbaxVPI496W3BQk7kR4kfBt6bb28f88w=; b=LhtLBmeWWCmeerPoM6MZQbQV0IRbPil48fXSEpQrCjaICMzN1tmkXO+3bo7I2nRfv7 3QNEtxlZomA/RktaAAnxabMerFlbOusVBC1XIfj0PU1Vc52JiyESXzKJPT2wbSPsVsnC wooQ3KPwiVZrAj/ji+/TNQLZ4Fg3G8HqAky56NkpxaalheO/BVRGbuPZX99OK6KTsRwM Sxz+ubJNPHLo+wo1HddV6Qmwl4zLa0KtQZ+ciYXLFGMAHJ6riYuRHJmUEDSnviPDMOgq UydkEA4JbcXGaH+J3st393LMxVJvqGBKEYIRxdfnaBr52xAdR8JwknridZztcwapbyry e+HA== 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=42LRw7VnhoqYbaxVPI496W3BQk7kR4kfBt6bb28f88w=; b=K8IPPVT/miRmJgcWccyPNQQag9iHLE+R9hnAWih4mSQXk7bR8r6ISi7mzywPZTqNLF KBmIz7tvOnXrfTylbPfWM5ebe+/YyhRf224lbwDOMoVdAH7RyzNiD75zhb8P9lhgCQFY xh8RLB9VoqdS0myXsQLZsuzEkLVq4RFdOmLae3O+JuMnMBYSsKXe/kdsmHsPbEymY/VR yyfGqfQafF2+57d53MV/qufyv3iyI417jM/OCvkFwN3XYMsOFVGGOlY2dU4GkvqJO1wS gBH+tAi1v1zOdJGR2Vhw5RfX6s1MQlI8SIiQwDiabWlSPsfTjn3XEXQUOVnHXbr4OHhu ebAw== X-Gm-Message-State: APf1xPDBxqdr/cpOhF5ZVcBuYmTFEynL45L/gTYlGs0FShnH1c1dKfQ4 d+B8Mt8+/rJTymwmsVcSxAxFUIs1u9EExnt2tm6MJZi+ X-Google-Smtp-Source: AG47ELsXdfyUXxJ/Ke6E9Vyleq1ZaC5ro/R9v3ycejWGi8akWGf+AAw4QXmoa39vYlPXoBLNuhjsaZp8iqt579dfFC0= X-Received: by 10.31.154.200 with SMTP id c191mr1417168vke.60.1519917274266; Thu, 01 Mar 2018 07:14:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.147.145 with HTTP; Thu, 1 Mar 2018 07:14:33 -0800 (PST) From: "Matthew Horsfall (alh)" Date: Thu, 1 Mar 2018 10:14:33 -0500 Message-ID: To: jmap@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Jmap] Handling of unknown properties in /get properties section 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, 01 Mar 2018 15:14:37 -0000 How should unknown properties that the client hands in to a /get call be handled? The spec https://github.com/jmapio/jmap/blob/master/spec/jmap/api.mdown#get says: properties: String[]|null If supplied, only the properties listed in the array are returned for each Foo object. If null, all properties of the object are returned. The id of the object is always returned, even if not explicitly requested. Later, in the Security section: https://github.com/jmapio/jmap/blob/master/spec/jmap/api.mdown#security : As always, the server must be strict about data received from the client. Arguments need to be checked for validity; a malicious user could attempt to find an exploit through the API. In case of invalid arguments (unknown/insufficient/wrong type for data etc.) the method MUST return an invalidArguments error and terminate. To me this seems to say that: [["Mailboxes/get", { "ids": [ "m1" ], "properties": [ "name", "oops" ], }, "0"]] should return invalidArguments because "oops" is unknown. This would help consumers of the API find bugs in their code if they typed "parentid" instead of "parentId", for example. -- Matthew Horsfall (alh) From nobody Thu Mar 1 12:52:51 2018 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 827DB12FAA5 for ; Thu, 1 Mar 2018 12:52:50 -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 3K9r7h9m17MP for ; Thu, 1 Mar 2018 12:52:49 -0800 (PST) Received: from mail-pl0-x22a.google.com (mail-pl0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) (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 D349E12FA9F for ; Thu, 1 Mar 2018 12:52:48 -0800 (PST) Received: by mail-pl0-x22a.google.com with SMTP id y8-v6so4335086pll.13 for ; Thu, 01 Mar 2018 12:52:48 -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=n2Fl3HVGAMp7s9xEpbx0S7fq8n1TjwIyyjqhV2IORB8=; b=c07byD9BW1yU0xnPRAwJCrqDkroN+6uO5lVfYK4R5mnnJfXOs8tH7bMX2GNyejY9P0 ysodB0jj5QCmyp6HohomdCtvYl9lWfCDye/KpcwjbX+bylXrlnLXnBrt46MzFMgj5za9 FAJ+4whKfAN3HPTpKZZG2l6AzPGqemRoDf2O1pZf05XQ9I7t0+Kb9oYUpbiFdLX1DM+u o4/hbmP9ArbF6LLa6GDpOAi5g7wl1Is86mcnXyWxTWWLu8hsNa+ch+2tka2qDtSdfhZU OZ9oSv3l7T3tjtDHRQv6de21V6D/YDchNsKJW4hdwOa7sKhWApy3x+P3jZ5DE9xw6onx gM7Q== 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=n2Fl3HVGAMp7s9xEpbx0S7fq8n1TjwIyyjqhV2IORB8=; b=cL/RzbU9XwLbLmxjyxiikcF29rnR3R1j0twFMw58nP3oVP+qg4lfjxq1J5FXH2mwwF d20sQFPgTMXD0IvrMyjxcLLqGSw/OG/0e0SMeXjk2YpFQLYmkFph4x7MkgBHp/Ds5LI5 r59JMYsgwC7D07xkyFzFqHVnykMQD5Qj/H2emGbd2NA9J+T7Ylh3CGXlbSPKnxmfNGI+ VOQgtqHIO+1e61AaYpTzjFl3zwRw723udJcFsrQzzMSGGPjgbuvKjxshrOdw1FpeAKZc pjqTqNtiA2nfQCxLGlkU6P2AMX6B3wh57Gtr9sKINhTkd7MC4wsMJ+5eTFWN8/m0NbZf tKMA== X-Gm-Message-State: APf1xPAeWrUU+By7KpXhcZTff/JQIQf4iHOWQrPN+tWSm42CGAuxLK9v PLrxuEAS6vKox6NT8vQuGSd5lv4q6X8= X-Google-Smtp-Source: AG47ELtnL2oeMhBlRDGZrZCS4R3MiQZ/sIqpTFEws1zGV9aaE0EMpoqqj14+8rZkKW0SfrPkhOdSjQ== X-Received: by 2002:a17:902:4643:: with SMTP id o61-v6mr3114453pld.103.1519937568207; Thu, 01 Mar 2018 12:52:48 -0800 (PST) Received: from ?IPv6:2601:646:4000:6640:48fd:a3ff:cecd:ed37? ([2601:646:4000:6640:48fd:a3ff:cecd:ed37]) by smtp.gmail.com with ESMTPSA id q20sm9484816pgc.84.2018.03.01.12.52.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 12:52:47 -0800 (PST) From: Neil Jhaveri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5575CA6E-41E5-4E61-ADEF-AF1AE99ACB69" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 1 Mar 2018 12:52:46 -0800 In-Reply-To: <1518420407.1012131.1267607120.3E7422B3@webmail.messagingengine.com> Cc: IETF JMAP Mailing List To: Neil Jenkins References: <1518070284.168650.1263633200.05C7397A@webmail.messagingengine.com> <1518408506.1699741.1267466096.17DCF605@webmail.messagingengine.com> <1518419708.1006757.1267595536.799BEEC0@webmail.messagingengine.com> <1518420407.1012131.1267607120.3E7422B3@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Jmap] New JSON message representation 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, 01 Mar 2018 20:52:50 -0000 --Apple-Mail=_5575CA6E-41E5-4E61-ADEF-AF1AE99ACB69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This proposal looks really great to me! A few minor comments: > A EmailBodyPart object has the following properties: > [=E2=80=A6] > width: Number|null The width (in px) of the image, if the type is an = image and the server is able to determine this information for the = image. This MAY not be supported for all or any image types on some = servers. > height: Number|null The height (in px) of the image, if the type is an = image and the server is able to determine this information for the = image. This MAY not be supported for all or any image types on some = servers. How strongly do you feel about the need for these properties? Is the = primary intention for clients to have a more accurately-sized = placeholder until the image can be downloaded? There are some edge cases that can affect a client=E2=80=99s mapping of = image pixels to points, e.g. EXIF image orientation, DPI, and screen = resolution scale factor (in the case of screenshot images). In my = opinion, these special image properties add relatively small benefit and = aren=E2=80=99t bulletproof, but add a bit of clutter, so I personally = lean towards these not being a part of the core spec (they could always = be an extension or private extension). Thoughts? > The following Email properties are specified for access to the body = data of the message: > [=E2=80=A6] > textBody: EmailBodyPart[] (immutable) A list of text/plain, text/html = and image/* parts to display (sequentially) as the message body, with a = preference for text/plain when alternative versions are available. >=20 > htmlBody: EmailBodyPart[] (immutable) A list of text/plain, text/html = and image/* parts to display (sequentially) as the message body, with a = preference for text/html when alternative versions are available. >=20 Is the restriction to image/* non-text parts necessary? For instance, a = user could e-mail a video/* part with Content-Disposition: inline, and I = think it would be nice to include that in these array body properties. One option is to re-define this to:=20 =E2=80=9CA list of text/plain, text/html, and attachment parts with the = 'Content-Disposition: inline' header to display (sequentially) as the = message body, with a preference for text/___ when alternative versions = are available=E2=80=9D.=20 That seems more flexible in terms of including media parts, but it might = be too strict if there are cases where an image/* part is included = without a Content-Disposition header (or are C-D: attachment), but the = server wants the MUA to display them inline anyways. I know that the = Apple clients do that. If that case is common amongst other MUA's, could = we just go even looser and say:=20 "A list of parts to display (sequentially) as the message body, with a = preference for text/____ when alternative text versions are = available.=E2=80=9D=20 That leaves things pretty open-ended, though we do need to specify the = recommendations for the mapping now.= --Apple-Mail=_5575CA6E-41E5-4E61-ADEF-AF1AE99ACB69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = proposal looks really great to me!  A few minor comments:

A EmailBodyPart object has the = following properties:
[=E2=80=A6]
  • width: Number|null The = width (in px) of the image, if the type is an image and the server is = able to determine this information for the image. This MAY not be = supported for all or any image types on some servers.
  • height: Number|null The height (in px) of the image, if = the type is an image and the server is able to determine this = information for the image. This MAY not be supported for all or any = image types on some servers.
How strongly do you feel about the need for these properties? = Is the primary intention for clients to have a more accurately-sized = placeholder until the image can be downloaded?

There are some edge cases that can = affect a client=E2=80=99s mapping of image pixels to points, e.g. EXIF = image orientation, DPI, and screen resolution scale factor (in the case = of screenshot images). In my opinion, these special image properties add = relatively small benefit and aren=E2=80=99t bulletproof, but add a bit = of clutter, so I personally lean towards these not being a part of the = core spec (they could always be an extension or private extension). = Thoughts?

The following Email properties are specified for access to the = body data of the message:
[=E2=80=A6]

  • textBody: EmailBodyPart[] (immutable) A list of text/plain, text/html and image/* parts to display (sequentially) as the = message body, with a preference for text/plain when alternative versions are = available.

  • htmlBody: EmailBodyPart[] (immutable) A list of text/plain, text/html and image/* parts to display (sequentially) as the = message body, with a preference for text/html when alternative versions are = available.

Is the restriction to image/* = non-text parts necessary? For instance, a user could e-mail a video/* = part with Content-Disposition: inline, and I think it would be nice to = include that in these array body properties.

One option is to re-define this = to: 
=E2=80=9CA list of text/plain, text/html, and attachment = parts with the 'Content-Disposition: inline' header to display = (sequentially) as the message body, with a preference for text/___ when = alternative versions are = available=E2=80=9D. 

That seems more flexible in = terms of including media parts, but it might be too strict if there are = cases where an image/* part is included without a Content-Disposition = header (or are C-D: attachment), but the server wants the MUA to display = them inline anyways. I know that the Apple clients do that. If that case = is common amongst other MUA's, could we just go even looser and = say: 
"A = list of parts to display (sequentially) as the message body, with a = preference for text/____ when alternative text versions are = available.=E2=80=9D 

That leaves things pretty = open-ended, though we do need to specify the recommendations for the = mapping now.= --Apple-Mail=_5575CA6E-41E5-4E61-ADEF-AF1AE99ACB69-- From nobody Thu Mar 1 18:40:45 2018 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 ABFEF120724 for ; Thu, 1 Mar 2018 18:40: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 (2048-bit key) header.d=fastmailteam.com header.b=TDb3fyiN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dIppmGVi 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 kRWApsN1No7z for ; Thu, 1 Mar 2018 18:40:42 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126ED1205F0 for ; Thu, 1 Mar 2018 18:40:42 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 341AF21928; Thu, 1 Mar 2018 21:40:41 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 01 Mar 2018 21:40:41 -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=fm2; bh=GMfJoG xTxlZBJHlNCFbAlSO2bowlwXUwyDR9Jl207x0=; b=TDb3fyiNcC0K6uAlvtL+AY e0eH6kH/4540xAhdiVOXjqjWW9jC7hO8Wlx6OYe6xlqT32BypHTZ29kWcJ/TtBfl 57h2TGZpLiw1H35d8E6zbcUXiCPUDbIbm0SQvRI6eTsjeyYH2UwxOtyp5VCSeuGf vFAb86qQaiVy34peVNQMTp3cCxi9VGYC/k2ZwaPTndJ8HBx6IxudwKEBvBfN9Uyj F2FjvuQtkg0aCdNx3i3Sg3He8j1LYZM0os0Ri76jmg5UWvY79chNYWlDPleuVHTR jq+VVPgX1OPz3Imil1n3+X3gsejVcpA+q71rOMFBLfz4BWoNRp5qF/c9iAGDXfoA == 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=fm2; bh=GMfJoG xTxlZBJHlNCFbAlSO2bowlwXUwyDR9Jl207x0=; b=dIppmGVi7MNfq+X/tNsyTY ysVd4+r/92qB7zsVx0lJ27WbBdOuG8O/q3V2376kGFXMcc//V1jNEnA/cj3PhmD/ tDC0sUiLOd05seQ02/66Gae7wMKta5tYt169lgtOYwDgdPg9JgEtgs6UYmVdShNB RUrfoDc6GfkYH90WiUb4LRWnX+RcYajjjv/bOlcjO1IsHVJJOVVBg+86VkH3Jw0e 21BJpNVvM2Tn03JQRHyCOrYahnYDfOQwLUX76zSsN8ORMrjM+nDhWHkmYe3J2gJX f8R3AVHCXX5oLk6zikyx0QRZAxu2mc/MlErKyF0VeKoyVELwznSXB9xBfOy4muog == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E1712E2479; Thu, 1 Mar 2018 21:40:40 -0500 (EST) Message-Id: <1519958440.2905331.1288624696.238BA420@webmail.messagingengine.com> From: Neil Jenkins To: Neil Jhaveri Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151995844029053310" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4d729ab8 References: <1518070284.168650.1263633200.05C7397A@webmail.messagingengine.com> <1518408506.1699741.1267466096.17DCF605@webmail.messagingengine.com> <1518419708.1006757.1267595536.799BEEC0@webmail.messagingengine.com> <1518420407.1012131.1267607120.3E7422B3@webmail.messagingengine.com> Date: Fri, 02 Mar 2018 13:40:40 +1100 In-Reply-To: Archived-At: Subject: Re: [Jmap] New JSON message representation 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, 02 Mar 2018 02:40:44 -0000 This is a multi-part message in MIME format. --_----------=_151995844029053310 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Fri, 2 Mar 2018, at 7:52 AM, Neil Jhaveri wrote: > There are some edge cases that can affect a client=E2=80=99s mapping of i= mage > pixels to points, e.g. EXIF image orientation, DPI, and screen > resolution scale factor (in the case of screenshot images). In my > opinion, these special image properties add relatively small benefit > and aren=E2=80=99t bulletproof, but add a bit of clutter, so I personally= lean > towards these not being a part of the core spec (they could always be > an extension or private extension). Thoughts? Yeh, reasonable. They require a lot of additional functionality on the server and I'd already marked them as optional. I'll remove them from the core spec. > Is the restriction to image/* non-text parts necessary? For instance, > a user could e-mail a video/* part with Content-Disposition: inline, > and I think it would be nice to include that in these array body > properties. Hmm. This is a bit tricky. Apple Mail is the only common client I know that generates anything like this, and it will do it with any file type (e.g. a zip file in the middle of your text). My testing seems to show that most clients treat that as an attachment (and show it at the end or wherever they normally show attachments) unless it's an image, which they show inline. Now, I haven't actually tested video so maybe clients also show those inline? Anybody know? I don't think this should be changed to allow any types in the textBody/htmlBody list, but maybe allowing video/* as well as image/* would be OK. Anyone else got an opinion on this? Neil. --_----------=_151995844029053310 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Fri, 2 Mar 2018, at 7:52 AM, Neil Jhaveri wrote:
There are some edge cases that can affect a = client=E2=80=99s mapping of image pixels to points, e.g. EXIF image orienta= tion, DPI, and screen resolution scale factor (in the case of screenshot im= ages). In my opinion, these special image properties add relatively small b= enefit and aren=E2=80=99t bulletproof, but add a bit of clutter, so I perso= nally lean towards these not being a part of the core spec (they could alwa= ys be an extension or private extension). Thoughts?

Yeh, reasonable. They require a lot of additional functionality on the= server and I'd already marked them as optional. I'll remove them from the = core spec.

Is the restriction to image/* non-text = parts necessary? For instance, a user could e-mail a video/* part with Cont= ent-Disposition: inline, and I think it would be nice to include that in th= ese array body properties.

Hmm. This is a bit tricky. Apple Mail is the only common client I know= that generates anything like this, and it will do it with any file type (e= .g. a zip file in the middle of your text). My testing seems to show that m= ost clients treat that as an attachment (and show it at the end or wherever= they normally show attachments) unless it's an image, which they show inli= ne. Now, I haven't actually tested video so maybe clients also show those i= nline? Anybody know?

I don't think this should be changed to allow any types in the textBod= y/htmlBody list, but maybe allowing video/* as well as image/* would be OK.= Anyone else got an opinion on this?

Neil.
--_----------=_151995844029053310-- From nobody Thu Mar 1 18:47:21 2018 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 7364A120724 for ; Thu, 1 Mar 2018 18:47:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=k8fr+9ir; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mhkJNhmm 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 r4Mrz1cbC0Cs for ; Thu, 1 Mar 2018 18:47:18 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299B51205F0 for ; Thu, 1 Mar 2018 18:47:18 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 9311F21BBA for ; Thu, 1 Mar 2018 21:47:17 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 01 Mar 2018 21:47:17 -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=fm2; bh=gw1ro7kQXFfRc+oeK ODAp4uLKma0pshTqi7wAQGB0BQ=; b=k8fr+9irOBZrVTDg2/dlCc9mxhQRgkvyX 5xgfsl8f7uj8j8v4H4gJhyI2ceoi7vEnlEbP/rhIBJPieAIFfd3BKCVKiErOjled sC3cedlsFe7sEPvXvHDL5ojQ1/J0iL/msYcbZ72uFa5r2QpTgTEfAORcFkAdRNv1 l5kziJX/qsHGs1nkL0/mHjK+YoFQrMiAKkJoZVxboZq7HnHE40/SA0XAPdKRcMOT /Fi5Fz5TfTBt9oansImIAYH1xaBJTQHyr5RV2f+jnmgoaDMPKrDj7rECxGi/oIHB WXT9sqRTnGR75j28qdC+mPakXh4tATfkxIr0v4lyiz/V1UFQUj4fg== 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=fm2; bh=gw1ro7 kQXFfRc+oeKODAp4uLKma0pshTqi7wAQGB0BQ=; b=mhkJNhmmW2MCuf7ak1napz feSLpA5KSXQSFNfwmdB5O3TNcSu4y12u5s4+VpI2WqSLzzvfef70C0RYMtxw/JQ1 P6J9XcuCOUI4cfBJ1YTSnUmQAAvDFLDDNki7M9UR9417QIiXOFVVT/2MjSHyOfuh rJ8n2OV7bJ1SvfhFP/Da7HRDrJXDoX7si8sctihjOl47pneGEpmkHTtijE/TOhd8 OloVE3GinqWxot/GH7Q31V3mrfKSgDEF1/DbHZJ2h4sG4N6AMgGGdoY9H4WEiXX1 i6qaYrlX0gb7QtbY1fpBRZIgjQHG8HDNtn3zqK7swFj1R05Z4yvAPTUv52Ru7zyQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5FCA3E2479; Thu, 1 Mar 2018 21:47:17 -0500 (EST) Message-Id: <1519958837.2920887.1288630488.7B45C42B@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151995883729208870" X-Mailer: MessagingEngine.com Webmail Interface - ajax-4d729ab8 References: Date: Fri, 02 Mar 2018 13:47:17 +1100 In-Reply-To: Archived-At: Subject: Re: [Jmap] Handling of unknown properties in /get properties section 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, 02 Mar 2018 02:47:19 -0000 This is a multi-part message in MIME format. --_----------=_151995883729208870 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Fri, 2 Mar 2018, at 2:14 AM, Matthew Horsfall (alh) wrote: > To me this seems to say that:=E2=80=A6 > "properties": [ "name", "oops" ], > =E2=80=A6should return invalidArguments because "oops" is unknown. There are two options I think: you either silently ignore or reject with invalidArguments error as you say. Given you have to opt-in to any extensions you are using, the client should always know what properties it can fetch, so I think the error seems the better option as it will help developers not waste hours on bugs caused by small typos. Unless anyone disagrees, I'll clarify this in the spec. Neil. --_----------=_151995883729208870 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Fri, 2 Mar 2018, at 2:14 AM, Matthew Horsfall (alh) wrote:
To me this seems to say that:=E2=80=A6
    "properties": [ "name", "oops" ],
=E2=80=A6should return invalidArguments because "oops" is unknown.
=

There are two options I think: you either silently ignore or reject wi= th invalidArguments error as you say. Given you have to opt-in to any exten= sions you are using, the client should always know what properties it can f= etch, so I think the error seems the better option as it will help develope= rs not waste hours on bugs caused by small typos.

Unless anyone disagrees, I'll clarify this in the spec.

Neil.
--_----------=_151995883729208870-- From nobody Thu Mar 1 20:10:45 2018 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 E70941241F5 for ; Thu, 1 Mar 2018 20:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.207 X-Spam-Level: X-Spam-Status: No, score=-1.207 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, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=staff.atmail.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 let_aSdnqpSG for ; Thu, 1 Mar 2018 20:10:43 -0800 (PST) Received: from staff.atmail.com (unknown [204.145.97.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04218120724 for ; Thu, 1 Mar 2018 20:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=staff.atmail.com; s=20160330; h=Content-Type:MIME-Version:Date:Message-ID: From:To:Subject; bh=PEGYCVciW2QTf6gASeufoQ9w8bxLmX7t7ybEVIVDPwE=; b=W7YNq6EI+ RlHCiWUwaJ8Cxlci+1XMYpCqy31TiqsPaYkuBF696bUK5ayvTa2Bm3PBIuD8ZHBrptyf8zQHvHQa5 7gJ3Ia0dzmw61Xzpz2EZZcQvoE9aDdBgN4PYtsgKULGg5bA6ZWdjIvZDk3cDhvMCRxJiG2Vj3sVgn VLZGXgxc=; Received: from 35.124.233.220.static.exetel.com.au ([220.233.124.35] helo=[172.16.254.117]) by us11-001dm.dh.atmailcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1erc1t-00023B-3d for jmap@ietf.org; Fri, 02 Mar 2018 14:10:45 +1000 To: jmap@ietf.org References: <1519958837.2920887.1288630488.7B45C42B@webmail.messagingengine.com> From: Brad Kowalczyk Message-ID: Date: Fri, 2 Mar 2018 15:10:35 +1100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1519958837.2920887.1288630488.7B45C42B@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------636A9D003019B434409BC41F" Content-Language: en-US X-Atmail-Id: brad.kowalczyk@staff.atmail.com X-atmail-spam-score: 0 X-atmail-spam-bar: / Archived-At: Subject: Re: [Jmap] Handling of unknown properties in /get properties section 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, 02 Mar 2018 04:10:44 -0000 This is a multi-part message in MIME format. --------------636A9D003019B434409BC41F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 02/03/18 13:47, Neil Jenkins wrote: > On Fri, 2 Mar 2018, at 2:14 AM, Matthew Horsfall (alh) wrote: >> To me this seems to say that:… >>     "properties": [ "name", "oops" ], >> …should return invalidArguments because "oops" is unknown. > > There are two options I think: you either silently ignore or reject > with invalidArguments error as you say. Given you have to opt-in to > any extensions you are using, the client should always know what > properties it can fetch, so I think the error seems the better option > as it will help developers not waste hours on bugs caused by small typos. > > Unless anyone disagrees, I'll clarify this in the spec > > Neil. > I also prefer the invalidArguments error. This is how we currently have it implemented in our JMAP server and it's already helped us to immediately find those pesky typos when writing client code, preventing what could have become a more time wasting issue. Brad -- --------------636A9D003019B434409BC41F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 02/03/18 13:47, Neil Jenkins wrote:

On Fri, 2 Mar 2018, at 2:14 AM, Matthew Horsfall (alh) wrote:
To me this seems to say that:…
    "properties": [ "name", "oops" ],
…should return invalidArguments because "oops" is unknown.

There are two options I think: you either silently ignore or reject with invalidArguments error as you say. Given you have to opt-in to any extensions you are using, the client should always know what properties it can fetch, so I think the error seems the better option as it will help developers not waste hours on bugs caused by small typos.

Unless anyone disagrees, I'll clarify this in the spec

Neil.


I also prefer the invalidArguments error. This is how we currently have it implemented in our JMAP server and it's already helped us to immediately find those pesky typos when writing client code, preventing what could have become a more time wasting issue.

Brad

--



--------------636A9D003019B434409BC41F-- From nobody Fri Mar 2 00:52:49 2018 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 8BD6812D7F3 for ; Fri, 2 Mar 2018 00:52:42 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E7 hex): Cc: Fran\347ois COLOMBIER <[...] X-Spam-Flag: NO X-Spam-Score: 0.912 X-Spam-Level: X-Spam-Status: No, score=0.912 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, FORGED_MUA_EUDORA=0.001, HTML_MESSAGE=0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=rdlab.org 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 WcNOV2F-aUyi for ; Fri, 2 Mar 2018 00:52:41 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A431127201 for ; Fri, 2 Mar 2018 00:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rdlab.org; s=default; h=Content-Type:Mime-Version:References:In-Reply-To:Cc:Subject: From:To:Date:Sender:Reply-To:Message-ID:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=pbX1p6fkOBz3T6P+KtgabDNIkUpDB22jXyh3ZpHXwwQ=; b=ea8YM2pXyLVRsYZMY6Sl6K7ALO t9DFoe/gMxHEoHS8XXtCQwqmqQEmz5fvSsyernc/N2j2w0rZP85m5sOyxWBc+MWCddtcf/JcuRqVX CqFze22SUYDqRpYItBjto+6uhdNgf6uCLssgGNxYrFzh4l8h0QIBFwDg9x4eSlU/UHn57A3m0ydbz 0f9ZcA09XE9PqlrfZuhZnaiFyYLnvDzevx1ph8A8OcIfCrgq+VVaAob8gOwXJHQ4OKMdqEEaUmbHp 3ltsM0g2uJE3wZ/VCVxN95b80xFwCZjBytpnHXBpLKYf4eaUisaq10mtxfoAIbTe+iYUrvthAyG6Z PjF2J38w==; Received: from gra86-h02-176-142-255-40.dsl.sta.abo.bbox.fr ([176.142.255.40]:59457 helo=Morfin-Morfin.rdlab.org) by host.presenceweb.org with esmtpa (Exim 4.89_1) (envelope-from ) id 1ergQh-00022w-T9; Fri, 02 Mar 2018 09:52:40 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Mar 2018 09:52:33 +0100 To: jmap@ietf.org From: JFCM Cc: François COLOMBIER In-Reply-To: References: <1519958837.2920887.1288630488.7B45C42B@webmail.messagingengine.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1302815954==.ALT" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - rdlab.org X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: info+rdlab.org/only user confirmed/virtual account not confirmed X-Authenticated-Sender: host.presenceweb.org: info@rdlab.org X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20180302085241.8A431127201@ietfa.amsl.com> Archived-At: Subject: Re: [Jmap] Handling of unknown properties in /get properties section 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, 02 Mar 2018 08:52:48 -0000 --=====================_1302815954==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed On 05:10 02/03/2018, Brad Kowalczyk said: >This is how we currently have it implemented in our JMAP server and >it's already helped us to immediately find those pesky typos when >writing client code, preventing what could have become a more time >wasting issue. We use e-mail as an intra-distributed-application vehicle. I think JMAP would bring me a lot of new possibilities and hence standardisation needs. Therefore we look for running code we could use for experimentation. Are there JMAP server open codes available we could use ? jfcm --=====================_1302815954==.ALT Content-Type: text/html; charset="us-ascii" On 05:10 02/03/2018, Brad Kowalczyk said:
This is how we currently have it implemented in our JMAP server and it's already helped us to immediately find those pesky typos when writing client code, preventing what could have become a more time wasting issue.

We use e-mail as an intra-distributed-application vehicle. I think JMAP would bring me a lot of new possibilities and hence standardisation needs. Therefore we look for running code we could use for experimentation. Are there JMAP server open codes available we could use ?

jfcm --=====================_1302815954==.ALT-- From nobody Sun Mar 4 21:40:55 2018 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 834631205F0; Sun, 4 Mar 2018 21:40:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152022844749.27956.12150932438674632065@ietfa.amsl.com> Date: Sun, 04 Mar 2018 21:40:47 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-core-04.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: Mon, 05 Mar 2018 05:40:48 -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-04.txt Pages : 47 Date : 2018-03-04 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-core-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-core-04 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 Sun Mar 4 21:41:26 2018 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 A158A126E64; Sun, 4 Mar 2018 21:41:13 -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.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152022847361.27878.10535793061539253828@ietfa.amsl.com> Date: Sun, 04 Mar 2018 21:41:13 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mail-04.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: Mon, 05 Mar 2018 05:41:19 -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-04.txt Pages : 55 Date : 2018-03-04 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mail-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mail-04 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 marc@laporte.name Mon Mar 5 07:18:16 2018 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 6D8B612DA12 for ; Mon, 5 Mar 2018 07:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=laporte-name.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 pMLtHlEK_V3o for ; Mon, 5 Mar 2018 07:18:14 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 1D37812D88A for ; Mon, 5 Mar 2018 07:18:13 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id y6so20688514qtm.7 for ; Mon, 05 Mar 2018 07:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=laporte-name.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=yIhxgQnYsfWyyFltQxgFKXji4u/a2YrViPBn45yiiWU=; b=l3qYNHEqchsliqtURa2TqlB0wytFhKciywhRmKeVIHLTPOz8+vITpr6pPZ4qPQOam4 bh4pBYp883R2Awikul9Fn4S7OM1KogcIPr5XMqj6vHnRRyukUDCrEZX1hsNvBeR1OCxl HC5re3MZpNQmZMqdXzHubYkjeI6FmdARr6zwG3EXcWl63sasgcxFspcxDy/6lusTXR9o pXT48JhPQprxeAIndriVioQ5kU/dYxGkf/151X+BVj2B0DhJGccrIVTP4ThuGJ/u5aG1 MEqyF/uh72iWrUwbmHKLaP9kVSrxVgV0RjlvOBD2G2NgUBoz1DET8/dqr5GaTVK5FNOx 0Lyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc; bh=yIhxgQnYsfWyyFltQxgFKXji4u/a2YrViPBn45yiiWU=; b=bdgSE8gDEavqh4zTWOozkGRv/xglfgjqBduYWgIw0Bwh4hHLV9BjMmejWbVhyCSCV+ cPbwoG0MXmzlNP/TCIJP+rAcBl0HvwExB6MA78icqhv0yRYV/Fg1+xMm2xZJHUc/REsU NCybwxfQ72TbWa1NcNntSQPFyc+8D4jzSbxGk6KwWdtzo91HL/ziTyaBjum3XY8EzDJw 259pSipJaDMVF4zzHmZqIMR/lmc/nBT0/uljB5yRpa7dXYOITV0wHO+oNKq17tD6tJ1k 07+3O+OBxNollM76w19lVQxRSzpJDzcSkD3SEFNirqOWDWgkoaNpprpLYmkIhtRJgAdq ikow== X-Gm-Message-State: AElRT7Hl9BvuKLd5jX69dA83NBVeyfx8epdGIUmsCnyZMbf0m2RTgcMF viRM7hqRDLwv7FTsa2vm7mky8dpb0kQDhlS4PYugYeu+ X-Google-Smtp-Source: AG47ELt0xtZNhjWxnZS9gnEPv25uKLyesAFK4qgSkWgfWOVkRPfYFebXZWCZaVYNJV8g8GnF+Un6IIpSBkm+x449l0k= X-Received: by 10.200.82.6 with SMTP id r6mr23220077qtn.31.1520263093059; Mon, 05 Mar 2018 07:18:13 -0800 (PST) MIME-Version: 1.0 Sender: marc@laporte.name Received: by 10.12.134.2 with HTTP; Mon, 5 Mar 2018 07:18:11 -0800 (PST) From: Marc Laporte Date: Mon, 5 Mar 2018 10:18:11 -0500 X-Google-Sender-Auth: IfGv3_4DtkrhA6CI6SQP2SiYXiA Message-ID: To: Bron Gondwana Cc: jmap@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Jmap] Core team members from WikiSuite and Tiki Wiki CMS Groupware will be present! was: Re: JMAP added to Hackathon wiki page 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, 05 Mar 2018 15:19:24 -0000 Dear Bron and all, We'll be 4 or 5 devs with you: http://wikisuite.org/2018-XMPP-WebRTC-and-JMAP-Hackathons-in-London We are also doing an XMPP event a few days before in case anyone is interested. We have updated our dev branch to Cyrus to 3.1.4, to get latest JMAP: https://github.com/WikiSuite/cyrus-imapd/commits/master We plan to have our dev server using this version http://wikisuite.org/ClearOS-and-Cyrus-IMAP-3-testing It would be really nice to have someone from Apache James / OpenPaaS Will https://github.com/jmapio/jmap-demo-webmail be updated as well? Thanks and best regards, M ;-) -- Marc Laporte http://WikiSuite.org http://Tiki.org http://PluginProblems.com http://Avan.Tech On Wed, Jan 31, 2018 at 4:53 PM, Bron Gondwana wrote: > Hi All, > > I've added JMAP to the IETF Hackathon page: > > https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon > > JMAP > > Champion(s) > > Bron Gondwana > Neil Jenkins > > Project(s) > > Interoperability testing > Check that spec covers client needs > > > It would be great to have other implementations there to test with! We'll > be bringing Cyrus IMAPd, the perl proxy, and Neil's latest frontend code > (both the FastMail interface code, and the open source libraries) > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > From nobody Mon Mar 5 09:12:47 2018 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 DD76412D94F for ; Mon, 5 Mar 2018 09:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, WEIRD_QUOTING=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 R74NDq5e1u_h for ; Mon, 5 Mar 2018 09:12:43 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id C4E3012D86A for ; Mon, 5 Mar 2018 09:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1520269962; d=isode.com; s=june2016; i=@isode.com; bh=/Ow39yfXB5TzRUVEFit2bJlLB/c8DbWxrHQo2ZbP25A=; 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=C3hqamUepG6Rfn6xZVUKl+VVR5sOejQKYykHZHandxv9ETfeOro86+CmYLYDK0Do1cJOLe bCJcsUWqVkcqVSwN+GVbjxXhybsF1NrwjqOovtMR2HH3/N0PDmrd8GC9K1YvlJk56LkEa+ n3P2GMva3Ph94h4Jvk3WkHNoH/TabdQ=; 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 ; Mon, 5 Mar 2018 17:12:42 +0000 To: "jmap@ietf.org" From: Alexey Melnikov Message-ID: <74eab43a-6bed-ea06-14d6-a43a37503d87@isode.com> Date: Mon, 5 Mar 2018 17:12:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------B5220B8BE657A1E1D1FCAC92" Content-Language: en-GB Archived-At: Subject: [Jmap] Early draft on S/MIME signature verification to 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, 05 Mar 2018 17:12:46 -0000 This is a multi-part message in MIME format. --------------B5220B8BE657A1E1D1FCAC92 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I wrote a very early draft on how a JMAP server can return S/MIME signature verification status to a JMAP client. I would like to submit it as a working group document as a concrete proposal to start to a proper discussion. Comments are welcome! Best Regards, Alexey --------------B5220B8BE657A1E1D1FCAC92 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-jmap-smime-00.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-jmap-smime-00.txt" CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBLiBNZWxuaWtvdgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJc29kZSBMdGQKSW50ZW5kZWQgc3Rh dHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCA1 LCAyMDE4CkV4cGlyZXM6IFNlcHRlbWJlciA2LCAyMDE4CgoKICAgICAgICAgIEV4dGVuc2lv bnMgdG8gSk1BUCBmb3IgUy9NSU1FIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24KICAgICAgICAg ICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1qbWFwLXNtaW1lLTAwCgpBYnN0cmFjdAoKICAg VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgZXh0ZW5zaW9uIHRvIEpNQVAgZm9yIHJldHVybmlu ZyBTL01JTUUKICAgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBzdGF0dXMuCgpTdGF0dXMgb2Yg VGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxs IGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1Ag NzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJ bnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBh cyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBE cmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVu dC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3Ig YSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNl ZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0 IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UK ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJv Z3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBTZXB0ZW1i ZXIgNiwgMjAxOC4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxOCBJ RVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVu dCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlz aW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cHM6Ly90cnVzdGVlLmll dGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1Ymxp Y2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50 cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3Ry aWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9u ZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1w bGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9m CiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91 dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vu c2UuCgoKCgoKCk1lbG5pa292ICAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDYs IDIwMTggICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg IEpNQVAgZXh0ZW5zaW9uIGZvciBTL01JTUUgICAgICAgICAgICAgTWFyY2ggMjAxOAoKClRh YmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIENvbnZlbnRpb25z IFVzZWQgaW4gVGhpcyBEb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAy CiAgIDMuICBFeHRlbnNpb24gdG8gZ2V0TWVzc2FnZXMgZm9yIFMvTUlNRSBzaWduYXR1cmUg dmVyaWZpY2F0aW9uICAuICAgMgogICA0LiAgT3BlbiBJc3N1ZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgNS4gIElBTkEgQ29u c2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA0CiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICA3LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAgQXV0aG9yJ3Mg QWRkcmVzcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA0CgoxLiAgSW50cm9kdWN0aW9uCgogICBKTUFQIFtJLUQuaWV0Zi1qbWFwLWNvcmVd IGlzIGEgZ2VuZXJpYyBwcm90b2NvbCBmb3Igc3luY2hyb25pc2luZwogICBkYXRhLCBzdWNo IGFzIG1haWwsIGNhbGVuZGFycyBvciBjb250YWN0cywgYmV0d2VlbiBhIGNsaWVudCBhbmQg YQogICBzZXJ2ZXIuICBJdCBpcyBvcHRpbWlzZWQgZm9yIG1vYmlsZSBhbmQgd2ViIGVudmly b25tZW50cywgYW5kIGFpbXMgdG8KICAgcHJvdmlkZSBhIGNvbnNpc3RlbnQgaW50ZXJmYWNl IHRvIGRpZmZlcmVudCBkYXRhIHR5cGVzLgogICBbSS1ELmlldGYtam1hcC1tYWlsXSBidWls ZHMgb24gdG9wIG9mIEpNQVAgYW5kIGRlZmluZXMgaG93IHRvIHBlcmZvcm0KICAgZW1haWwg c3luY2hyb25pemF0aW9uLgoKICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gZXh0ZW5z aW9uIHRvIEpNQVAgTWFpbCBmb3IgcmV0dXJuaW5nCiAgIFMvTUlNRSBbUkZDNTc1MV0gc2ln bmF0dXJlIHZlcmlmaWNhdGlvbiBzdGF0dXMsIHdpdGhvdXQgcmVxdWlyaW5nIGEKICAgSk1B UCBjbGllbnQgdG8gZG93bmxvYWQgdGhlIHNpZ25hdHVyZSBhbmQgYWxsIHNpZ25lZCBib2R5 IHBhcnRzLgoKMi4gIENvbnZlbnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudAoKICAgVGhl IGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJT SEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50 ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4KCjMuICBFeHRlbnNpb24gdG8g Z2V0TWVzc2FnZXMgZm9yIFMvTUlNRSBzaWduYXR1cmUgdmVyaWZpY2F0aW9uCgogICBbSS1E LmlldGYtam1hcC1tYWlsXSBkZWZpbmVzIGdldE1lc3NhZ2VzIG1ldGhvZCBmb3IgcmV0cmll dmluZwogICBtZXNzYWdlIHNwZWNpZmljIGluZm9ybWF0aW9uLiAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIHRoZSBmb2xsb3dpbmcKICAgcHNldWRvIHZhbHVlcyBpbiB0aGUgX3Byb3BlcnRp ZXNfIGFyZ3VtZW50OgogICBvICpzbWltZVN0YXR1cyo6IElmICIic21pbWVTdGF0dXMiIiBp cyBpbmNsdWRlZCBpbiB0aGUgbGlzdCBvZgogICByZXF1ZXN0ZWQgcHJvcGVydGllcywgaXQg TVVTVCBiZSBpbnRlcnByZXRlZCBieSB0aGUgc2VydmVyIGFzIGEKICAgcmVxdWVzdCB0byBy ZXR1cm4gIiJzbWltZVN0YXR1cyIiIHByb3BlcnR5LgoKICAgKnNtaW1lU3RhdHVzKjogIlN0 cmluZ3xudWxsIi4gbnVsbCBzaWduaWZpZXMgdGhhdCB0aGUgbWVzc2FnZSBkb2Vzbid0CiAg IGNvbnRhaW4gYW55IHNpZ25hdHVyZS4gIFBvc3NpYmxlIHN0cmluZyB2YWx1ZXMgb2YgdGhl IHByb3BlcnR5IGFyZQogICBsaXN0ZWQgYmVsb3cuICBTZXJ2ZXJzIE1BWSByZXR1cm4gb3Ro ZXIgdmFsdWVzIG5vdCBkZWZpbmVkIGJlbG93LgogICBDbGllbnQgTVVTVCB0cmVhdCB1bnJl Y29nbml6ZWQgdmFsdWVzIGFzICJ1bmtub3duIjoKCiAgICAgIHVua25vd24gLSBTL01JTUUg bWVzc2FnZSwgYnV0IGl0IGlzIG5laXRoZXIgc2lnbmVkLCBub3IgZW5jcnlwdGVkLgogICAg ICBUaGlzIGNhbiBhbHNvIGJlIHJldHVybmVkIGZvciBhIG11bHRpcGFydC9zaWduZWQgbWVz c2FnZSB3aGljaAogICAgICBjb250YWlucyB1bnJlY29nbml6ZWQgc2lnbmluZyBwcm90b2Nv bCAoZm9yIGV4YW1wbGUgT3BlblBHUCkuCgoKCgpNZWxuaWtvdiAgICAgICAgICAgICAgICBF eHBpcmVzIFNlcHRlbWJlciA2LCAyMDE4ICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRl cm5ldC1EcmFmdCAgICAgICAgICBKTUFQIGV4dGVuc2lvbiBmb3IgUy9NSU1FICAgICAgICAg ICAgIE1hcmNoIDIwMTgKCgogICAgICBzaWduZWQgLSBTL01JTUUgc2lnbmVkIG1lc3NhZ2Us IGJ1dCB0aGUgc2lnbmF0dXJlIHdhcyBub3QgeWV0CiAgICAgIHZlcmlmaWVkLiAgU29tZSBz ZXJ2ZXJzIG1pZ2h0IG5vdCBhdHRlbXB0IHRvIHZlcmlmeSBzaWduYXR1cmUKICAgICAgdW50 aWwgYSBwYXJ0aWN1bGFyIG1lc3NhZ2UgaXMgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQuCgog ICAgICBzaWduZWQvdmVyaWZpZWQgLSBTL01JTUUgc2lnbmVkIG1lc3NhZ2UgYW5kIHRoZSBz ZW5kZXIncyBzaWduYXR1cmUKICAgICAgd2FzIHN1Y2Nlc3NmdWxseSB2ZXJpZmllZCwgc2Vu ZGVyIG1hdGNoZXMgdGhlIEZyb20gaGVhZGVyIGZpZWxkCiAgICAgIGFuZCB0aGUgc2VuZGVy J3MgY2VydGlmaWNhdGUgKGFuZCB0aGUgY2VydGlmaWNhdGUgY2hhaW4pIGlzCiAgICAgIHRy dXN0ZWQgZm9yIHNpZ25pbmcuCgogICAgICBzaWduZWQvZmFpbGVkIC0gUy9NSU1FIHNpZ25l ZCBtZXNzYWdlLCBidXQgdGhlIHNpZ25hdHVyZSBmYWlsZWQgdG8KICAgICAgdmVyaWZ5LiAg VGhpcyBtaWdodCBiZSBhIHBvbGljeSByZWxhdGVkIGRlY2lzaW9uIChtZXNzYWdlIHNpZ25l cgogICAgICBkb2Vzbid0IG1hdGNoIHRoZSBGcm9tIGhlYWRlciBmaWVsZCksIG1lc3NhZ2Ug d2FzIG1vZGlmaWVkLCBldGMuCgogICBUaGUgZm9sbG93aW5nIGV4YW1wbGUgZGVtb25zdHJh dGVzIGEgcmVxdWVzdCBmb3IgUy9NSU1FIHN0YXR1cy4KCgogICAgICBbImdldE1lc3NhZ2Vz IiwgewogICAgICAiaWRzIjogWyAiZjEyM3U5ODciIF0sCiAgICAgICJwcm9wZXJ0aWVzIjog WyAibWFpbGJveElkcyIsICJmcm9tIiwgInN1YmplY3QiLCAiZGF0ZSIsICJzbWltZVN0YXR1 cyIgXQogICAgICB9LCAiIzEiXQoKVGhpcyB3aWxsIHJlc3VsdCBpbiB0aGUgZm9sbG93aW5n IHJlc3BvbnNlOgoKICAgICAgWyJtZXNzYWdlcyIsIHsKICAgICAgICAgImFjY291bnRJZCI6 ICJhYmMiLAogICAgICAgICAic3RhdGUiOiAiNDEyMzQxMjMyMzEiLAogICAgICAgICAibGlz dCI6IFsKICAgICAgICAgICB7CiAgICAgICAgICAgICBpZDogImYxMjN1NDU3IiwKICAgICAg ICAgICAgIG1haWxib3hJZHM6IHsgImYxMjMiOiB0cnVlIH0sCiAgICAgICAgICAgICBmcm9t OiBbe25hbWU6ICJKb2UgQmxvZ2dzIiwgZW1haWw6ICJqb2VAYmxvZ2dzLmNvbSJ9XSwKICAg ICAgICAgICAgIHN1YmplY3Q6ICJEaW5uZXIgb24gVGh1cnNkYXk/IiwKICAgICAgICAgICAg IGRhdGU6ICIyMDEzLTEwLTEzVDE0OjEyOjAwWiIsCiAgICAgICAgICAgICBzbWltZVN0YXR1 czogInNpZ25lZC92ZXJpZmllZCIKICAgICAgICAgICB9CiAgICAgICAgIF0KICAgICAgfSwg IiMxIl0KCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFeGFtcGxlCgo0LiAg T3BlbiBJc3N1ZXMKCiAgIFtbVGhpcyBzZWN0aW9uIHNob3VsZCBiZSBlbXB0eSBiZWZvcmUg cHVibGljYXRpb25dXQoKCgoKCgoKCk1lbG5pa292ICAgICAgICAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDYsIDIwMTggICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURy YWZ0ICAgICAgICAgIEpNQVAgZXh0ZW5zaW9uIGZvciBTL01JTUUgICAgICAgICAgICAgTWFy Y2ggMjAxOAoKCjUuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUQkQuCgo2LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRCRC4KCjcuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoK ICAgW0ktRC5pZXRmLWptYXAtY29yZV0KICAgICAgICAgICAgICBKZW5raW5zLCBOLiwgIkpT T04gTWV0YSBBcHBsaWNhdGlvbiBQcm90b2NvbCIsIGRyYWZ0LWlldGYtCiAgICAgICAgICAg ICAgam1hcC1jb3JlLTA0ICh3b3JrIGluIHByb2dyZXNzKSwgTWFyY2ggMjAxOC4KCiAgIFtJ LUQuaWV0Zi1qbWFwLW1haWxdCiAgICAgICAgICAgICAgSmVua2lucywgTi4sICJKTUFQIGZv ciBNYWlsIiwgZHJhZnQtaWV0Zi1qbWFwLW1haWwtMDQKICAgICAgICAgICAgICAod29yayBp biBwcm9ncmVzcyksIE1hcmNoIDIwMTguCgogICBbUkZDMjA0NV0gIEZyZWVkLCBOLiBhbmQg Ti4gQm9yZW5zdGVpbiwgIk11bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsCiAgICAgICAgICAg ICAgRXh0ZW5zaW9ucyAoTUlNRSkgUGFydCBPbmU6IEZvcm1hdCBvZiBJbnRlcm5ldCBNZXNz YWdlCiAgICAgICAgICAgICAgQm9kaWVzIiwgUkZDIDIwNDUsIERPSSAxMC4xNzQ4Ny9SRkMy MDQ1LCBOb3ZlbWJlciAxOTk2LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRp dG9yLm9yZy9pbmZvL3JmYzIwNDU+LgoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktl eSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1 aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LAogICAgICAgICAgICAgIERPSSAx MC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LAogICAgICAgICAgICAgIDxodHRwczovL3d3 dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoKICAgW1JGQzU3NTFdICBSYW1zZGVs bCwgQi4gYW5kIFMuIFR1cm5lciwgIlNlY3VyZS9NdWx0aXB1cnBvc2UgSW50ZXJuZXQKICAg ICAgICAgICAgICBNYWlsIEV4dGVuc2lvbnMgKFMvTUlNRSkgVmVyc2lvbiAzLjIgTWVzc2Fn ZQogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBSRkMgNTc1MSwgRE9JIDEwLjE3NDg3 L1JGQzU3NTEsIEphbnVhcnkKICAgICAgICAgICAgICAyMDEwLCA8aHR0cHM6Ly93d3cucmZj LWVkaXRvci5vcmcvaW5mby9yZmM1NzUxPi4KCkF1dGhvcidzIEFkZHJlc3MKCiAgIEFsZXhl eSBNZWxuaWtvdgogICBJc29kZSBMdGQKICAgMTQgQ2FzdGxlIE1ld3MKICAgSGFtcHRvbiwg TWlkZGxlc2V4ICBUVzEyIDJOUAogICBVSwoKICAgRU1haWw6IEFsZXhleS5NZWxuaWtvdkBp c29kZS5jb20KCgoKCgoKCgoKTWVsbmlrb3YgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0 ZW1iZXIgNiwgMjAxOCAgICAgICAgICAgICAgIFtQYWdlIDRdCg== --------------B5220B8BE657A1E1D1FCAC92-- From nobody Mon Mar 5 11:43:52 2018 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 26E5C12E8E4 for ; Mon, 5 Mar 2018 11:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7Su3oZH9ZJHN for ; Mon, 5 Mar 2018 11:43:46 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 5390612E8E7 for ; Mon, 5 Mar 2018 11:43:41 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id g60so21762050qtd.11 for ; Mon, 05 Mar 2018 11:43:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=13PPXUZ++V3OV8aUJnchSBL8OGVstQJN/H02l1a/caI=; b=i9Jd7hogRU4666VDEwRPkJRqju818DQNAK0uOMpyMCzjU40pS0eTwhierSwwEcXhVU /owaTASxdoCCBTlHEyjYusXHAZfJ1MrEeLdkLq+0ZZMknoLxQP23ZT5fKflZoqaZe+OT pOzznQmizQHhLA00xHlq2aU+PLdjjDY3ko2iUcKu+tr+6fydkeLZyiuCfNy1++4rxdbi MXUEW7QLaQEauIVbOFOh8v5JcKdkflF9MpGXkKunhJsXA8FwozR82i0S5H59fRw0n8Im I2rLvBJuIFo+rmVIcRZGPn4FQCDCXlN32rXICB3ZJQP42GpRc6YzgRJ0xMtEl47YIC1j AD1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=13PPXUZ++V3OV8aUJnchSBL8OGVstQJN/H02l1a/caI=; b=XylPyk5+qXvca4knYjYxxpoPCQfON/VydjSx6bgkAgllVC0imUMnoPC4GG/HjMog+u lKzSIzrD6+WIlXkSrVZWcTgfiYJoFvIs3VehHjy2VmWwkxmo445gk9Q+Tiwx3ACk0Vzj kRY9+4GM0kyoIkCovR2+UBVM1G/CVBpOvOMhmP58IMbFMR5T9lK5uOEndsTGPG6ZmoY8 XXF/BbnV2pogr1JNhgHp2LeHmvtATLeSoMO+kTrImqOF+yYh1eBl32AoymLT/bEK5KmS 4NraCU2T8X3AL+Pyo7+dM7WPa7XoEdf3lVaVLtiwK8Wm6gdqUt4mHuCT8jwkR8OJf4pK uDLg== X-Gm-Message-State: AElRT7EldqBcL0x13fOOCRTOhfNHB2/xVRa2T01QyCvrNYIl6+p+l4mj WWTX7xQe6vi1bPFNSP3yeiT2EDOE65yk/uOtDbk= X-Google-Smtp-Source: AG47ELuZDNoACSI5EQ9JCthOeTx6py4Diw2iYlvjPhFBiGc3kVaFKvIsxSOJwRNLWKcUZi/k1QHuD0xbISwF0YSCGq4= X-Received: by 10.237.46.69 with SMTP id j63mr25069525qtd.257.1520279020438; Mon, 05 Mar 2018 11:43:40 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.54.215 with HTTP; Mon, 5 Mar 2018 11:43:39 -0800 (PST) In-Reply-To: <74eab43a-6bed-ea06-14d6-a43a37503d87@isode.com> References: <74eab43a-6bed-ea06-14d6-a43a37503d87@isode.com> From: Barry Leiba Date: Mon, 5 Mar 2018 14:43:39 -0500 X-Google-Sender-Auth: VBHaoshe7rFhY3hwZ9ecb1fkCcM Message-ID: To: Alexey Melnikov Cc: "jmap@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Jmap] Early draft on S/MIME signature verification to 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, 05 Mar 2018 19:43:51 -0000 Given that this is directly within our charter, work that was discussed in Singapore, and a good first stab at extending the base JMAP, your chairs would like to ask the working group to take Alexey's proposal on as a starting point for a working group document. If there are no objections to that by the Monday of IETF week (19 March), we will approve Alexey's draft for posting. Barry, being chair-like On Mon, Mar 5, 2018 at 12:12 PM, Alexey Melnikov wrote: > Hi, > > I wrote a very early draft on how a JMAP server can return S/MIME signature > verification status to a JMAP client. I would like to submit it as a working > group document as a concrete proposal to start to a proper discussion. > > Comments are welcome! > > > Best Regards, > > Alexey > > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > From nobody Mon Mar 5 15:01:17 2018 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 594DE12EBEA for ; Mon, 5 Mar 2018 15:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=Zr44BFax; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=diSKzg3+ 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 BR19k_OZUeh7 for ; Mon, 5 Mar 2018 15:00:55 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC44912EB4F for ; Mon, 5 Mar 2018 15:00:39 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3005D219B3 for ; Mon, 5 Mar 2018 18:00:39 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 05 Mar 2018 18:00:39 -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=fm2; bh=XBAc8o4mBO6TA61+q MRgsNOZh/MDQuIBuQ5H7hR0Ulg=; b=Zr44BFax/jFB/XbhPbf6if/zl65GLLcax iTZVdlywTYweh05/Ri9aalRQWoEwj9JRDthKgoRiLfmfBcRaxDyfYmMFrc9UM2lZ fUgtENuk4w2IyuZueCznh46BdvPm0aFoQOxs8cWGMSDcPb8graHdZ2SQw2U4ENj/ aO5Y2kGuWjIfqPfY6G8VcGmZkzich2AJB7aHIe1sua0FejGYDf/aM+TLuPpU/q5G rYMBm7+dUlQI+tG+RVVJnAg7t+sKAgIldod1H1gmQbib0CN6c+1kV1CBgPiiqIFG LIToFNXDUOrRyvh8y2CkWba7cwWkyS/4a9uOj6OXhXvyRfO1+V1ig== 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=fm2; bh=XBAc8o 4mBO6TA61+qMRgsNOZh/MDQuIBuQ5H7hR0Ulg=; b=diSKzg3+m8ATguZ9fsNlWW zaJPzrv4xY5uruKUz8yQMgJxaJdGRVhVXSuhNJv9VvWtHRBkvRuhTxqhTYPrWS5D TltGjoR+KBCBt5sMmK6z5KcpyynL/Bg/GBv8tITAAYFpIzFO90Dp10K58o5sgQj/ Nqzdl62ss6avH4yc7/BCmTdJIh7aQijVfSW92ezq6K1OYlJUwEopRaWoTNchTQuE xBxUzS0JdaCfy4fVFaenqpoE0BQBSFDVzwUSWDw7LW2kPl9Swz0kaye1uRkoNLRI HNxnJxzGnkCQ/RW/nSsc00QH1Ig6Ocm8WvWzuwUl8e8vbykMWtcxoxenchisV4Mg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F1A469E1D9; Mon, 5 Mar 2018 18:00:38 -0500 (EST) Message-Id: <1520290838.2193126.1292540872.08935C98@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152029083821931260" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b86e6959 References: <74eab43a-6bed-ea06-14d6-a43a37503d87@isode.com> In-Reply-To: Date: Tue, 06 Mar 2018 10:00:38 +1100 Archived-At: Subject: Re: [Jmap] Early draft on S/MIME signature verification to 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, 05 Mar 2018 23:01:00 -0000 This is a multi-part message in MIME format. --_----------=_152029083821931260 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" This sounds good to me. I'd like to see a couple of extension docs. I have plans of writing one that adds a couple of bits of IMAP data to the JMAP objects, in particular: Mailbox: { uidvalidity: Number, imapname: String } Message: imapdata: { uniqueid: { uid: number, savedate: date } } But plans are all very well, I have to do it! Bron. On Tue, 6 Mar 2018, at 06:43, Barry Leiba wrote: > Given that this is directly within our charter, work that was > discussed in Singapore, and a good first stab at extending the base > JMAP, your chairs would like to ask the working group to take Alexey's> proposal on as a starting point for a working group document. If > there are no objections to that by the Monday of IETF week (19 March),> we will approve Alexey's draft for posting. > > Barry, being chair-like > > On Mon, Mar 5, 2018 at 12:12 PM, Alexey Melnikov > wrote: >> Hi, >> >> I wrote a very early draft on how a JMAP server can return S/MIME >> signature>> verification status to a JMAP client. I would like to submit it as a >> working>> group document as a concrete proposal to start to a proper >> discussion.>> >> Comments are welcome! >> >> >> Best Regards, >> >> Alexey >> >> >> >> _________________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap >> > > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152029083821931260 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
This sounds good to me.  I'd like to see a couple of extension docs.  I have plans of writing one that adds a couple of bits of IMAP data to the JMAP objects, in particular:

Mailbox: { uidvalidity: Number, imapname: String }
Message: imapdata: { uniqueid:  { uid: number, savedate: date } }

But plans are all very well, I have to do it!

Bron.

On Tue, 6 Mar 2018, at 06:43, Barry Leiba wrote:
Given that this is directly within our charter, work that was
discussed in Singapore, and a good first stab at extending the base
JMAP, your chairs would like to ask the working group to take Alexey's
proposal on as a starting point for a working group document.  If
there are no objections to that by the Monday of IETF week (19 March),
we will approve Alexey's draft for posting.

Barry, being chair-like

On Mon, Mar 5, 2018 at 12:12 PM, Alexey Melnikov
Hi,

I wrote a very early draft on how a JMAP server can return S/MIME signature
verification status to a JMAP client. I would like to submit it as a working
group document as a concrete proposal to start to a proper discussion.

Comments are welcome!


Best Regards,

Alexey



_______________________________________________
Jmap mailing list


_______________________________________________
Jmap mailing list

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


--_----------=_152029083821931260-- From nobody Mon Mar 5 22:24:23 2018 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 34F4B12EA59 for ; Mon, 5 Mar 2018 22:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=LrzyILPv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WjtTymVm 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 cHe9M67aiz_F for ; Mon, 5 Mar 2018 22:24:11 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C07312E8C5 for ; Mon, 5 Mar 2018 22:24:11 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 056922091F for ; Tue, 6 Mar 2018 01:24:11 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 06 Mar 2018 01:24:11 -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=fm2; bh=h1GkEB9I1RkdWGkdE dOxYFl65mzgq+iUKwGgJbCZM/c=; b=LrzyILPvqRuCdtTrGYXDN07VFH2fwEY/7 2+8fdKT0gmi7uiHUazlXvxb6+wIgR/oHrvj2h3Lkt7n60PJbXeSKbE5qCU+6cGbh zR/xoKYCAj2eXQYNJnVKmLClw/72n5BRR/qIYy1WVux67qz4GcoUvfmX1BDYu7jO mzNKbkZHpsVgpSK80F2hABNsJ9UXS1wls6bEApNSs71RVUrhcyHUOCzg1kQhMRC9 +/R98p5jBk/NwOpQJkndqwBHrJkK/PR3QvD31qAeqnmxgl4N8Wkw/jU64nlCSfjD XJjeDx0CVN+sAisvRlOnYgsOoW+Bjku/GzODB+9n/ptKV+MZvCQ3A== 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=fm2; bh=h1GkEB 9I1RkdWGkdEdOxYFl65mzgq+iUKwGgJbCZM/c=; b=WjtTymVmWmPcwV4JLvw1yn HR/5UZuoNsCkUm3PUmUdnMZ83UpqDM8W/jhanxth7deJOBWgMzpxwy/AgDTAKCmB J8+Z5mGP/Uf4eN5cDwgBZUYbDyg4roSDggK5vPxvxLfTCaMiVDSuj/XkDxx5pQE2 q+8IpmOgwsazvXGx6nOgUVvpli7iVlcecu3fAg09AMPh0cAA9pZYjPiCJNj1sr3h lbx3bbker9VQEO2DAKww6bZZ2ReVPrX2zpt/qz4ybyJPcigIWhZDQyUIlEkiUCL+ SvUPSObbzs2/5q4VGLxzZb4vjKiHXl22s5e7kIHY9MQkdStbjgAqxlC8LoI0ViKA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B5313E21DC; Tue, 6 Mar 2018 01:24:10 -0500 (EST) Message-Id: <1520317450.734036.1292960800.0ED6DCDC@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15203174507340361" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3d810018 References: In-Reply-To: Date: Tue, 06 Mar 2018 17:24:10 +1100 Archived-At: Subject: Re: [Jmap] Core team members from WikiSuite and Tiki Wiki CMS Groupware will be present! was: Re: JMAP added to Hackathon wiki page 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, 06 Mar 2018 06:24:21 -0000 This is a multi-part message in MIME format. --_----------=_15203174507340361 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 6 Mar 2018, at 2:18 AM, Marc Laporte wrote: > Will https://github.com/jmapio/jmap-demo-webmail be updated as well? I'll look at updating that to match the current spec before the hackathon (a good task for a long flight from Australia!) Cheers, Neil. --_----------=_15203174507340361 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 6 Mar 2018, at 2:18 AM, Marc Laporte wrote:

I'll look at updating that to match the current spec before the hackathon (a good task for a long flight from Australia!)

Cheers,
Neil.
--_----------=_15203174507340361-- From nobody Mon Mar 5 22:45:49 2018 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 13B4B124217 for ; Mon, 5 Mar 2018 22:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=MrhK9Eo2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cTtkUVSs 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 WYoicgWA0js3 for ; Mon, 5 Mar 2018 22:45:46 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FD2126C2F for ; Mon, 5 Mar 2018 22:45:46 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 9D82A20D3D for ; Tue, 6 Mar 2018 01:45:45 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 06 Mar 2018 01:45:45 -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=fm2; bh=V3RmIkrQIyxRdU/Su6H7Ya1kAinIA97R362Z0OHRc 4M=; b=MrhK9Eo2QN8V8x83MgORlw301nPX6jEL1TCh6u7qSCYWmhHunMeU1rKZt RF/lbyUDJFwMFh+Jxx+FUC++9Az3GYA+s/0rSAChQTCOtaKTM8RiG+xNDUcMzmYg ORtVKEukuhEylquznT/jRPOfGRsAieRNfFjoMxvQcAmpGQDkDOG6HLzIJBFylW5j ANBS+BAvmjvYMldsX+lhi9tdXabTiXBNp6SUOEqtJH1SOXHF1tqQNX8BZINq30UJ cEKSbu6hggs555Hx/s9Suwlwm1DiMSEUSa2RbibIVGdy9iUHlmVh1fyItUorpDjz N0lJI+9CMVT62+GpGaJRhvwZ+FkTA== 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=fm2; bh=V3RmIkrQIyxRdU/Su6H7Ya1kAinIA 97R362Z0OHRc4M=; b=cTtkUVSsSYOpPOQUrAOaywqt1I8GrT6K6tW0WIUcCz3ab KjX9ztjuC+0+slUEEDNPphDUIyosIv57ZeG0xm8rbYUqWMXcSnX+5aDUO6sVl8is xQWGH5st/D89GP8h70AhLyZFpX2YHzWDEorYzhITvinnuepCucZRHAQO16XpJjZz vy7lywzR1k7ikL6zQqOSDa0XUOX4bT3ZaVkEtcHTAYNH0jSs6Xg9Da4EAP0/2c3Z 4LLveQF46PNw4bAAwLePc9C+SEEEOINWYQKDZgeQJphIh0EUXLG2F1PbHDmYvW6X GVDYTvFx07bqhxYeejwnksCECuond3A/KpBcqu9dw== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4BE1DE21DC; Tue, 6 Mar 2018 01:45:45 -0500 (EST) Message-Id: <1520318745.759158.1292964120.370C7C90@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15203187457591581" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3d810018 Date: Tue, 06 Mar 2018 17:45:45 +1100 Archived-At: Subject: [Jmap] JMAP spec status 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, 06 Mar 2018 06:45:48 -0000 This is a multi-part message in MIME format. --_----------=_15203187457591581 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" As you probably saw, I pushed a new draft of the core and mail specs before the IETF101 cutoff. I have merged the Email object changes, since these seem to have broad support, with the following minor changes: * The ability to add the :all modifier[1] to get all instances of a header. e.g. the "header:received:all" property would return an array containing the raw values of each Received header field (in the order they appear in the message). * An initial suggested algorithm for decomposing bodyStructure[2] into textBody/htmlBody/attachedEmails/attachedFiles =E2=80=93 feedback welcom= e on improvements to this, as while it should work well for conformant messages, I expect people may have real-world experience of hacks required to display malformed messages seen in the wild well. It would be great to pool some of this experience into the suggested algorithm. * The attachedFiles array is now defined to also contain[3] any images that are just in textBody or htmlBody but not in both. It's easy for a client to skip them when rendering attachments if the body list the client used already contains it (you can just compare the partId), but without this important content might disappear when rendering one of the text/html versions. The latest drafts of core/mail are available in standard IETF formats from the datatracker[4] site, or the same content is available with better formatting on the jmap.io website (core spec[5]/mail spec[6]). Almost all the GitHub issues[7] have now been resolved. The remaining few tasks are mainly some IANA updates, which should be easy to get done at IETF101. So now is the time to do a final review of the two specs and raise any remaining issues in advance of the conference! I plan to review the changes since Singapore, and we can go over any remaining issues, but my hope is to have this finished and published before IETF102. Cheers, Neil. Links: 1. https://github.com/jmapio/jmap/commit/b180278da6d83a69795dffa667bac941= 775b7ab5 2. https://github.com/jmapio/jmap/commit/200e6c068e939d5f5d5e847f6f7e8a88= b624001b 3. https://github.com/jmapio/jmap/commit/5122b475b45841e9c3235e0ba5c0c095= 9847fd5e 4. https://datatracker.ietf.org/wg/jmap/documents/ 5. http://jmap.io/spec-core.html 6. http://jmap.io/spec-mail.html 7. https://github.com/jmapio/jmap/issues --_----------=_15203187457591581 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
As you probably saw, I pushed a new draft of the core and mail s= pecs before the IETF101 cutoff. I have merged the Email object changes, sin= ce these seem to have broad support, with the following minor changes:
<= /div>
  • The ability to add the :all modifier to get all= instances of a header. e.g. the "header:received:all" property would retur= n an array containing the raw values of each Received header field (in the = order they appear in the message).
  • An initial s= uggested algorithm for decomposing bodyStructure into textBody/htmlBody= /attachedEmails/attachedFiles =E2=80=93 feedback welcome on improvements to= this, as while it should work well for conformant messages, I expect peopl= e may have real-world experience of hacks required to display malformed mes= sages seen in the wild well. It would be great to pool some of this experie= nce into the suggested algorithm.
  • The attachedFiles array is no= w defined to also contain any images that are just in t= extBody or htmlBody but not in both. It's easy for a client to skip them wh= en rendering attachments if the body list the client used already contains = it (you can just compare the partId), but without this important content mi= ght disappear when rendering one of the text/html versions.

The latest drafts of core/mail are available in standard IETF formats from the datatr= acker site, or the same content is available with better formattin= g on the jmap.io website (core spec/mail spec).

Almost all the GitHu= b issues have now been resolved. The remaining few tasks are mainly som= e IANA updates, which should be easy to get done at IETF101. So now is the = time to do a final review of the two specs and raise any remaining issues i= n advance of the conference! I plan to review the changes since Singapore, = and we can go over any remaining issues, but my hope is to have this finish= ed and published before IETF102.

Cheers,
Neil.
--_----------=_15203187457591581-- From nobody Mon Mar 5 22:51:03 2018 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 403DE126CF6 for ; Mon, 5 Mar 2018 22:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=OUNL9/nY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WRAUL6Zo 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 9w0w5WmVb2il for ; Mon, 5 Mar 2018 22:51:01 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FA6124217 for ; Mon, 5 Mar 2018 22:51:00 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 5757B20D52 for ; Tue, 6 Mar 2018 01:51:00 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 06 Mar 2018 01:51: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=fm2; bh=DNt3VPy+R4rXZjLIT GMju2Apo5G1EbCjnUgzxsQ1dsE=; b=OUNL9/nYEGiVLokKEWUZTWEdncv7LHAEC CrtlfZqeY2zxcIxPUKPdwvTsSyRp+O7l3zeM5J6ZzNbSJUM9/xEnKmYGJPauXonB 4DaYDin1uPlBJ878atSc7ObNx/eH30st2Qz+JIoYQi2pnpH8bTlmum3T4b462nUc CrBxoL5mqRVyVdMzZEiRZRE5Hioi+PVRlSm2acfiRnK9DsQqy31Wf9FhMeWYtpKi 317onebtNNIUEeW1Y/BQOKbBca1+vrpLo3LjTe+fCgpSah/pjpSZxYHJ9qX4hDa6 bpJG3j/VKhpoboB0gHvhB6pTHEY6KCHU1nEiqEaCD985kIT86fdkQ== 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=fm2; bh=DNt3VP y+R4rXZjLITGMju2Apo5G1EbCjnUgzxsQ1dsE=; b=WRAUL6Zo74B0hn6Xb7ylc5 Z6/osuCfAYICgzE4MCnVN1YW0eCwLvlicuuCOyYHaBJ+yq9XGAh0pjRward6SH4n eIQzW80RxWRlDTqun/yNffyhpn1iJIDcq2Zh41/nGV4SiXAfspnaqBT62GZXXoK3 yhIdJyQb3KNsaX2zAONIFkn62BxndMoS4HEZ4l4R0dYt7DYjr/cRh0337LYg70ga wS4Xt9rn5465CWyRxVkkHuQMEvsNwpTlAsHVG659cmXzOv6fvLQjQwMp/QsmvLXW tDLghq37O1ogMzO7ZBeEucegGeJypBOQU4wT8vGSYQWpQVy5mzI7/JVEVWmgClhg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1AC94E21DC; Tue, 6 Mar 2018 01:51:00 -0500 (EST) Message-Id: <1520319060.767299.1292974264.7F3FEDB5@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15203190607672990" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3d810018 Date: Tue, 06 Mar 2018 17:51:00 +1100 References: <1519958837.2920887.1288630488.7B45C42B@webmail.messagingengine.com> <20180302085241.8A431127201@ietfa.amsl.com> In-Reply-To: <20180302085241.8A431127201@ietfa.amsl.com> Archived-At: Subject: Re: [Jmap] Handling of unknown properties in /get properties section 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, 06 Mar 2018 06:51:02 -0000 This is a multi-part message in MIME format. --_----------=_15203190607672990 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 2 Mar 2018, at 7:52 PM, JFCM wrote: > Are there JMAP server open codes available we could use ? The most complete/up-to-date open-source implementations I am currently aware of are Cyrus[1] (which is a full JMAP/IMAP/CardDAV/CalDAV server) and a Perl JMAP Proxy[2] (which sits in front of an IMAP/CardDAV/CalDAV server to provide JMAP; this is currently more designed for testing rather than production-level use). Once the spec is finalised sometime in the next few months there will be a stable target so hopefully we will see more. Neil. Links: 1. https://www.cyrusimap.org/ 2. https://github.com/jmapio/jmap-perl --_----------=_15203190607672990 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 2 Mar 2018, at 7:52 PM, JFCM wrote:
Are there JMAP server open codes available we could use ?

The most complete/up-to-date open-source implementations I am currently aware of are Cyrus (which is a full JMAP/IMAP/CardDAV/CalDAV server) and a Perl JMAP Proxy (which sits in front of an IMAP/CardDAV/CalDAV server to provide JMAP; this is currently more designed for testing rather than production-level use).

Once the spec is finalised sometime in the next few months there will be a stable target so hopefully we will see more.

Neil.
--_----------=_15203190607672990-- From nobody Tue Mar 6 00:25:28 2018 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 10D49126CF9 for ; Tue, 6 Mar 2018 00:25:27 -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 vaTRIa_AzhhN for ; Tue, 6 Mar 2018 00:25:25 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 004FF120724 for ; Tue, 6 Mar 2018 00:25:24 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id g12so8008323pgs.0 for ; Tue, 06 Mar 2018 00:25:24 -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=fWCWt3+nON2PmHArzlO5TWIEdJNij8AtUsMJDUFmMN0=; b=n5885+7L1uuO60dC83MrqIDvNZ0he/WbHne/Br5satlptMZcoITDO/64AWVgqKy4zB 4wKI2wLEA/HfSUYF4haxazZlq+pajPbEDg06GG0bjyjmzf/KB8qDndZHtMtWu5gqalZI gAef/cM8CRmaW4AeJh/f0pno6yEu46m/7NLLuCa2GdiLA8QR01/j/wJl/imX4yDwvvkG +yH2bdOg0//EMk+I3HWRq0vOG9dVuoRDgs3hZmyAKXHXWURiUCQfDu0pn+GASKZ1gJoU kR+WsEhGpwfhMm1Hrl+hZsVjgI9a1Pr3uLL2af9AZbTxrEoh4e7WEW8rf10d9ZPKJzmJ W7Rw== 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=fWCWt3+nON2PmHArzlO5TWIEdJNij8AtUsMJDUFmMN0=; b=V0vlipQWVVjSQyxug4rh6YdNv5do9NUQcLHV7oyXeC7d8Po/M8SROZVYReBalDj5EH y6EDUa59iOHKC7WLYc6jO7/M9rJom9WgZVr8v0x1v9vTdZxsohI1Gh6Qbkl3d+8HG2J7 Pd9at6Nke86lAtMVQEfDhXvJUSb2W7GRDoiEq7LCly7qaWCT8qXFy00qQpq3L+TFTTT5 4/94nnNud8FgyzIPhMidTWZPFFMhAS1gb5nCrO0IWKmY/x03M4OIwZ0Jhd1vWEUrKVMs j/1xxMhhvak0/Iace8UPpve/PQydPedLA1mkiUWpCdD/AhXVE1JFlu/68JQu4q/fN9g0 anYg== X-Gm-Message-State: APf1xPDfhFZEVic1PFSMoKsEhIHXWmUJLSoSfIlTmgGNG62l6Hix/oxx k/oGwmwHpA9JXJAZIsGPgzOgB8kgVE0= X-Google-Smtp-Source: AG47ELvPWncorUrqmrybuMQnigAPcakNaIgoIFRWKbgFMu1bq4qZ12EPyu9PaJitDZYqTbGFc4cCPQ== X-Received: by 10.99.103.196 with SMTP id b187mr14636941pgc.1.1520324724241; Tue, 06 Mar 2018 00:25:24 -0800 (PST) Received: from ?IPv6:2601:646:4000:6640:388a:7366:cb57:656e? ([2601:646:4000:6640:388a:7366:cb57:656e]) by smtp.gmail.com with ESMTPSA id m12sm22539990pgr.35.2018.03.06.00.25.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Mar 2018 00:25:23 -0800 (PST) From: Neil Jhaveri Message-Id: <23FBD8A8-934B-4223-A8A7-E844F21F4611@neiljhaveri.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D31EE77-1E5E-4E69-95B4-C60C53FCE540" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 6 Mar 2018 00:25:21 -0800 In-Reply-To: <1520318745.759158.1292964120.370C7C90@webmail.messagingengine.com> Cc: IETF JMAP Mailing List To: Neil Jenkins References: <1520318745.759158.1292964120.370C7C90@webmail.messagingengine.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Jmap] JMAP spec status 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, 06 Mar 2018 08:25:27 -0000 --Apple-Mail=_9D31EE77-1E5E-4E69-95B4-C60C53FCE540 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The new draft looks great, Neil! > An initial suggested algorithm for decomposing bodyStructure = into textBody/htmlBody/attachedEmails/attachedFiles =E2=80=93 = feedback welcome on improvements to this, as while it should work well = for conformant messages, I expect people may have real-world experience = of hacks required to display malformed messages seen in the wild well. = It would be great to pool some of this experience into the suggested = algorithm. I took a look at this suggested algorithm, and while basic, it looks = pretty solid to me. My recollection working on Apple's Mail clients is = that there actually weren=E2=80=99t many special cases in the flattening = logic, and that the suggested algorithm already in the draft actually = covers any special cases I saw added over the years. The major = differences are around additional supported features, such as support = for displaying text/enriched. I do have one minor nit-pick comment, related to the assumption of = Content-Type. If a part has no Content-Type, I believe it=E2=80=99s = supposed to be assumed to be text/plain (unless it=E2=80=99s a child of = message/digest, in which case it=E2=80=99s assumed to be = message/rfc822). In these cases, I think the algorithm could use a small = tweak to consider a part=E2=80=99s assumed Content-Type when the = Content-Type is null? =46rom the other thread, I=E2=80=99d still also like to see video/* and = audio/* join image/* in being included in the list of types that can be = inlined into textBody/htmlBody when the Content-Disposition is not = attachment (since these can be easily displayed using the HTML5