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

"Chris Newman" <> Mon, 08 April 2019 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7F6C120446; Mon, 8 Apr 2019 12:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YWKJm4_57B11; Mon, 8 Apr 2019 12:50:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFE2C120442; Mon, 8 Apr 2019 12:50:25 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x38JgSMU000793; Mon, 8 Apr 2019 19:50:20 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=WlVhbeBLd0BveVrpIyuVg8ezsBYit/xlKqGvTnDOIb0=; b=iVmLw7/2uT1bl3DICl3mVGK+g9sJaTwEozGaTa3VTMNfsfDFkVnOi0rFsDw30sbttAE5 i6crYPwMxp92bUj7BksxRRK9Ifz+1L9wYR6Jx2QmgZPDkRv0PWuyljvR490/UYZwFb9V W10CsLSmBWyadZq105IPbPqy2Rv3xARtIaQhGge5GG16CIeicMz898e+do04yWHW3GO/ p12ojUcZlXsw+8V2i3Vij3rc7xYRlF9h3P3moQqwbA6YKoMJoVa/h3sHYWF4s5BUBlG0 GiGSv3wjDfCJa+armMekX0L9+5wj/h/YZf2f59umFtYwd6IhQiBlXeVnF1/9WYboQQNU Xg==
Received: from ( []) by with ESMTP id 2rpkhsrsfp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 19:50:19 +0000
Received: from pps.filterd ( []) by ( with SMTP id x38JnZcl084441; Mon, 8 Apr 2019 19:50:18 GMT
Received: from ( []) by with ESMTP id 2rpytb7rag-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 19:50:18 +0000
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x38JoHEg028478; Mon, 8 Apr 2019 19:50:17 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Apr 2019 12:50:16 -0700
From: "Chris Newman" <>
To: "Barry Leiba" <>
Cc:, "Bron Gondwana" <>, "The IESG" <>,
Date: Mon, 08 Apr 2019 12:50:12 -0700
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080150
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080150
Archived-At: <>
Subject: Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)
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: Mon, 08 Apr 2019 19:50:36 -0000

On 8 Apr 2019, at 12:38, Chris Newman wrote:

