Summary
RFC 9051 (IMAP4rev2) obsoletes RFC 3501. Servers and clients that implement it advertise IMAP4REV2 in their CAPABILITY response. Currently imap-types has Capability::Imap4Rev1 but no Capability::Imap4Rev2 variant, so any implementation that needs to advertise or parse this capability falls through to Capability::Other.
Requested change
Add a typed variant to the Capability enum:
pub enum Capability<'a> {
Imap4Rev1,
Imap4Rev2, // RFC 9051
// ... existing variants ...
}
With corresponding codec support (encode as IMAP4REV2, parse case-insensitively per RFC 9051 §9).
Context
RFC 9051 absorbs many extensions already modelled individually in imap-types (MOVE, NAMESPACE, ENABLE, LITERAL-, CONDSTORE, UTF8=ACCEPT, UIDPLUS, etc.). The individual extension variants are already there; the only missing piece is the top-level IMAP4REV2 capability string so that a server can advertise conformance to RFC 9051 as a whole.
References
Summary
RFC 9051 (IMAP4rev2) obsoletes RFC 3501. Servers and clients that implement it advertise
IMAP4REV2in theirCAPABILITYresponse. Currentlyimap-typeshasCapability::Imap4Rev1but noCapability::Imap4Rev2variant, so any implementation that needs to advertise or parse this capability falls through toCapability::Other.Requested change
Add a typed variant to the
Capabilityenum:With corresponding codec support (encode as
IMAP4REV2, parse case-insensitively per RFC 9051 §9).Context
RFC 9051 absorbs many extensions already modelled individually in
imap-types(MOVE, NAMESPACE, ENABLE, LITERAL-, CONDSTORE, UTF8=ACCEPT, UIDPLUS, etc.). The individual extension variants are already there; the only missing piece is the top-levelIMAP4REV2capability string so that a server can advertise conformance to RFC 9051 as a whole.References