ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] smtp extension model

2019-02-12 05:13:30
On Fri 08/Feb/2019 19:15:12 +0100 John C Klensin wrote:
--On Friday, February 1, 2019 12:26 +0100 Alessandro Vesely wrote:
On Thu 31/Jan/2019 04:46:02 +0100 John C Klensin wrote:

I think those kinds of questions are going to require a WG rather than,
e.g., Pete and I getting together and putting drafts together with while
everyone will be comfortable.  YMMD but be careful what you wish for or
wish the ADs to wish for.>>
+1, it would be about time!

Write a proposal.


:-)


If possible, make a list of things you think need to be changed or at least
examined for changes.

We have this funny situation where SMTP is a /de facto/ standard.  Just
bringing it to Internet Standard would be a Good Thing.  There are not so many
changes to be done.  You say you have notes.  Otherwise the YAM database is
still good.


As you are doing that, note that after IETF LC on what became 5321 closed
there were demands from an AD or two to make editorial and organizational
changes. Some of those changes would have required completely reorganizing
the document.


Reorganizing the document would make life difficult for implementors, which is
not worth doing for purely editorial or aesthetic reasons.


Partially because it was recognized that such a reorganization would require
starting the approval process over and probably discussion in a WG,
compromises were reached that involved a few small changes and probably
satisfied no one.  IMO, we should not try to move forward unless those
issues can be settled (or preventing from arising again) very early in the
process.


The new WG's purpose would be to consolidate the standard, not to explore
experimental rules.  Some parts of the document are observably obsolete, for
example Section 3.9.  In such cases, it would be preferable to state that some
features don't belong to the on-the-wire protocol, and content ourselves with
stating who is responsible for ruling what.


FWIW, I personally believe that it would be a good idea to completely
reorganize and rewrite 5321 because the process by which we folded 821, some
topics covered by 1123, and the extensions work together created a document
that is hard to follow as well as being too long.

It's here that I find it difficult to follow your reasoning.  Yeah, it would be
a fascinating idea, but would it also be a practical task to pursue?


While I think we could patch 5321 (as we patched 2821 to get it) without
needing a very intense review process, I assume that reviewing a
reorganization and rewrite and making sure we didn't inadvertently
introduce errors, requirements, or other substantive changes for which there
was no consensus would almost certainly require an active and committed WG.

I agree an active and committed WG is necessary, but I doubt it'd suffice.


Also, either

* Think about doing formal implementation reports on 5321 and 5892 and, if
any of the changes you think need to be made are new and substantive rather
than, e.g., clarifications or unused features that should be deleted, make
sure I-Ds are written, posted, processed into Proposed Standards (and
reflected in those implementation reports) before you suggest we open 5321/ 
5322.

   --or--

* Figure out how to convince the community that it would be worthwhile to
produce Proposed Standard 5321bis / 5322bis with the clear expectation that
we would want to be working on Internet Standard 5321ter / 5322ter six
months or a year after we got finished with the "bis" versions.

I'd opt for the second one of those that you said.  But...


As you can probably guess, I'd be strongly opposed to that for multiple
reasons, but I'm just one voice.

Eh?  Well, certainly sooner or later there will be a 5321ter if SMTP won't die
before.  Perhaps six months or a year is a bit too early, but ten years after
would seem quite enough, wouldn't it?


Best
Ale
-- 

_______________________________________________
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>