Dear Yingzhen Qu,
On 24/11/2022 11:51, Alexey Melnikov wrote:
Dear Yingzhen Qu,
Thank you for your review!
My answers are below:
On 21/11/2022 20:02, Yingzhen Qu via Datatracker wrote:
Reviewer: Yingzhen Qu
Review result: Has Nits
I have reviewed this document as part of the Operational
directorate's ongoing
effort to review all IETF documents being processed by the IESG.
These comments
were written with the intent of improving the operational aspects of
the IETF
drafts. Comments that are not addressed in last call may be included
in AD
reviews during the IESG review. Document editors and WG chairs should
treat
these comments just like any other last call comments.
Document: draft-ietf-extra-imap-partial-02
Reviewer: Yingzhen Qu
Review Date: 2022-11-20
Summary:
This document extends PARTIAL SEARCH return option defined in RFC 5267.
The document is ready, but the following nits should be considered
before publication.
General: this documents still has a normative reference to RFC 3501,
which
was obsoleted by RFC 9051. RFC 3501 is referenced multiple times in the
draft.
Nits (line numbers are from idnits):
90 This document defines an extension to the Internet Message Access
91 Protocol [RFC3501] for performing incremental searches and fetches.
major: RFC 9051 should be referenced here instead of RFC 3501.
Ok, I will review this. The intend was to reference both RFC 3501 and
RFC 9051.
I checked and I think the following sentence is quite clear on that. So
I haven't done any change.
101 This document extends PARTIAL SEARCH return option originally
nits: should it be "PARTIAL SEARCH" (used 4 times) or "PARTIAL search"
(used 2 times)?
Well spotted. It should be "PARTIAL SEARCH" in all cases.
245 +------------------------------+---------------------+
246 | SAVE PARTIAL COUNT [m] | all found messages |
247 +------------------------------+---------------------+
249 Table 1
251 where '[m]' means optional "MIN" and/or "MAX"
Question: If the SAVE + PARTIAL result options are combined with COUNT,
MIN and MAX, what the result would be? The text above the table didn't
cover this case.
This is covered by the last line of the table, as it also applies when
both MIN and MAX are present, as per the comment under the table.
I tried to clarify that.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call