Re: [Last-Call] [Extra] Genart last call review of draft-ietf-extra-imap-uidonly-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.
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.
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/
All of these look good to me. Thank you.
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.
Can probably reference RFC 9051 here.

I thought ABNF verifiers like BAP complain if something is not defined, thus SP is defined by reference.
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.
Extending CAPABILITY and adding to the IANA registry are just different aspect of the same action. All IMAP documents always do both.
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.
Good point.

Best Regards,
Alexey


    
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux