(just in time for shipping the final version for IESG consideration after Last
Call...)
SM wrote:
In the Introduction section:
"The underlying technical standards for Internet Mail comprise a rich
array of functional capabilities. The specifications form the core:
* Simple Mail Transfer Protocol (SMTP) [RFC0821], [RFC2821],
[RFC5321] moves a message through the Internet.
* Internet Mail Format (IMF) [RFC0733], [RFC0822], [RFC2822],
[RFC5321] defines a message object."
RFC 733 was obsoleted by RFC 822.
The text is not normative and is providing the historical chain of development
for transfer and content specifications.
Section 2.2.1 of the draft defines the Originator as:
"The Originator ensures that a message is valid for posting and then
submits it to a Relay."
In Section 2.2.3:
"The basic test of Gateway design is whether an Author on one side of
a Gateway can send a useful message to a Recipient on the other side,
without requiring changes to any components in the Author's or
Recipient's mail services other than adding the Gateway."
As it is the Originator doing the submission, "Author" should be
replaced by "Originator" in the above paragraph.
The words for Originator are "posting" and "submits". "Send" is a different
word. It is commonly used in a variety of ways, some rather vague. As shown in
Figure 2, there really is a logical connection between Author and Recipient.
Referring to the use of that connection as sending to a Recipient.
One of the key points behind a layered architecture like this is that these
higher-level, logical, end-to-end relationships are primary. Author and
Recipient perceive themselves as sending to each other. They mostly don't
perceive all the underlying mechanism.
In Section 3.4 of RFC 5322, it is mentioned that:
"A mailbox receives mail. It is a conceptual entity that does not
necessarily pertain to file storage."
Section 3.1 of the draft has:
"A mailbox sends and receives mail. It is a conceptual entity
which does not necessarily pertain to file storage." [RFC5322]
fixed. thanks.
In Section 3.3 of the draft:
"The name is structured as a hierarchical sequence of names, separated by
dots (.), with the top of the hierarchy being on the right end of the
sequence. There can be many names in the sequence -- that is, the
depth of the hierarchy can be substantial."
Section 3.1 of RFC 1035 uses "sequence of labels" instead of "sequence
of names".
Hmmmm. Ok. Since the cited specifications do say 'label', I've switched the
text to say that, although I personally view 'names' as more helpful to the reader.
Section 4.4 of the draft mentions that the the MIME Header is set by the
Author. It should be the Originator as that is done when the message is
submitted.
Section 4.1.4, Table 1?
The Author, not the Originator, defines the body. MIME structuring and labeling
is defining the body. It is very much *not* the job of the Originator, which
has more clerical duties.
"RFC5321.ORCPT: Set by - Author.
This is an optional parameter to the RCPT command, indicating
the original address to which the current RCPT TO address
corresponds, after a mapping was performed during transit. An
ORCPT is the only reliable way to correlate a DSN from a multi-
recipient message transfer with the intended recipient."
Table 1 lists ORCPT as being set by the Originator.
fixed.
As the "RcptTo" is at the SMTP layer, it might be more appropriate to
have it "Set By" the Originator instead of the Author.
The Legend for Table 1 notes:
"Set By - The actor role responsible for specifying the identifier value
(and this can be different from the actor that performs the fill-in function for
the protocol construct)"
Again referring to the logical view, Authors send to Recipients. Authors
specify Recipients. The underlying mechanism that populates the RcptTo SMTP
command is following a choice made by the Author.
"RFC5321.Return-Path: Set by - Originator
The MDA records the RFC5321.MailFrom address into the
RFC5322.Return-Path field."
The RFC5321.Return-Path looks like a typo. It should be
RFC5322.Return-Path and it is "Set by" the MDA according to the Table 1.
RFC 5321, Section 4.4:
"When the delivery SMTP server makes the "final delivery" of a
message, it inserts a return-path line at the beginning of the mail
data."
RFC 5322, Section 3.6.7 -Trace Fields:
"A full discussion of the Internet mail use of trace fields is
contained in [RFC5321]"
As usual, it is indeed confusing to have redundant definitions in two different
specifications. Happily, here, one makes clear the other is the controlling
spec for this item.
So email-arch does have an error, here, but it's the opposite of what you note.
Now fixed.
RFC 2298 is obsoleted by RFC 3798.
fixed.
There is a typo (RFC 2304) in the
reference for RFC3192.
ewwwww. good catch. fixed.
If the author of the draft wants to reference
RFC 2821 and RFC 2822, he could make it an Informative reference instead
of a Normative reference.
It needs to be normative.
The author of MAIL-I18N mentioned that the
document should not be referenced in a modern architecture document.
Late-stage development of Section 6.3, Internationalization went through some
iterations. Reference to MAIL-I18N has now been removed.
Thanks for the diligent detail.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf