Hi Elwyn,
On 08/03/2024 17:35, Elwyn Davies via
Datatracker wrote:
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-extra-imap-uidonly-06 Reviewer: Elwyn Davies Review Date: 2024-03-08 IETF LC End Date: 2024-03-15 IESG Telechat date: Not scheduled for a telechat Summary: The docment is almost ready for approval as an RFC. It has a number of nits, in particular there are a number of missing definite and indefinite articles. One minor issue which I have flagged is that the total suppression of the UIDNOTSTICKY response, even if the client has not enabled the UIDONLY response format, may possibly be inappropriate. Basically UIDNOTSTICKY disables most of modern IMAP functionality (for example a very widely implemented UIDPLUS extension) and it is a hack to allow servers not to persist important state. This is very rarely used and the choice in the document is quite deliberate in this case. Old clients wouldn’t be broken, because most of them don’t support UIDNOTSTICKY anyway. I think it is much simpler to tell server implementors to either support UIDONLY or UIDNOTSTICKY.Major issues: None Minor issues: s3.6: This states that "a server that advertises UIDONLY extension MUST NOT return UIDNOTSTICKY response code." Should this only be the case if the client has enabled UIDONLY? It seems to me that a client that does not use UIDONLY and indeed maybe an old client that does not implement UIDONLY might be confused or broken if it does not receive UIDNOTSTICKY responses when it was expecting them, but my knowledge of IMAP is limited so this might not be the case. All of these look good to me. Thank you.Nits/editorial comments: Abstract and s1: UID is not a well-known abbreviation in the context of the RFC Editors list and needs to be expanded on first usage in the Abstract and in s1. Abstract: It would be good to mention that this proposal is experimental. s3, para 2: s/MUST return tagged BAD response/MUST return a tagged BAD response/ s3, para 4: s/The server returns UIDREQUIRED/The server returns the UIDREQUIRED/ Also this line is too long (flagged by idnits). s3, last para: s/details./detail./ s3.3, para 2: OLD: The UID is always returned at the beginning of a UIDFETCH response, and it can also appear in UID response data item, if requested by the client. While UID response data item is redundant when requested, NEW: The UID is always returned at the beginning of a UIDFETCH response, and it can also appear in the UID response data item, if requested by the client. While the UID response data item is redundant when requested, END s3.5: s/in tagged BAD response/in a tagged BAD response/ s.3.6, para 4:s/SHOULD return COPYUID response/SHOULD return the COPYUID response/ s3.6, para 5: OLD: Use of UIDNOTSTICKY response code (see [RFC4315]) is not compatible with the UIDONLY extension. I.e. a server that advertises UIDONLY extension MUST NOT return UIDNOTSTICKY response code. NEW: Use of the UIDNOTSTICKY response code (see [RFC4315]) is not compatible with the UIDONLY extension, i.e. a server that advertises the UIDONLY extension MUST NOT return UIDNOTSTICKY response code. END s3.7: s/CONDSTORE/The CONDSTORE/; s/QRESYNC/The QRESYNC/; s/such parameter/such a parameter/ s3.8: Add a reference to Section 9 of [RFC 9051] associated with "sequence-set". s3.8: s/server MUST reject/the server MUST reject/ Can probably reference RFC 9051 here.s4: Add a note that this syntax is intended to update the Formal Syntax in Section 9 pf [RFC9051]. s4: Note that redefining SP is inappropriate as it duplicates the definition in RFC 9051. Removing this will also partially suppress a warning from idnits regarding referencing an obsolete RFC. I thought ABNF verifiers like BAP complain if something is not defined, thus SP is defined by reference. Extending CAPABILITY and adding to the IANA registry are just different aspect of the same action. All IMAP documents always do both.s4, uidfetch-resp: The second line (;; The uniqueid is the UID of the corresponding) is too long (flagged by idnits) s4: I am unclear why 'capability' is explicitly extended. The definition in RFC 9051 implies that the possible values come from the IANA database and the UIDONLY attribute is added to that database by s6.1. Good point.s6/s6.1: RFC document structure prefers that all document sections contain substantive text. Currently there is no text in s6 and only one subsection - the text in s6.1 should be used for s6. Best Regards, Alexey |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
