ietf-smtp
[Top] [All Lists]

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

2019-11-28 09:13:07
Just throwing it out there.

IMO, iff we just focus on 5321bis, it will difficult to remain focus on the SMTP protocol because there will be participants, especially those connected with DMARC futures, that will want it considerations being part of the SMTP update, same with SPF and most importantly TLS (encryption).

Over the years, I have peppered in my comments a few times, the idea of producing another "hosting requirements" documents similar to the 1989 RFC 1123:

https://tools.ietf.org/html/rfc1123
RFC1123 Requirements for Internet Hosts -- Application and Support

I always considered RFC1123 as the "holy bible" for internet hosting. With developing and supporting an internet hosting platform, this document put all the internet hosting protocols together. Back then, it was SMTP, FTP, TELNET/RLOGIN and DNS. This was the application layer. There was also the common guide, RFC1122 dealing with the IP transport layer, TCP/UDP which also helped with our RPC client/server framework. But the work concentration was with the application layer.

There was many RFCs to cover all these protocols, many questions, many clarifications needed. You had the available outdated RFCs, the mailing list and the newsgroups. I found RFC1123 was a g-dsend. While I didn't participate in the DRUMS WG, my understanding was that RFC1123 helped jump start DRUMS with much of the SMTP material in RFC1123 added to RFC2821.

For me, RFC1123 was a closer to a technical specification and reference guide with beautiful minimum requirement tables, things engineers look for. It helped with implementation productivity, lower production cost, higher quality and better support, "Getting it Right .... The First Time."

The RFC format, by design, targets a wider audience, it offered a blend of functional and technical guidance and specification. But too often, its verbosity can be subjective with marginal rough consensus. Quite often this is intentional in the name of leaving proposed methods "open ended." But today, with decades of industy-wide IETF-MAN-YEARS, we don't need all the subjective verbosity. I would rather to get the straight forward protocol specifications, minimum requirements tables, explain how all the parts fit and leave subjective reasoning and background information out, put into an appendix or moved into informational support documents, if needed.

My proposal for a modern RFC similar to the format of 1123 that summarizes, clarifies, codifies all the MAIL Hosting related protocols and BCP methods as done today. This is an example outline:

Requirements for Internet Mail Hosts -- Application and Support

- SMTP
- POP3
- IMAP
- DNS
--- DNANE?
- EXTENSIONS
--- TLS
--- AUTH
----  SUBMIT (port 587)
--- SPF
--- DKIM
------- DKIM-BASE
------- DKIM-POLICY
----------- DMARC
--- GREYLISTING
--- OTHERS??

The above is just a quick outline. Others can provided imagine a much better outline, but I suggest sticking with well-established protocols and BCP methods with the goal to consolidate what we know today, not repeating the verbosity, but providing the integrated summaries of what makes a modern mail hosting system for interoperability at ALL SCALES - small to large.

RFC1123 was used to help DKUMS WG produce RFC2821. We can use this new RFC as input for a new WG to produce RFC5321bis.

I know there is also new HTTP-based Mail methods, JMAP? Maybe the JMAP summary work can be added to this "Internet Mail Hosting" requirements guide.

Of course, it may sound like a good idea, and if so, who can help write it. Maybe the above could be just an starting point for what a RFC5321bis WG Charter could consider.

Just throwing it out there.


On 11/27/2019 10:09 AM, Keith Moore wrote:
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

--
HLS


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