Bruce,
Thanks for the details. Just the sort of careful proof-reading the document
needs.
Comments, below, when there is an issue:
<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).
1. It works fine with Internet Explorer and with Firefox.
2. OD is carriage-return. The newline sequence is OD-OA (CR-LF). What do you
believe is the problem with having carriage-returns in a document?
Feel free to provide more detail, especially if anyone else is experiencing
problems.
"SMTP" in the first page heading should be "Network Working Group" (see
RFC 2223).
The document is produced by xml2rfc and I try to use it carefully. It is
popular enough and behaves well enough that I am not likely to try to change
such things, particularly when I think they are helpful.
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").
See the "Gender Neutral" section, at <http://dcrocker.net>
Given the fact that section 2.2.3 mentions store-and-forward, changing
"(re)-transmits" to "forwards" would clarify the operation.
except that forward, by itself, is at best ambiguous, given its uses for
discussion of mediators.
In section 3.2 and many subsequent sections, "Address" in "IP Address" is
unnecessarily capitalized.
It's quite intentional. The multiaddressing work has made the term "address"
generally problematic to use, particularly on its own. The preferred terms
are locator and identifier. Hence, using the word "address" makes sense only
when it is part of a formal term. That's why I capitalized it.
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".
You think that a discussion of functional components may not, also, discuss
the objects used by and for those components?
Section 4.1.2 describes header fields as "attribute/value pairs", which is
technically incorrect (they are named fields).
not sure what you think an attr/val pair is, if not that.
For example, the Bcc field
may have no field body (a.k.a. "value");
null value.
The same section also destroys consistency of technical term usage by
using "registering headers" where it should say "registering header field
names".
yeah. use of the term 'header' is actually variable among the email
standards, but i did, in fact, mean to use header field.
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 IETF does not provide a very representative sampling basis for
generalizing global Internet practise. That said, however, I agree that a
document like this should be very wary (or vary wery) of such text.
"Acknowledgements" (Appendix A) is usually spelled "Acknowledgments" in
RFCs (and by many spelling checkers).
I believe this issue received plenty of it's own discussion, today.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net