RFC 3798, "Message Disposition Notification", May 2004
Note: This RFC has been obsoleted by RFC 8098Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app
Errata ID: 691
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2004-10-20
Rejected by: Peter Saint-Andre
Date Rejected: 2011-11-12
(1) disposition types ===================== The dispositions "denied" and "failed" were removed from the document reflecting the lack of implementation or usage ... Now, the syntax production "disposition-type" in section 3.2.6. (on page 14) and section 7. (on mid-page 22) has been changed to read: disposition-type = "displayed" / "deleted" This means that the RFC 2298 disposition types "dispatched" and "processed" have been removed from the syntax definitions as well! Thus, either Appendix A lacks mentioning these removals OR these items should not have been removed from the syntax definitions. Nevertheless, all these disposition types removed from the syntax are mentioned at many places throughout RFC 3798: o "dispatched" : - section 3.2.6. , final paragraph of the section on page 16 - section 4. , third-to-last bullet on page 17 - section 4. , first bullet on page 18 o "processed" : - section 4. , third-to-last bullet on page 17 - section 4. , first bullet on page 18 - section 5. , 4th paragraph on page 18 o "denied" : - section 2.1. , bottom of page 4 - section 2.1. , end of 3rd paragraph on page 5 - section 4. , third-to-last bullet on page 17 - section 4. , first bullet on page 18 - section 6.2. , end of first paragraph on page 19 o "failed" : - section 2.2. , middle of second-to-last paragraph on page 6 - section 2.2. , middle of second paragraph on page 7 (twice) - section 2.2. , third paragraph on page 7 (twice) - section 3.2.7. , in 2nd text line, on page 16 (mis-spelled "failure" there) - section 4. , third-to-last bullet on page 17 - section 4. , first bullet on page 18 All these places in the text deal with the issue/sending/generation of MDNs with the named deprecated disposition types (it would be acceptable to talk about what to do with *received* such disposition types for backwards compatibility with RFC 2298) !
It should say:
Clearly this document is a mess. The solution is to publish an RFC that cleans up the mess (and verifies that there is indeed consensus to remove the "denied" and "failed" dispositions), not to handle this via the errata process.