RFC 4978, "The IMAP COMPRESS Extension", August 2007

Errata ID: 4478
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: poima fuimaono
Date Reported: 2015-09-19
Rejected by: Barry Leiba
Date Rejected: 2015-09-19

Section IMAP protoco says:

RFC 4978 vs. RFC 5032 -- mismatch in UPDATES clauses

Within two weeks, two RFCs have been published specifying amendments
to the IMAP protocol:

  o  RFC 4978  -- COMPRESS

  o  RFC 5032  -- WITHIN Search

Both IMAP extensions are similarly structured and arguably RFC 4978
modifies IMAP behaviour specified in RFC 3501 (and other IMAP
extension specifications: IMAP TLS and SASL) to a much greater extent
than RFC 5032 does.

Nevertheless and surprisingly, only RFC 5032 has the line,
  Updates: 3501
in its document header and hence in its RFC index metadata.

This is apparently inconsistent.

An update to the RFC metadata incoporating the relation
     "RFC 4978 updates RFC 3501"
would be welcome as well.
Report New Errata

It should say:

TBD following modifications

Notes:

Both IMAP extensions are similarly structured and arguably RFC 4978
modifies IMAP behaviour specified in RFC 3501 (and other IMAP
extension specifications: IMAP TLS and SASL) to a much greater extent
than RFC 5032 does.

Nevertheless and surprisingly, only RFC 5032 has the line,
Updates: 3501
in its document header and hence in its RFC index metadata.

This is apparently inconsistent.

An update to the RFC metadata incoporating the relation
"RFC 4978 updates RFC 3501"
would be welcome as well.
Report New Errata
--VERIFIER NOTES--
First, errata isn't meant to be used for RFC metadata.

Second, the reason that RFC 5032 "updates" 3501 is that the grammar for the IMAP SEARCH command isn't set up to be extensible, so adding search terms is an update to the base. In contrast, adding IMAP commands generally isn't.

Except that, yes, we have been inconsistent with that over time.

Report New Errata