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.

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

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.