> On 7 Apr 2019, at 20:25, Barry Leiba via Datatracker wrote:
>> Barry Leiba has entered the following ballot position for
>> draft-ietf-extra-imap-fetch-preview-03: Discuss
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut 
>> this
>> introductory paragraph, however.)
>> Please refer to 
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> — 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.
>> — 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).
> That alternative design would take control away from the client, make 
> the client code more complex, and make the server code more complex. 
> For clients using deployed request/response-style IMAP APIs, your 
> proposal would violate the API model and thus be incredibly hard to 
> implement without replacing a lot of the API. On the server side, even 
> if I was willing to implement what you propose (and I'm not), I'd have 
> to refuse to issue the untagged response until all PREVIEWs were 
> generated to make sure request/response style client APIs could handle 
> that server behavior -- at which point it's far less efficient than 
> the proposed design where the client has control.

Sorry for the typo: s/refuse to issue the untagged response/refuse to 
issue the tagged response/

		- Chris

> I happen to consider the tagged/asynchronous part of the IMAP model to 
> be an elegant design that is a failure in practice when it encounters 
> the real world of implementations. The fact is the majority of clients 
> and client APIs just get the model wrong -- they're so used to 
> request/response that they try to shove a cache/update model into a 
> request/response model with predictably bad results. In our 8.0 server 
> release, we tried to push the envelope just a little bit by generating 
> untagged EXISTS responses between commands (a behavior that's 
> explicitly encouraged by the IMAP base spec) and that broke 
> interoperability with more than one IMAP client in practice so we had 
> to add an option to suppress that behavior to maintain 
> interoperability with those (admittedly buggy) clients.
>> 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.
> As it turns out, that's exactly the implementation model followed by 
> clients that generate previews manually without this extension. So 
> with the new preview extension those clients just tweak the first 
> command to add LAZY PREVIEW fetch so they possibly get early previews 
> (improving the UI for a very small change). Then the client 
> implementer can add an alternate code path to use the non-LAZY preview 
> fetch variant instead of computing manually or the client implementer 
> could ignore the non-LAZY preview feature and have fewer codepaths to 
> test -- their choice (and the better choice might depend on whether 
> the client is mobile or desktop -- something the server doesn't know).
> Since our server implemented PREVIEW before LAZY was added, I find the 
> proposed LAZY an inconvenient but defensible addition to the protocol 
> because it allows the client this additional implementation 
> flexibility. But if the LAZY extension didn't give the client 
> flexibility, then I'd consider the feature objectionable -- it would 
> be significant unnecessary complexity without a defensible 
> implementation benefit.
>> Why was this not done with the first mechanism?
> I can't speak to why the author wrote it that way, but as a server 
> implementor, I find the way LAZY is presently specified to be 
> perfectly acceptable and it has a straightforward implementation in my 
> server. However, the proposed alternate design would be a royal PITA 
> to implement on my server.
> 		- Chris
>> — 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 
>> capabilities include both algorithms and modifiers, that 
>> required, that the presence of any preview algorithm implies 
>> that the latter not only need not be specified, but is not permitted 
>> to be.  So
>> would mean we
>> support the algorithms FUZZY and FURRY, and the modifiers LAZY and 
>> SLEEPY.  Is
>> that correct?
>> 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 
>> 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.
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> — Section 3.1 —
>> Nit: Please change “alternately” to “alternatively”.
>>    These algorithms MUST be one
>>    of the algorithms identified as supported in the PREVIEW 
>> capability
>>    responses.
>> There’s a number-agreement problem here.
>> NEW
>>    All algorithms in the list MUST have been included in the
>>    list of algorithms identified as supported in the PREVIEW 
>> capability
>>    responses.
>> END
>> — Section 3.2 —
>>    This relaxed requirement permits a
>>    server to offer previews as an option without requiring 
>> potentially
>>    burdensome storage and/or processing requirements to guarantee
>>    immutability for a use case that does not require this strictness.
>> That’s sensible, but can you include some text giving an example of 
>> a situation
>> where the preview might change?  Given that the messages themselves 
>> are
>> immutable, why would applying the same algorithm to the same text 
>> give
>> different results?
>> — Section 4.1 —
>>    The server SHOULD limit the length of the preview text to 200 
>> preview
>>    characters.  This length should provide sufficient data to 
>> generally
>>    support both various languages (and their different average word
>>    lengths) and different client display size requirements.
>>    The server MUST NOT output preview text longer than 256 preview
>>    characters.
>> The text here should make it clear, because many implementers do not 
>> understand
>> the difference, that these refer to *characters*, not *bytes*, and 
>> that 200 or
>> 256 characters can possibly be much longer than 256 bytes.  I worry 
>> that an
>> implementer might allocate a buffer of 256 bytes, thinking that’s 
>> enough, and
>> have it overflowed.
>>    The server SHOULD remove any formatting markup that exists in the
>>    original text.
>> This is OK as it is, but perhaps a bit more specific than necessary.  
>> I think
>> the sense is that the server is meant to do its best to render the 
>> preview as
>> plain text, because that’s what the client will treat it as.  As 
>> such, I would
>> fold this into the earlier paragraph that talks about no transfer 
>> encoding, and
>> maybe say it something like this:
>>    The generated string will be treated by the client as plain text, 
>> so
>>    the server should do its best to provide a meaningful plain text 
>> string.
>>    The generated string MUST NOT be content transfer encoded and MUST 
>> be
>>    encoded in UTF-8 [RFC3629].  For purposes of this section, a 
>> "preview
>>    character" is defined as a single UCS character encoded in UTF-8.  
>> The
>>    server SHOULD also remove any formatting markup, and do what other
>>    processing might be useful in rendering the preview as plain text.
>> _______________________________________________
>> Extra mailing list
> _______________________________________________
> Extra mailing list