Re: smtp charter (revised)

[Einar Stefferud <Stef@xxxxxxxxxxx>]

Well Ned -- To begin, I want to argue that assigned TCP port numbers
are not a precious commodity (though the supply is arbitrarily
limited), and expending one to resolve all this fuss seems like a very
small investment of an available resource to produce a big result.

I am firmly convinced (after John's interpretation that I was trying
to load up the new Extended SMTP with enough dead weight to kill it)
that I do not want to add any additional burden to the SMTP 8-bit
extension effort.  None!  Zip!

If others want to add weight to the burden, that is their business,
but I will not share any responsibility for having killed 8-bit SMTP
by so loading it up.

I am now convinced that there is a real need to find some way to run
the currently running 8-bit SMTP (lets call it SMTP8) as it is
currently "defined in practice" in certain internet communities that
know what it is and know how to use it, and will agree to not pollute
the 7-bit SMTP communities with 8-bit stuff.

My proposal is to do just that, with a new TCP port number for SMTP8.
I will happily accept that they have done their experiments and found
it to work in very useful ways which they now want to put to work.

I do not suggest any further extension at this time for this new SMTP8
port number.  However, I will not object if others, especially those
who have been lobbying for "8-bit SMTP NOW", want to add some other
extensions, and can agree on what they are and how to do them.  I
regard this as a local matter for the SMTP8 community to resolve.

They should prepare an RFC-smtp8 to specify whatever they want, as
long as it includes a prohibition against "just letting 8-bit stuff go
into the 7-bit community".

Then, as a separate effort, an RFC-87gtwy should be written to define
the relationship between RFC-821 and RFC-smtp8, with due respect paid
to RFC-822 and RFC-XXXX in terms of alignment and smooth interworking.
This RFC-87gtwy will not specify an MTA level conversion.  The entire
conversion takes place in the context of RFC-822 and RFC-XXXX, with UA
level authority!  Thus, it does not belong inside an MTA protocol
specification.  RFC-XXXX should expect and support RFC-87gtwy.

Until RFC-87gtwy is adopted, we should not expect mail to flow between
RFC-821 and RFC-smtp8 communities (except for gtwy experiments and
testing).  If it is critical for mail to flow between these
communities, then someone better get cracking on writing RFC-87gtwy.
I think it only needs to specify a 7-bit<->8-bit conversion, using the
appropriate RFC-XXXX identifiers.

In addition to all this, if someone wants to develop more extensions,
using yet another TCP port for experimentation, this should be OK with
everyone.  If they are wise, they will carry forward and build on the
stuff that is now being developed in the above listed new RFCs.

Best...\Stef