Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)

"Alexey Melnikov" <> Wed, 10 April 2019 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E6FE120112; Wed, 10 Apr 2019 05:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=W7NkQQDL; dkim=pass (2048-bit key) header.b=RwsDBh0M
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HsvnHPXq9Yc2; Wed, 10 Apr 2019 05:33:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A29F0120058; Wed, 10 Apr 2019 05:33:28 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id F36EB21E82; Wed, 10 Apr 2019 08:33:27 -0400 (EDT)
Received: from imap1 ([]) by compute7.internal (MEProxy); Wed, 10 Apr 2019 08:33:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=f6ENm JdUhwdyU0HZSMf0trH0tfy9ykakMH4FwYGIJsA=; b=W7NkQQDL+qBqC8GSYRCIs KtsboV0HgN9+woE/lavGnQq1bErKRjWJah27sNpa2pMZTgsf6E+CvQFe32y9OAHx 7BA8gKb+aA5N+HyHEKSxaZrmLzMaPgvw3lS0CdhXACkxsvY1k6ZN3aEPSih5ovas TcHCLcVAmB9RKWdXuXrvLFgbsnyTlQizw9Vhu6CJabZG983gfvwzuIm9mXsbDf1e fFcxOjc5bRBI7868RJUtLp9YFmoOtFptJqIVo2cIJyOUiyxUFw69cauwN52pe2ay t+93na2zuKgv5e6/uNvAAx33QpJGmoVI4l4JjuqXni66cQQ3GIMhqAum6TqBaGET A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=f6ENmJdUhwdyU0HZSMf0trH0tfy9ykakMH4FwYGIJ sA=; b=RwsDBh0MybrNDwL0U3GTq01Je0uS5fp3b/65wY56GhzOlfTioG1EoqkxU lMBw6Qg+INgRjBgLCzj0bcL3IcLqj9XQJdvy7cihnmksJ+LH2cCyjNQhO01lS8UK XFtkuVMXBqr8rtZCrPU4/jmQYwgWJwndnDAoycB+L5m0JDQlRW1g8HOznrNlg8hz DXvQlnUDK0x4Xq7jzJ6SyXNEHb4SATgGxGGnKLxwvqEarmyM9nF7lgso4rq0KkeY /P703ezgoKkwZAkbERrYtbvcyCOTAaP4q4woAYTwOAZcDpRaNjb6QWhLWP2swFwQ p1f2fXAH5s0CVx3S36Z1Lk06dJmTg==
X-ME-Sender: <xms:l-KtXJHUgZi_VKurv4tf_P8BAAwFSKWXms-_2oRpSC119bu5n9zOHg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudejgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:l-KtXIYnO5qmkJAjjyRtYHT9RVoOfr0kIofnh0i7TjqU159Phni9IA> <xmx:l-KtXLCTFOit5_FSzeLo66X1m3xnLHYolg5JcDFaPGPkFigjSc03VQ> <xmx:l-KtXAn9G6JqIGTf7X13mx_djySb-qDPPm48aCXwFa9d7yub9pgczg> <xmx:l-KtXE1J-5jwGvDTURXg7Wx0LDoNdoaSY2abn2f69sQ9Y7skVpj7AQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6C98BD48AF; Wed, 10 Apr 2019 08:33:27 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1
Mime-Version: 1.0
X-Me-Personality: 21611513
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Wed, 10 Apr 2019 08:33:12 -0400
From: "Alexey Melnikov" <>
To: "Barry Leiba" <>, "The IESG" <>
Cc:, "Bron Gondwana" <>,
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Extra] =?utf-8?q?Barry_Leiba=27s_Discuss_on_draft-ietf-extra-im?= =?utf-8?q?ap-fetch-preview-03=3A_=28with_DISCUSS_and_COMMENT=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2019 12:33:30 -0000

Hi Barry,
Replying to your DISCUSS comments only:

On Mon, Apr 8, 2019, at 4:25 AM, Barry Leiba via Datatracker wrote:

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> — Section 3.1 —
> I don’t understand “the client’s priority decision”: what decision is that? 
> And what’s the point of giving the server a list of algorithms here, given that
> they all have to be ones that are supported by the server?  Won’t the server
> always have to use the first one in the list?  If not, please add some text
> explaining what the server does.

For some reason I missed that multiple are allowed here. I think this is overcomplicated and the WG should probably re-review whether multiple should be allowed here.

(Adam raised a few comments on the same section. It needs more work.)

> — Section 3.2 —
>    If the preview is not available, the server MUST return NIL as the
>    PREVIEW response.  A NIL response indicates to the client that
>    preview information MAY become available in a future PREVIEW FETCH
>    request.  Note that this is semantically different than returning a
>    zero-length string, which indicates an empty preview.
> I think the MUST here is hard to follow, because the text doesn’t make a clear
> enough distinction between “preview is not available” and “an empty preview”. 
> Can you expand the text a bit to explain the distinction more clearly, as this
> is a protocol requirement?  Also, as I noted in response to Meral’s Gen-ART
> review it would be good to be clear how encrypted messages should be handled in
> this regard.


> — Section 4.1 —
>    The preview text MUST be treated as text/plain MIME data by the
>    client.
> I think this requires a normative reference to RFC 2046.


> — Section 5.1 —
> The way you have LAZY working isn’t really consistent with the IMAP protocol
> model.  In that model, the client would not have to ask for the preview twice,
> one with LAZY and one without.  Instead, with LAZY, the server would return
> FETCH PREVIEW responses when it could — perhaps some in the first set of FETCH
> responses, and some, where the PREVIEW part was missing before, in unsolicited
> FETCH responses when the preview became available.  That way, the server has
> the responsibility of setting off a separate task to generate the previews, and
> to send them to the client when it has them (at which point it either saves the
> for future FETCHes or doesn’t).
> As it’s written here, the client has to open a separate IMAP session with the
> server and ask a second time for the previews it’s missing — a separate session
> to avoid blocking other action on the main session.  And if the server has spun
> off a task to preemptively generate them because the client asked once (a good
> practice, given the description here) it has to retain them for some indefinite
> period waiting for the client to ask again.
> Why was this not done with the first mechanism?

I think you had a good exchange with Chris Newman on this.

> — Section 7 —
> As was mentioned in Ben’s review, either the ABNF for “capability” is in error
> (it should not include “preview-mod-ext”) or the description needs to be
> significantly beefed up.  I’m guessing that the intent is that PREVIEW=
> capabilities include both algorithms and modifiers, that PREVIEW=FUZZY is
> required, that the presence of any preview algorithm implies PREVIEW=LAZY such
> that the latter not only need not be specified, but is not permitted to be.  So
> we might have “PREVIEW=FUZZY PREVIEW=FURRY PREVIEW=SLEEPY”, which would mean we
> support the algorithms FUZZY and FURRY, and the modifiers LAZY and SLEEPY.  Is
> that correct?

I think this is the intent. I agree that the document needs to be updated to clarify this.

> That seems somewhat obtuse to me, overloading the PREVIEW= capability and
> inviting confusion.
> — Section 8 —
> It seems like a bad idea to have to keep the IMAP Capabilities registry in sync
> with the two new registries: as it stands, when you add a new algorithm you
> have to add it to the Preview Algorithms registry, and also add a corresponding
> entry in the Capabilities registry... and similarly for a modifier, if I have
> that right above.
> Why not follow the model of AUTH= and RIGHTS=, and just reserve the PREVIEW=
> capability in the registry, allowing it to apply to entries from the two new
> registries?  That avoids inconsistencies in registrations if we later add
> algorithms or modifiers.

I think this is a good idea.

Best Regards,