On Wed March 30 2005 20:19, Dave Crocker wrote:
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?
Well, I haven't used an ASR-33 since the mid 1970's; my laptop doesn't
have a carriage and therefore doesn't need a "carriage return".
Seriously, transfer protocols dealing with text are supposed to
appropriately convert line endings. I've never had a problem with
the ftp URIs in the ID-announce messages.
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>
"Source" seems in this case to refer to a piece of software, so "it"
would seem appropriate. Failing that, your first reference suggests
recasting the sentence, and the second reference agrees with Messrs.
Strunk & White that "he" is gender-neutral in such a context.
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?
Discuss them by all means, but don't call them services or functional
components when they're not.
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 a start, a "pair" is two things... I suppose you might say that a
field is an "attribute" that might or might not have an associated
"value". But one problem with "attribute" is that it means a
characteristic of something; whereas a header field is a component of
message content rather than a characteristic. One problem with "value"
is that it implies a numerical quantity, which isn't applicable to most
header field bodies. See RFC 2822 section 3.6 for possible alternative
text.
yeah. use of the term 'header' is actually variable among the email
standards, but i did, in fact, mean to use header field.
OK, but note that the registry registers just field *names*, not the
entire field.