Hi Dave,
At 08:33 15-05-2009, Dave CROCKER wrote:
The text is not normative and is providing the historical chain of
development for transfer and content specifications.
If you want to provide the historical chain of development, you'll
have to start with RFC 1341 for MIME. Mail routing is covered in RFC
974. There's also RFC 1123 which updates or annotates portions of
RFC 821 to conform to current usage (at that time). RFC 1123
discouraged all source routing and tried to abolish explicit source
routing for mail delivery.
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.
The paragraph is about the basic test of Gateway design. At the
higher level, they may be a perception that the author is "sending" a
message to the recipient. But we are not operating at that level as
the section is about gateways. The end points are the sender (in
your draft the Originator fits in there) and the recipient. We are
looking at the "connection" between these points where a change in
"addressing", for example, isn't required for the message to get through.
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.
That would have been helpful for a less technically inclined audience.
Section 4.1.4, Table 1?
Yes.
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.
We are talking about the "Message Body" here. That should not be
confused with the message content (what the recipient views and not
the raw message. My use of the word "content" may not be technically
correct). MIME structuring is not really part of the content from
the author's perspective if the author and originator are not the
same person. It's up to the originator to see that the message
conforms to Internet Mail standards (Section 2.2.1 of the draft).
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.
Your comment elicited a smile. :-) You mentioned RFC 5322, Section
3.6.7 which references RFC 5321 to explain trace fields. The draft
references RFC 2505 for trace information.
So email-arch does have an error, here, but it's the opposite of
what you note. Now fixed.
This brings us back to the document conventions used in the draft
where the first part of a structured field cites the specification
for the field. RFC 5322 has a registration for "Return-Path" in the
Permanent Message Header Field Names registry. The "Received" header
field registration references both RFC 5321 and RFC 5322.
It needs to be normative.
At the beginning of your reply, you said that the text with a
reference to RFC 2821 and RFC 2822 is not normative. In the draft
STD 10 and STD 11 are Informational references.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf