[Top] [All Lists]

Initial comments on draft-croker-email-arch

2004-09-09 07:48:40

Some comments, in the same order as the draft text:

In section 1.1. "intermingled" would probably be more accurate than

Section 1.2 encourages review of tables.  Table 4.1.4 refers to actor
"h", which is nowhere defined.

Section 1.2 also discusses MDA/MS/MUA and requests review of the model.
Several terms used in the model (discussed separately below) probably
need revision, and gateways (of various types) aren't shown at all.

And section 1.2 mentions message identifiers, but nowhere are the
message header fields that use message identifiers -- Message-ID,
Resent-Message-ID, Original-Message-ID, In-Reply-To, References,
Supersedes, and Delivery-Report-Content-Original -- discussed!
Indeed, only a tiny fraction of standardized message header fields
are mentioned at all.

Section 4 omits presentation and discussion of gateways. I can think
of several types of gateways:
1. gateways between different transport methods (using different
   transport addressing), where the message content is identical,
   e.g. between SMTP and UUCP (some mention in RFC 976)
2. gateways between mail systems where transport, addressing, and
   message format all differ, but the basic function (interpersonal
   electronic correspondence) is the same. E.g. between Internet
   mail and X.400 (MIXER series of RFCs), between Internet mail
   and proprietary vendor-specific systems
3. gateways between systems that use essentially the same message
   format and transport, but between separate functional entities;
   typically a separate end-to-end function using the Internet
   message format and infrastructure. E.g. voice messaging (VPIM),
   fax, printing
4. gateways implementing end-to-end functionality layered on top of
   Internet mail (this is distinguished from the case immediately
   above; whereas in the above case the interaction with the user
   is typically *not* via a MUA except in particular implementations,
   this case typically *does* use a MUA). E.g. EDI (RFC 3335).
5. list expansion is typically a gateway function
6. message processing for security by MTAs or MDAs which are acting
   as gateways. E.g. virus scanning.  See RFC 1344 vs. CERT Vulnerability
   Note #VU836088 (
7. gateways between systems that use essentially the same message
   format but different modes of distribution and addressing. E.g.
   between mail and Usenet.

Note that the message store (4.1.5), particularly type MS-1, is
correctly identified as a *message* store (and not a "mail" store);
IMAP (Internet Message Access Protocol) in particular is capable of
accessing messages in the message store regardless of how they may
have arrived at that store (Usenet, SMTP, ...).

Section 5.2 refers to "message headers". Some messages do in fact
have multiple headers; the message header and one or more MIME-part
headers. Section 5.2 refers to "headers" where it means message
header fields. Use of "headers" in lieu of "header fields" may
lead to confusion and/or misinterpretation.

Sections 6.2.4, 6.2.5, and 6.2.6 should probably be renamed; gateways
(in general), alias expanders (in particular), and mailing list
expanders (in particular) are not typically MUA functions. They
tend to be MTA or MDA functions.

Section 6.2.6 refers to mailing list "address", which should be
"mailbox" (a single mailing list is typically not accessed via
a named group, which contains a list of mailboxes and is the
difference between "mailbox" and "address" (RFC 2822)).

<Prev in Thread] Current Thread [Next in Thread>
  • Initial comments on draft-croker-email-arch, Bruce Lilly <=