Thanks for getting to this in the middle of all of the other
--On Monday, March 16, 2020 11:40 +0000 Alexey Melnikov
I am finally catching up with a few outstanding requests.
On 8 Mar 2020, at 17:49, John C Klensin <john-ietf(_at_)jck(_dot_)com>
(personal opinion, not wearing any particular hat)
Discussions on this (ietf-smtp) list since before IETF 106 and
the informal proposals to try to revise RFCs 5321 and 5322 and
get them done before now (!), have convinced me, and I think
at least some others, that an Applicability Statement or BCP
--one that can cover current advice for application and use of
provisions of the core protocols and related ones -- is going
to be key to an actual revision effort for 5322 and
(especially) 5321 being a matter of weeks or a few months
rather than years of work.
If we are going to continue discussions in anticipation of an
eventual WG, I think it would be helpful to get an outline of
what might be in, or evolved into, such an A/S or BCP posted
soon. It could act, not only as a placeholder but a place to
keep (historically archival, because that might be important)
notes of what we expect to put there, partially so that we
could put pointers and references into 5321bis/5322bis.
I personally like this idea. So +1 from me.
Its presence as a placeholder could also help with
constructing a draft WG Charter.
I guess I am, reluctantly, willing to sign up to produce a
first cut at such an (-D or an outline of one (although
certainly not before tomorrow's posting deadline).
Unfortunately, while I had a clear picture of how to put that
together when I wrote that note, the passage of time and general
disruptions cleared it from memory. Will try to reconstruct
within the next several days, depending in part on how you
(collectively and Barry in particular would like me to
prioritize it relative to RFC-to-be 8753.
But my condition for doing
so would be a volunteer for co-author who would be willing to
take over the work and maintain the document. That would be a
good opportunity for someone new at this work, possibly more
involved in day-to-day operations of large email systems, and
with a different perspective on things than I have. So,
unless others object or the ADs have conflicting advice,
I am willing to help out with this one, if you like someone
not junior (in addition to a more junior person).
Especially since you presumably acquire free time next week,
that would be great. As this moves forward, you (or Barry and
Murray) also need to find a WG Chair or co-chairs and being one
of the latter would also be a good learning opportunity for
someone who hadn't done it before (IMO, it would be wonderful if
you felt like taking the more senior role on because you have
the both the IETF expertise and the long-term email
perspective). For this A/S document, I just don't want people
to depend on me longer-term as sole editor because I suspect I
will have my hands full with 5321bis.
On a similar note, I have been maintaining a list of possible
issues and changes to 5321 in Appendix G of 5321bis. I'm
willing to continue to do that, but it may be that either a
formal tracker or an IETF-sanctioned Github repository would
be a better way to manage and facilitate discussion on those
topics and where they belong. Other than a personal distaste
for trying to track long and complex discussions that I
cannot read in real time in Github, I have no preference
among the three options. But I don't think setting something
up requires a WG or even a firm plan/ draft charter for one
and so, if others (particularly the ADs or or potential WG
chairs) have strong opinions, this would be, IMO, a good time
to get them posted.
While I don't particularly like GitHub interface (I love git
itself), I think it is the more commonly used tool these days.
(My next choice would be trac on tools.ietf.org)
I can set one up, if there is rough agreement to use GitHub.
I'm happy to leave this decision to others. It is partially the
interface, or maybe a sign of advancing age, but I have found
GitHub almost impossible to follow and track for long,
multi-thread discussion. In that respect, the advantage of trac
is precisely that it can keep an issues list but encourages the
action discussions to take place on a mailing list, while
GitHub, in practice, seems to discourage that.
Hope everyone is well and staying that way.
ietf-smtp mailing list