IMAP PARTIAL Extension for Paged SEARCH and FETCH
draft-ietf-extra-imap-partial-04

# Internet AD comments for draft-ietf-extra-imap-partial-03
CC @ekline

## Nits

### S3.1

* s/prepeding/prepending/ I think

** The notation of “RFC 5267 and RFC 4731/RFC 9051” appears twice and the slash was a new syntax for me.   If this the equivalent of saying using the “extensions in [RFC5267] and [RFC4731] with IMAP4rev2 [RFC9051]”?

I *almost* balloted DISCUSS on this document on process grounds -- I was under the impression that IMAP documents had to be at least 100 pages long, and this one is barely 1/10th of that. Further research has shown that, while unusual, there is precedent for short IMAP documents so I'll let it slide... :-P


Thank you very much to the authors for writing this document - it seems like it will be very useful.
Also much thanks to Yingzhen Qu for the OpsDir review, which contains some useful nits that the authors should address.

Thanks for working on this specification.

I have following comments -

* Abstract and Section 1 : can't parse what "RFC 5267 and RFC 4731/RFC 9051" supposed to mean. A more verbose version would be helpful. I am guessing "RFC 3501/RFC 9051" defined in IMAP version 1 and version 2 both are in scope. 

* Please add a ref to ESEARCH on the first appearance of it in section 3.1.

* Section 3.2 : says - "Note for the table: '[m]' means optional "MIN" and/or "MAX"". This confuses me, as I didn't find any clarification on how to interpret m whether it is a MIN or MAX, or MIN and MAX.

* Section 4 : I think it is better idea to be explicit that the format applies (or not applies then we have issues :-) ) to RFC9051.

# GEN AD review of draft-ietf-extra-imap-partial-03

CC @larseggert

Thanks to Roni Even for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/2YZk9vkP5VyB1YfzU0rOMXzku4k).

## Comments

### Boilerplate

Document has a TLP Section 6.c.iii "pre-5378" boilerplate. Is this really
needed?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.1, paragraph 2
```
-    prepeding "-" to the index.  For example -1 is the last message, -2
+    prepending "-" to the index.  For example -1 is the last message, -2
+         +
```

### Uncited references

Uncited references: `[RFC7162]`.

### Outdated references

Reference `[RFC3501]` to `RFC3501`, which was obsoleted by `RFC9051` (this may
be on purpose).

### Grammar/style

#### Section 4, paragraph 15
```
 Yahoo! team and their questions about best client practices for dealing wit
                                 ^^^^^^^^^^
```
A determiner may be missing.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Hi,

Thanks for this document. Only one minor comment on the security considerations section:

   However, as this is going to be new code in both the
   client and the server, rigorous testing of such code is required in
   order to avoid introducing of new implementation bugs.

I wasn't convinced that this is really relevant to the security considerations of the specification, and presumably this text equally applies to all implementations for new features in all specifications.  Hence, I would suggest that this text could probably just be elided from the document.

Finally, thanks to Yingzhen for the OPSDIR review.

Regards,
Rob