ietf-smtp
[Top] [All Lists]

Re: Editorial/typographical/grammatical/punctuation/usage/formatting/charset/simple comments on draft-crocker-email-arch-04.txt

2005-03-30 18:19:19

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