On Tue March 29 2005 11:23, Dave Crocker wrote:
Until the draft is issued through the Internet Drafts process, it can be
accessed at:
<http://bbiw.net/current.html#email>
The server either does not recognize the "text" version as text or
fails to honor text transfer protocols; I retrieved a document which,
unlike I-Ds retrieved from the official process, contained thousands
of spurious control characters (0x0D).
Anyway, here are some comments that do not delve into complex
substantive issues. I expect to comment on such issues in a series
of separate messages.
"SMTP" in the first page heading should be "Network Working Group"
(see RFC 2223).
The document uses out-of-date boilerplate; refer to RFCs 3978/3979.
The Abstract (and Section 1 from which it was apparently extracted)
contains "marked by many independent operators, many different
components for providing users service and many others for performing
message transfer" which is somewhat awkward. I suggest "... providing
service to users and many other components for ...".
Section 1.3 says "Disp" which isn't a word and which appears nowhere
in the text. It appears as a label in a box in one figure. Surely there
is room for a more descriptive label.
Section 1.3 also states that "Administrative Domain" was changed to
"Administrative Unit", however section 2.2.1 appears not to have been
updated.
Section 2.2.1 also says: "Hence, Source is best held accountable for the
message content, even when they did not create any or most of it". That
appears to have disagreement in number between "source" and "they" (see
Strunk & White re. usage of "their").
Given the fact that section 2.2.3 mentions store-and-forward, changing
"(re)-transmits" to "forwards" would clarify the operation.
Section 3.1 refers to and speaks of "conventions", but the section
heading instead says "Standards". I suggest changing "Standards" in the
heading to "Conventions".
In section 3.2 and many subsequent sections, "Address" in "IP Address"
is unnecessarily capitalized.
Section 4 purports to describe "functional components" under the
heading "Services". The first bullet item is "Message", which is
neither a service nor a *functional* component, i.e. a message doesn't
"do", it just "is".
Figure 5 contains the line
. | +---- -------------------+ |
which appears to have a typographical error (gap in horizontal line).
Description of MDN states "indicating that the message has been read",
which is not quite correct. Changing "read" to "presented" would fix
the problem.
Following that MDN description under the heading "Messages" and
following the introductory line "Internet Mail has distinguished some
special versions of messages, for exchanging control information:" is
a subsection headed "Message Filtering (SIEVE)". Sieve is not a
message at all, much less a special version of a message.
Section 4.1.2 describes header fields as "attribute/value pairs",
which is technically incorrect (they are named fields). For example,
the Bcc field may have no field body (a.k.a. "value"); likewise for
all unstructured fields (Subject, Comments, Content-Disposition, etc.).
The header fields Incomplete-Copy, Generate-Delivery-Report, and
Prevent-Nondelivery-Report are required to have no field body (RFC
2156).
The same section also destroys consistency of technical term usage by
using "registering headers" where it should say "registering header
field names".
Section 4.1.3 refers to RFC 2048, which is the MIME media type
registration procedure, which is unrelated to the Internet mail
architecture (it's a registration procedure!). RFC 2048 is about to
be superseded (draft-freed-media-type-reg-02.txt is in Last Call).
RFC 2048 can probably be dropped from the architecture draft text and
references.
The word "or" in the last line of section 4.2 should be "of".
The third paragraph of section 4.3 says "it operates on a separate TCP
port, and will typically impose". That should be "it may operate on a
separate TCP port and may impose". And I would add that a client oMUA
cannot reliably distinguish an MSA server from an MTA server.
The same section states:
RFC2821.HELO or RFC2821.EHLO
Set by: Source
The MSA may specify its hosting domain identity for the SMTP HELO
or EHLO command operation.
1. several subsequent sections mention only "RFC2821.HELO" but not EHLO.
2. while an MSA does indeed set HELO/EHLO domain when operating as an
SMTP client, the oMUA sets the HELO/EHLO domain when communicating to
the MSA when the latter is acting as a server.
Section 4.4, third paragraph, second line has a superfluous comma after
"host". Same section, fourth paragraph, first line has superfluous
commas before and after "over the open Internet" and after
"prearrangement" and "participants".
The comma after "mechanism" in the second paragraph of section 4.5
should be replaced by a colon.
Commas in the first two lines of the last paragraph beginning at the
bottom of page 27 are superfluous.
The apostrophe in "it's" (meaning a contraction for "it is") is
incorrect near the top of page 28 (use "its").
The section 5.3 discussion of "RFC2919.List-id" [capitalization sic]
states "Although [RFC2919] is a standards-track specification, it has
not gained significant adoption." I note that the (ahem) ietf-smtp
list (to name but one example) uses the List-ID field. I doubt the
wisdom of making such value judgments in a document intended to be
long-lived, and I suggest eliding that sentence.
The last paragraph of section 5.3 contains a conflict in number between
"fields" and "it" (change "it" to "them").
RFC 2298 has been obsoleted by RFC 3798 (see the "rfc-ref.txt" file
made available by the RFC Editor at
ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt
).
"Acknowledgements" (Appendix A) is usually spelled "Acknowledgments" in
RFCs (and by many spelling checkers).