Re: [ietf-smtp] Email standard revision

[John C Klensin <[e-mail]>]

Dave,

I agree with your logic.  I just don't see it as being as simple
as all that, primarily because I don't see a way to alter only
"minor" details while ignoring major issues if there are any of
those -- and some have asserted that there are.

Disclaimer: as editor, I'm willing to do whatever the consensus
is about this, even if that requires holding my nose.

In principle, I'm fine with "a cleanup".  The difficulty I see
is that the language in RFC 2026 seems very clear to me: "no
known technical omissions with respect to the requirements
placed upon it" without an explicit IESG waiver for Proposed
Standards; not even an exception procedure for Internet
Standard.   Unless you and Barry (and/or the other ADs) see a
way to waive that section of 2026 and intend to do so, I believe
the only option is for a WG to go through the list of issues in
Appendix G of draft-klensin-rfc5321bis-02 and determine, for
each one, whether it is "cleanup" (including technical
omissions) or new work that can be handled elsewhere (or not at
all).  I think (or at least hope) that some things on that list
can be quite quickly disposed of as inconsistent with a cleanup.
As examples, pushing into authentication or TLS issues apprear
to me to rather clearly on that list but others may disagree.
Some of the other items listed may be less clear.  But I see no
way to separate what is, or is not, "cleanup" by writing general
scope statements: sooner or later, either someone is going to
assert the authority to make command decisions and people are
going to decide to accept that or "we" are going to have to go
through that list one item at a time.

And, of course, there is nothing particularly special about that
list: if someone identifies an issue tomorrow that is
significant enough to be a "known technical defect", I see no
way to bar that issue from the discussion.

best,
   john



--On Tuesday, February 18, 2020 07:20 -0800 Dave Crocker
<[e-mail]> wrote:

> Folks,
> 
> After some discussion with Barry, what seems to have been
> missing is a clear statement of needs and goals.  Many
> different approaches to revision are possible and reasonable.
> So the reasons for choosing one needs to be clear.
> 
> 
> Logic for a limited effort:
> 
> 
>      The current, well-established, core specifications for
> email are at a lower standards level than what the
> (realistically) long-obsolete versions.  The goal is to
> (finally) establish the later versions as full standards (and,
> I assume, declare the earlier versions as obsolete.)
> 
>      Any substantive revision to the current specifications
> runs the risk -- actually the likelihood -- of resulting in
> the output being labeled at a /lower/ standards level than it
> current has, thereby exacerbating the original issue.
> 
>      Hence the revision effort needs to be constrained to
> altering only essential, /minor/ details.  A cleanup exercise,
> if you will.
> 
> 
> 
> Yes?
> 
> d/