Bron,
I'm going to respond inline to parts of your message, but, after
this, I'm going to follow my own advice and go silent until we
hear from the ADs. All I know at this point is that I was
approached by Barry, Alexey, and Pete about a possible plan to
spin up a WG to address some mail issues including producing and
processing Internet Standard documents to replace 5321 and 5322.
I am resistant to the idea for two sets of reasons. One set was
more or less covered by my earlier note (and I may fill in some
extra details below). The other is that I'm fairly unhappy,
editorially, with 5321 (and 2821 before it). When 2821 was
being created, we (I'm complicit, but it was definitely a WG
decision), to essentially merge RFCs 821 and 1869, some material
from RFC 1123, and some new material. The main reason was that
we were concerned that, if we started rewriting, we would
unintentionally introduce discrepancies that we wouldn't have
the resources to catch. That concern was almost certainly
justified: the one big editorial change we made was to replace
the rather basic BNF of RFC 821 with ABNF. The change was
marked by a lot of errors, some of which were caught before IETF
Last Call and some of which made it into 2821. While that
strategy kept the number of inadvertent changes down, the result
is a document that is hard to read and understand and that is
written in a style (or three) that is inconsistent with how we
talk about things, with one important set of examples resulting
from the 15 years between the publication of RFC 821 and that of
RFC 2119.
For the record, I agree with Dave Crocker about the importance
of focusing on substance, not process. One reason for this is
given in a reply to part of your later note below.
--On Tuesday, November 26, 2019 14:37 +1100 Bron Gondwana
<brong(_at_)fastmailteam(_dot_)com> wrote:
...
I think there's a set of three questions which are raised by
this discussion:
1. Should we ever review/revise 5321 and 5322 within the IETF?
2. If yes, should we review/revise them NOW? (for some value
of) 3. If yes, where should that revision work be done?
If anybody disagrees with me on this set of questions and
ordering, I'd love to hear it! I can't think of any other
questions or a better ordering, but I may well be wrong.
Assuming my questions are sane, let's look at them:
*1.* I'd say there's a very strong argument that we shouldn't
leave those two documents as the final form "forever". As John
pointed out, there are some good justifications for revising
them at some time, including:
* citations are still more common for 2821
Actually, there are two ways to interpret that bit of data. One
is that, were we to issue 5321bis, all of the people who have
been ignoring 5321 would suddenly pick up the new version and
start referencing it. The other is that, if 5321 has been
ignored for more than a decade, a successor could easily be
ignored for equally long.
* there are various errata which it would be good to address
Having addressed many of them in that working draft I mentioned,
most are trivial. That draft also calls out the others that
have not been rejected; some of them raise complex issues about
which we may not easily reach agreement.
* the documents don't necessarily describe actual practice in
the real world (not necessarily an argument for changing them,
but if we don't think the best solution is "push people to
adopt the precise detail of the standard" then a better
alternative is publishing the document that we do want to push
people to follow).
* (significantly tongue in cheek) It would
be way cool to get numbers ending with 82X again instead of
32X. Everyone knows 82X.
Then we had best scurry to get 982x and then try to persuade the
RFC Editor to allocate those numbers further in advance than
they have, IIR, ever done before. Or perhaps that is
justification for sitting around for another several years :-)
If you disagree with my assumption that this is enough to
justify "YES" to 1, then we stop here. Otherwise let's move on.
How about a resounding "maybe" followed by "let's see what the
ADs have to say".
*2.* If not now, when? Are there any conditions which mean
that a time in the future would be better for doing this work
than now? Some examples might be: * experiments in progress
with outputs which will inform the new documents * expected
changes in the userbase which will obsolete work done now *
excessive short-term workload on the people best suited to
work on or review these documents, which means they are likely
to have more availability in the future.
Well, I am personally looking forward to the IETF's solving
internationalization (i18n) before I go back to editing long
email documents. And the strong advocates for SMTPUTF8 (RFC
6530ff) would probably like to see it broadly deployed enough
that 5321bis and 5322bis can require that extension and thereby
get ride of a lot of cruft.
* (ever so slightly
tongue in cheek) a bunch of people are expected to retire/die
in the near future who would otherwise gum up the works
Unless one of those exists to justify a delay in the work, a
YES to 1 implies we might as well do it now!
Which brings us to:
* 3. *Where? Clearly this belongs in ART. Clearly this
requires a working group, this is not AD-Sponsorship level
work. I'm sure the ADs will have things to say here, but I
think it makes sense to spin up a specific working group to
handle just this piece of work.
So, let me anticipate the key question. Let's pretend this is a
BOF and ask the obvious BOF-type question: RFC 5322 is 57 pages
long. The working version of 5321bis contains questions,
annotations, and other material that will come out so the final
version will be shorter, but it is somewhat over 100 pages long
at present. It would be astonishing if such a working group
didn't find a few other documents it needed to look at and
either revise or write to complete the picture. So, to make an
estimate by rounding up a bit, who is willing to commit to doing
careful reviews of each of several probable iterations of up to
200 pages of documents, reviews that including digging in,
finding and discussing problems, and proposing text?
And, finally for now (and until we hear from the ADs) and noting
that I'm about to make a process comment but still agree with
Dave about the importance of looking at substance first:
--On Tuesday, November 26, 2019 15:40 +1100 Bron Gondwana
<brong(_at_)fastmailteam(_dot_)com> wrote:
You clipped out my three questions, but I do agree that you
have raised a question (0) which I did not address. The
question zero is:
*0. Are there known deficiencies with the current documents
which could be addressed by revising them.*
If the answer to that is NO then obviously the others don't
matter.
Actually, there is a 0.1, which is "whether the known
deficiencies with the current documents could be addressed, in
the IETF, without revising them."
Independent of whether it is a good idea or not, we could
address at least a significant fraction of the issues by
generating an Applicability Statement that, if necessary, did a
little bit of document updating rather than doing more or less
comprehensive replacements for the two documents. Such an
applicability statement might reasonably include advice about
which SMTP extensions are just about mandatory at this point.
For example, there is a strong case that an SMTP implementation
that does not support the 8BITMIME extension or a mail header
implementation that does not support encoded words is even more
badly outdated in the modern world than one that restricts
local-parts to 64 octets.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp