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
activity.
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"
"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
term.
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
IM.
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
Mediator.
The line from recipient to originator seems to represent a message delivery
notification.
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
explicitly.
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
RFC2822.Reply-To
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
without
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
describing.
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net