ietf-smtp
[Top] [All Lists]

[ietf-smtp] Editor's policy note on rfc5321bis

2019-12-15 15:14:28
Hi.

Especially for those whose history with me and SMTP
specifications does not go back 20-odd years to the beginning of
the work that became 2821, let me explain how I'm going to
approach "would you add XXX" or "would you change YYY" requests.

I believe that, with these documents, I'm acting very much as
the recorder/ holder of the pen for a consensus process.  With
one group of exceptions, I will fix obviously stupid mistakes as
they are uncovered and identified, but my working hypothesis is
that, after the 2821->5321 editing process and 11 years for
errata to accumulate, there are none of those left that have not
been identified.  That exception is with details about the ABNF.
For better or worse after too many years working on programming
language standards, ABNF and I have never been friends, a
problem that has gotten more pronounced as it has gotten more
complicated (others might say "expressive").  That doesn't mean
I'm opposed to it but it does mean that I'm not comfortable
making subtle changes without evidence of consensus among those
who have done careful checking even if people claim that the
problems are obvious.  

The default, absent fairly clear consensus for change of a
particular part of the specification, is that the document is
correct or close enough to it and should not be changed.

More broadly, I am also very, very, conservative about anything
that might be interpreted as a substantive change and/or one
that would cause currently conforming implementations to not
conform any more.  I see no point in revising 5321 at this stage
unless we can move the revision to Internet Standard and I take
a narrow view of the rules that prohibit substantive changes
(other than removal of features that are really, really, unused)
without going back to Proposed Standard.

If there even the appearance of disagreement about what should
be done or whether a particular change should be made, I'm much
more likely to add notes to the document about the controversy
(in addition to those that are there already) than to start
making changes... and will not make changes until there is a
clear consensus.

The other thing that everyone who is going to participate in
discussions of revisions should know is that I have never been
happy with the "several specifications pasted together"
structure of 2821/5321.  There was a clear decision made when we
started working on 2821 to do that rather than risking
introducing errors by rewriting and I think it was, on balance,
probably the right one.  However, as anyone who has actually
tried to trace the discussions of IP literals through the
document in the course of the recent discussion knows, the
result is something hard to read and interpret exactly because
the use of such literals is discouraged in some places,
discussed without comment in others, and yet rejection on the
basis that one appears appears to be covered by a MUST NOT.  I
don't believe there are any inconsistencies there, but the rules
are hard to extract and follow with confidence.  I'd welcome
specific suggestions as to what to fix, but those suggestions
will be expected to meet the same standards for consensus and
not making incompatible changes as anything else... and I think
we all need to understand that a complete fix probably requires
a complete rewrite.

Finally, if people don't want to rely on my strategies and
judgment as outlined above, push the ADs toward a WG with a
consensus charter.  If there is a WG, I'm going to do whatever
the WG chair(s), after making consensus calls as seem needed,
tell me to.  Without a WG, the above applies and, in particular,
I'm likely to be quite unsympathetic "maybe that was a good idea
once, but it isn't any more and we should change the spec"
requests.

best,
  john

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

<Prev in Thread] Current Thread [Next in Thread>
  • [ietf-smtp] Editor's policy note on rfc5321bis, John C Klensin <=