On 1/2/2020 10:17 AM, John C Klensin wrote:
Whether we
change the spec to follow their practices or retain and clarify
the recommendation, it seems to me that we are going to need
text, somewhere, that explains our decisions, why we are giving
whatever advice we are providing, and why people should follow
that advice. That text, which probably belongs in a separate
document from RFC531bis, may actually be more important than
whatever we put in 5321bis.
If it turns out to be more important than the actual protocol spec,
we've got bigger problems.
But explanatory text certainly can be helpful. Here is is worth
distinguishing text that explains utility of what is specified -- and
one of the benefits of the IETF style of specification, as opposed to
that of many other standards organization, is that such text can be
inline with the spec -- versus discussion of group decision-making that
produced the spec.
While production of this latter type of history review can be
interesting, I'm not aware of that being a regular -- or even
established? -- practice in the IETF.
I don't recall specific examples, but believe it has been done, though
not very often. Perhaps you can cite some examples?
Absent our providing a persuasive
explanation of why people should, or should not, do something,
experience, both on the anti-spam side and based on continuing
references to 2821, suggests that sites will do whatever they
(locally) think best and that some of those decisions will be
ill-informed.
Such explanation has pretty much never altered independent
decision-making in the adoption or rejection of Internet mail practices.
Perhaps you have counter-examples?
The same principle applies, IMO, to suggestions that we pull
material out of 5321 that is considered obsolete, irrelevant, or
not belonging there. Some of the arguments about what should be
included ultimately date from the 1980s and involve questions of
whether the envelope-message body (with headers) separation
arrived at then was correct, whether we should have placed more
reliance on message processing rather than transport processing
or vice versa, and so on.
The topic of the envelope received significant discussion during the
development of RFC 5598:
4.1. Message Data
The purpose of the Message Handling System (MHS) is to exchange an
IMF message object among participants [RFC5322]. All of its
underlying mechanisms serve to deliver that message from its Author
to its Recipients. A message can be explicitly labeled as to its
nature [RFC3458].
A message comprises a transit-handling envelope and the message
content. The envelope contains information used by the MHS. The
content is divided into a structured header and the body. The header
comprises transit-handling trace information and structured fields
that are part of the Author's message content. The body can be
unstructured lines of text or a tree of multimedia subordinate
objects, called "body-parts" or, popularly, "attachments".
[RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].
and
4.1.1. Envelope
Internet Mail has a fragmented framework for transit-related handling
information. Information that is used directly by the MHS is called
the "envelope". It directs handling activities by the transfer
service and is carried in transfer-service commands. That is, the
envelope exists in the transfer protocol SMTP [RFC5321].
Trace information, such as RFC5322.Received, is recorded in the
message header and is not subsequently altered [RFC5322].
If there has been discussion that deviates from this and/or calls for
modifications to this, please cite it.
That even includes such questions as
whether RFC 974 was the right solution to that problem and
remains the right solution in a world in which the DNS is being
optimized for other things and we have strongly discouraged open
relays (something else 5321 says little or nothing about) and
whether, when we introduced EHLO, we should also have introduced
a three-layer envelope [2] and whether we should do that now via
a new but strongly-recommended extension.
Again, please document indications of current community concern of these
issues.
In any event, I believe the discussion we need now is how we get
to a WG and how to sort out the details of Barry's suggested
approach for moving forward.
Whereas I think there's been some significant attempt to do just that.
As just one example, as I read his
suggestion, I don't think it allows making major scope changes
in 5321bis, especially because, because of the way it is
constructed, different parts of that document are sufficiently
intertwined that simply adding or removing a substantive
sections or two may lead to inconsistencies that would require
very careful examination and revisions to sort out [3] [4].
Ahh. I think there's been some very useful discussion about work to be
done, but apparently you think that Barry's suggestions somehow
constrain what constructive discussions we are permitted to have? So,
ummm, his suggestions were really a mandate?
[2] Somewhat like the X.400 P1/P2/P3 distinction but not
necessarily using that model. I note that many of the rough
edges associated with the relationship between trace information
from xx21 and the header specifications of xx22 and many of the
issues with signatures over message headers would be at least
considerably simplified by pushing that type of information into
an intermediate layer or structure.
Whereas I think that any issues with disparities, ambiguities, etc.
between RFC *21 and RFC *22 involves the occurrence of redundant text
rather than thoughtful incorporation by citation from one to the other.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp