The Abstract and Introduction refer to "the first standardized
architecture for email". That would be FTP (MAIL and MLFL commands). I
believe that the quoted phrase above should be replaced by "RFC 821".
No, the first standardized architecture was the IFIP WG 6.5 effort, later,
that fed the X.400 work. There was no public, standard "architecture" work
prior to that.
Prior to that there was email *service* in a number of places -- and even
significant *private* architecture work -- but nothing that could be called a
"standardized architecture".
The UA-MTA model was derived from assessing 4 extant services, which had been
independently developed, and detecting strong similarities among their
high-level architectures.
For reference, there was no "standard" for arpanet mail content until RFC733,
in 1977. That was the word "standard" in the title of the document AND
getting formal Arpa approval to use it. (It happens that this was the first
RFC to declare itself a formal standard, and it caused quite a firestorm.)
Please note: "All RFCs are not standards".
The introduction also states "Core aspects of the service, such as address
and message style, have remained remarkably constant." In fact there have
been significant changes, ... It is incorrect to imply
that these changes haven't happened;
Saying "core aspects" leaves all sorts of room for "other", and hardly
constitutes an implication that the changes you cite have not occurred.
at minimum these changes should be
acknowledged,
The text is non-normative and is not intended to provide a history of email
development. That would be a delightful bit of text to read, no doubt, but it
is not a goal of this document.
Section 1.3 and subsequent sections use the term "bounce", which implies
non-delivery whereas the term is used to cover cases that include positive
delivery notifications as well as informational notices about delayed
transmission.
the problem with terminology, here, is matching existing practise, in
particular finding a term that people will be comfortable with. as nearly as
i can tell, 'bounce' is a common term, in spite of the fact that it also
applies to intermediate and successful delivery notices.
Figure 2 implies that a recipient can only respond to an originator if the
message passed through a mediator.
mumble. grrr. yeah.
i had hoped to avoid having each recipient have a line going back, and i did
worry about anyone drawing the implication you cite, but what the heck.
i'll make the change.
Section 2.2.3 states "A Relay may add information to the envelope, such as
with trace information. However it does not modify existing envelope
information or the message content semantics". Routes in paths (forward
and reverse) generally are modified in transit. Routes in paths are now
somewhat uncommon, but are not obsolete and should not be ignored in a
description of the mail system architecture.
what specific changes are you saying are legal for an mta to do?
please cite the rfc2821 text that authorizes it.
Section 4.6 refers to "relationship among two MSs". The relationship is
between an MS and an rMUA (simply "MUA" in the draft as written).
Synchronization between "local" and "remote" MSs occurs when they are
connected to a common rMUA.
yesthe rMUA take the actions that effect synchronization between the MSs.
however it is synchronization between the MSs that is of interest.
Section 5.5 should explicitly caution against mangling of Originator
fields (e.g. see draft-malamud-subject-line-04.txt).
You might have noticed that that section is rather short. There are all sorts
of things one might put into such a section, but I most clearly was not
intending to make the section be any kind of thorough.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net