ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Email standard revision, was address maximum length

2019-11-29 17:13:12


--On Friday, 29 November, 2019 11:16 -0600 Pete Resnick
<resnick(_at_)episteme(_dot_)net> wrote:

On 26 Nov 2019, at 2:20, John C Klensin wrote:

 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.

Since my name was mentioned, let me give you my short take on
this:

Both 5321 and 5322 have been in the limbo state of "Draft
Standard" for some time now. Not wildly important, but it
bothers my sense of order.

Mine too, fwiw.  On the other hand, doing 5321 without 5322 or
vice versa would also bother my sense of order, perhaps worse.

The new xml2rfc version is now out. I wanted to play with it,
so I converted my copy of rfc5322.xml to v3.

There were less than a dozen errata against 5322 that could be
trivially fixed. I fixed them as part of my conversion.

It seemed like a lovely time to publish this and get 5322 to
full "Internet Standard". Other things (e.g., MIME, utf8 mail,
etc.) could be progressed as desired. I asked Barry and Alexey
about how we might do this. Dealing with 5321 at the same time
seemed appropriate, so Barry contacted John.

Note that most of the tough "should we update or not" issues
are 5321 issues, not 5322.

Which as you know from my first response to you, Barry, and
Alexey, I also agree with.

Even the "From: rewriting" issue is
a gatewaying issue, not a message format issue per se.

That is less clear.  It fits into the gray area that has existed
for years about just exactly what a mailing list exploder /
redistribution system really is.  We've traditionally threaded
that needle by saying that, if the message is simply
redistributed, without messing with content (or headers other
than trace ones), then it is an SMTP matter, and that is what
5321 talks about.  If more drastic changes are needed, the story
we have told is that the mailing list mechanism is acting as the
agent for the mailing list manager and really more like a
specialized MUA.  I don't need to remind you about this, but
that it the main reason 5322 specifies "Resent-" header fields
and 5321 at least implicitly forbids true, MTA-level exploder
from messaging with them.   So, as I say, not clear.  And, fwiw,
an argument that anything rewriting a "From:" field should be
identifying itself in Resent- header fields.

So there is at least one touch issue with 5322bis even though
I'm prepared to believe it is the only one that isn't an
Applicability Statement-like issue about what we are really
recommending what people do.


All of
the 5322 issues (including "are we really documenting existing
practice) seem to be handled by extensions to 5322 (again,
like MIME) on the format side of things. So I contend that
5322 is pretty much ready to go, and 5321 is the more
interesting problem. (Glad to hear disagreements with that
position.

See above and offlist note you have already seen, while
continuing to agreed with 5321 is the more interesting case and
set of problems.  It would be even if we decided to ignore the
"paste bits of multiple documents together" versus "write
something coherent" question for which we have chosen the first
options twice and ended up with errata and complaints both times.

Back to waiting for Barry and/or Alexey.
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>