Re: [ietf-smtp] Email standard revision, was address maximum length

This is not in response to any specific message in this thread, but 
rather to the general idea of revising the email standards yet again:
The last thing I think the Internet community needs is more pages of 
email standard to sift through.
It's tempting to think that revising the standard makes things simpler 
for implementors.   My take on the situation is that it does the 
opposite.   No matter how much care is taken, every revision has the 
potential to introduce new incompatibilities that can adversely affect 
interoperation.   A diligent implementor will consider all of these when 
making implementation choices.   For instance, a mail user agent written 
in 2019 may still be expected to deal correctly with email messages 
written in the 1980s.
As far as I can tell, the RFC process in which entire documents are 
revised, and entire documents are subjected to multiple layers of 
scrutiny for each revision, is not a good process for mature and 
relatively stable specifications.   (By "relatively stable" I mean that 
a very high degree of compatibility with previous implementations is 
expected, so changes are mostly in the form of slight tweaks and 
clarifications.)   We see the problems with the RFC process in the email 
realm more than in some other realms precisely because the email 
protocol specifications are so old and have been used for so long.
And as much as I respect the effort and diligence that has been put into 
all of the revisions of RFCs 821 and 822, it's hard to escape the 
impression (in hindsight) that we would be better off if instead of the 
last N revisions, we had instead stopped revising whole documents and 
instead had a way of annotating old RFCs.     If for instance we had 
decided to stop whole-document revision at RFC2821, we'd still be using 
that document, but whenever we viewed it we'd see the original 2821 text 
along with any subsequently approved annotations, say in a different 
color or typeface.   Instead of reviewing and approving entire new 
revisions, and subjecting every revision to de novo scrutiny, we'd just 
get consensus on the annotations.   Not only would this process be 
easier for everybody: WG members, editors, IESG, the RSE, and 
implementors, it would minimize the potential for incompatibility and 
gratuitous changes.
I might even suggest that the time to permit annotations as an 
alternative to whole-document revisions is when a document has attained 
full Standard status.   It should be possible to annotate a Standard 
with relatively low effort, as long as the changes made were limited in 
scope to say clarifications and implementation advice based on 
experience.  On the other hand a significantly incompatible revision 
should still require a reset to Proposed.
And this isn't just about email.   I really wish we had the ability to 
annotate the original IP, TCP, and UDP specifications for instance.
Of course this would require thinking about RFCs quite differently than 
we do now - an annotated RFC would presumably consist of the original 
document plus some set of annotations (maybe in XML) that could be 
layered on top of the original to form some presentation of the 
composite document.   I assume that there's already some well-defined 
way to specify annotations to an XML document in XML, but a separate 
format might be needed to specify annotations to RFCs that predate use 
of XML.
Keith


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp