Re: Miscellaneous comments on draft-crocker-email-arch-04.txt

[Dave Crocker <[e-mail]>]

>  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