[Top] [All Lists]

Re: draft-crocker-email-arch-03

2005-02-19 20:10:59

On Sat, 19 Feb 2005 15:32:01 -0000, Willemien wrote:
  In your idea users and MUA's are outside (and not part of) the
  Mailhandling system.

  For users I agree fully with that, but for MUA's I am wondering.

  In my opinion MUA's are part of the mailhandling system.

As the document describes, the purpose of distinguishing MUAs from the Mail 
Handling Service is to separate user services from transfer services.  The MHS 
only concerns transfer.  The MUA is not part of the transfer service.

  Some motivation for this:

  - (practical) They supply the MIME encapsulation of the message.

MIME is not relevant to the transfer service.

  - (philosophical) They do not have a function outside the mailhandling
  system. (without an mailhandling system there is no use for a MUA)

This is like saying that an automobile is part of the street/highway system, 
because autos do not have a function without streets and highways.

The purpose of an architecture is to show *relationships* between components.  
It is not possible to do that if all the pieces are treated as part of the same 

  I want to elaborate the last point because it come back more often. (and
  than I only have to point to this point)
  I would use the term User only as entities outside the mail system.

"user" does.  "MUA" does not.  MUA is defined to be the mail system component 
that represents a user.

  "End-to-end" should mean from user to user, from keyboard to screen or
  something similar.

As the document observes, the term is used differently.  It is not possible to 
declare a single meaning for it, because community practise is already 
established.  All that is possible is to be clear about a particular use of the 

  1.1 service overview

  Small point: what is an email object? there is no description of it.

good catch.  i've changed it to 'message'.

  Instant messaging systems also fit in the description.

generally, yes it does.  for the architecture document, the baseline 
definitions come from rfc2821 and rfc2822, so it's clear this does not apply to 

  Section 2

  Figure 2: Relationships Among User Actors

  What is the meaning of the lines from recipient to mediator ?

a Recipient can generate a reply, either to an original Originator or to a 

  The line from recipient to originator seems to represent a message delivery

well, that's one kind of return message.

  Figure 3: Relationships Among MHS Actors

  Notice should be Notifications Handler

Too much text, so I shortened it.  But, yes, I need to tie them together 


  2.2.4 gateways

  Gateways are NOT users

I think you are confusing the concept of human users with the concept of 
user-level activity in a computer system.  There are many email "users" that 
are not human, with the document citing edi, fax and voicemail as examples.  A 
gateway is a user-level activity, for the reasons cited in the document.

Ultimately, there are many ways to describe a complex service, and each can 
make sense.  So what is important is not that everyone agree that this is THE 
way to describe service, but that it is A way to describe it and that the 
community generally finds that way to be helpful.

  3.3 Message Identifiers
  Not conform RFC 2822 section 3.6.4
  (the right side is not always a domain)

Well, this is interesting.  I believe the intent of rfc2822 is to characterize 
the id-right field as either a domain name or an ip address.  But it appears 
that it does not say that.

In actual practise, the right hand side should be a domain name.  So I'm going 
to keep the current text, until there is some consensus among the rf2822 
community about alternate language.

  Users do not assign this identifier.
  It may be assigned by the MUA but it is hidden from the user.

it MAY be hidden.  it is not required that it be hidden.

  4.1 Message

  Delivery Status Notification (DSN):
  in figure 5 MSA receives the DSNmessages in the text it send them. (and
  where it is supposed to send them to?)

How the MSA handles DSN's is a local matter.

  4.2 Mail User Agent (MUA)

  RFC2822.From and
  fields are set by the oMUA not by the originator.

oMUA is a protocols and services construct.

Originator is a user-level actor construct.

The "set by" entries use actor references.

  4.4 Mail Transfer Agent

  Missing is that there are MTA's that only forward to specified MTA's
  using MX records at all.

As I've noted a few times, there are many variations that are legal and are 
done.  This document is not trying to describe every possible scenario, merely 
those that are most common and use standardized techniques.

  Or maybe this is a primal distinction between MTA's and MSA's
  I am getting more and more confused an email client that sends al its mail
  by SMTP to the ISP's mailserver is that:
  a an MUA
  b an MUA-MSA
  c an MUA-MSA-MTA
  d something else

b or c, depending upon the operational configuration of the ISP.

  4.6 Message Store (MS)

  I would like to put a new suggestion in for this and the bottompart of
  figure 5

I do not know what "end of SMTP" means.  SMTP is a hop-by-hop protocol.  So, 
each link that references SMTP is an "end of SMTP".

  I came to this because the old MS always must be local to the MDA while the
  rMS mostly is local to the rMUA.
  And I liked the idea of a MRA agent.

Please elaborate.  I am not understanding.

  New functional components
  sMS   Smtp final message store

I do not know what this means.

  MRA   message retrieval agent

The Message Store is generally viewed as a static entity.  However it is 
accessed using protocols, so I believe the MS serves the MRA job that you are 

  rMS   receiver message store

Apparently you are suggesting alternate terms for MS-1 and MS-2?

  rUser receiver of the message (see comments about figure 5 earlier)
  5 mediators

  I see differences between User mediators and Non-user mediators. (see for a
  discussion about users the beginning of this comment)

I tend to see your suggestion as adding complexity and confuses styles of use 
with different categories of underlying functionality.  The distinctions you 
draw are reasonable, I think, but they do not seem to add utility.

Absent strong feedback from others, I'll keep the current text.

Dave Crocker
Brandenburg InternetWorking
dcrocker  a t ...

<Prev in Thread] Current Thread [Next in Thread>