On Tue 18/Feb/2020 16:20:36 +0100 Dave Crocker wrote:
After some discussion with Barry, what seems to have been missing is a clear
statement of needs and goals. Many different approaches to revision are
possible and reasonable. So the reasons for choosing one needs to be clear.
Logic for a limited effort:
The current, well-established, core specifications for email are at a
standards level than what the (realistically) long-obsolete versions. The
is to (finally) establish the later versions as full standards (and, I assume,
declare the earlier versions as obsolete.)
Any substantive revision to the current specifications runs the risk --
actually the likelihood -- of resulting in the output being labeled at a
/lower/ standards level than it current has, thereby exacerbating the original
Hence the revision effort needs to be constrained to altering only
essential, /minor/ details. A cleanup exercise, if you will.
I agree. I don't think a cleanup, like e.g. the one you proposed[*], would
revert rfc5321bis to proposed standard. However, I'm not clear on how that
works. Certainly, rfc2821 was reverted to proposed standard, but I wasn't
there and I don't know who/how decided to label that I-D to a lower standard.
BCP 9 is not so precise:
[I]f the specification has been changed very significantly, the IESG
may recommend that the revision be treated as a new document, re-
entering the standards track at the beginning.
Since there are quite some issues to be clarified[†], I think the new WG will
need some detailed guidelines about what would be a very significant change.
[†] I annotated some YAM issues at hypothes.is. Additions welcome.
ietf-smtp mailing list