Re: [Jmap] draft-ietf-jmap-mdn-06

cketti <ck@cketti.de> Thu, 11 June 2020 10:39 UTC

Return-Path: <ck@cketti.de>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B143A1810 for <jmap@ietfa.amsl.com>; Thu, 11 Jun 2020 03:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cketti.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8srgD9rlQZ0K for <jmap@ietfa.amsl.com>; Thu, 11 Jun 2020 03:39:13 -0700 (PDT)
Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5DD93A17F1 for <jmap@ietf.org>; Thu, 11 Jun 2020 03:39:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591871949; s=strato-dkim-0002; d=cketti.de; h=In-Reply-To:Date:Message-ID:From:References:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=r4B4ZAe7nSSDZDpHEtA41pGP1DKtVkWyuAR3nkw8ylg=; b=gEU+DjmTf4cQjWX5RI2j0LpG3IqvV7UCwztd+ef+ySDQFBpxyRlYw0SZblV5jOj3Su ARuu7YSBHPoHWBpK+RLc6WMgunC48HyFaGa3Klv9yaXannj7ERoACp1zwDzCZK2qTtmv VSM8rsfUOZA26f22kLeaZLS/B+ughpJigTXcT5JP3o0zqQiyvUyEZuBTK0cmSCC2KW/h jqd/ch4QbQhyG1eqHsQUCIQcEKY9lIEL2jNeTtAi9cNKVyNb4wPARC2udfV8FDBaV0rf T5XzCiQaX7fD/Os1mWAfBJSfSDRrlPwIMZgA+ZDHQH3L7t0tJMaGHAxjwdur3ENsO/eB 7wZA==
X-RZG-AUTH: ":L2ckdkutb+sebmQwUUWXIIIYdHNZM+Bv5gC+3oItIZntReBfOoHCAsuiGZE="
X-RZG-CLASS-ID: mo00
Received: from [192.168.5.133] by smtp.strato.de (RZmta 46.10.1 DYNA|AUTH) with ESMTPSA id N07a15w5BAd80TT (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate) for <jmap@ietf.org>; Thu, 11 Jun 2020 12:39:08 +0200 (CEST)
To: jmap@ietf.org
References: <b5eac159-c58e-dd75-f7f8-73a99b67345d@fastmail.com> <c4a7348f-0a09-19f0-14fd-4162479b4cd4@fastmail.com> <Mime4j.45.b5134222dd4c80fb.170eebd92f8@linagora.com> <ed338838-996a-26ad-3ba6-b5c578155e18@fastmail.com> <Mime4j.56.bf28b98699a28c35.170f24c1a82@linagora.com> <Mime4j.73.6bcc408d91ada72b.170f70b92f4@linagora.com> <Mime4j.49.2de94ecc6101a607.171c12e9c7b@linagora.com> <7e3a193f-6515-4d32-85a0-88bf624ba97c@www.fastmail.com> <050acaf4-05fd-448e-ad64-8313c14f6d23@dogfood.fastmail.com> <6d2919ca-9026-484e-885c-14e8b2bca05e@dogfood.fastmail.com>
From: cketti <ck@cketti.de>
Message-ID: <9424bb4b-ea8d-13be-ef72-75b9ce003339@cketti.de>
Date: Thu, 11 Jun 2020 12:39:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <6d2919ca-9026-484e-885c-14e8b2bca05e@dogfood.fastmail.com>
Content-Type: multipart/alternative; boundary="------------926405B5585FB092FAA4AB38"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/4rF0xAe7eozM-P7t43MD2JZhAao>
Subject: Re: [Jmap] draft-ietf-jmap-mdn-06
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2020 10:39:23 -0000

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

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

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

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