Re: [ietf-smtp] Email standard revision, was address maximum length
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
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:
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
---- SUBMIT (port 587)
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"
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.
ietf-smtp mailing list
ietf-smtp mailing list