[Top] [All Lists]

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

2019-11-27 09:09:46
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.


ietf-smtp mailing list