> My apologies for not making these comments sooner, but I have now read
> carefully through the whole draft and have encountered various nits and
> niggles. Also various things I do not understand (to which I have raised
> questions) and things which seem a little odd and might be worth thinking
> further about. Also some specific suggestions for improvement (some off
> which, I appreciate, may be hard to incorporate at this late stage). And
> also some plain bugs, which of course must be fixed.
> > Internet Message Format
> > draft-resnick-2822upd-02
> >
> >Abstract
> >
> > This document specifies a syntax for text messages that are sent
> > between computer users, within the framework of "electronic mail"
> > messages. This specification is a revision Request For Comments
> ^
> of
> > (RFC) 2822, which itself superseded Request For Comments (RFC) 822,
> >
> >1. Introduction
> >
> >1.1. Scope
> >
> > This document specifies a syntax only for text messages. In
> > particular, it makes no provision for the transmission of images,
> > audio, or other sorts of structured data in electronic mail messages.
> > There are several extensions published, such as the MIME document
> > series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
> > for the transmission of such data through electronic mail,........
> No mention of RFC 2047, or of RFC 2231?
RFC 2047 specifies a means to include non-ASCII text in email headers and has
essentially nothing to do with the transmission of structured data through
email. So why should it be mentioned in this context?
As for RFC 2231, I suppose an argument can be made that it touches on
transmission of nontext material by providing added labelling options, but it's
frankly a stretch and given 2231's lower standards status I am opposed to
mentioning it here.
> > Note: This specification is not intended to dictate the internal
> > formats used by sites, the specific message system features that
> > they are expected to support, or any of the characteristics of
> > user interface programs that create or read messages. In
> > addition, this document does not specify an encoding of the
> > characters for either transport or storage; that is, it does not
> > specify the number of bits used or how those bits are specifically
> > transferred over the wire or stored on disk.
> That last sentence seems wrong/confusing, given that the document specifies
> everything in terms of US-ASCII, presumably with the intent that US-ASCII
> should be the normal means of interchange over the 'wire' between agents (in
> the absence of explicit agreement otherwise).
What it says seems fairly clear to me: Systems exist that store things in units
other than octets, use counts rather than inline terminators, and so on and so
forth and this document isn't attempting to proscribe such behavior.
In any case, if you want the wording changed I think you'd best suggest
some alternative.
> >1.2. Notational conventions
> >
> >1.2.3. Structure of this document
> >
> > Section 4 of this document specifies an "obsolete" syntax. There are
> > references in section 3 to these obsolete syntactic elements. The
> > rules of the obsolete syntax are elements that have appeared in
> > earlier revisions of this specification or have previously been
> > widely used in Internet messages. As such, these elements MUST be
> > interpreted by parsers of messages in order to be conformant to this
> > specification. However, since items in this syntax have been
> > determined to be non-interoperable or to cause significant problems
> > for recipients of messages, they MUST NOT be generated by creators of
> > conformant messages.
> Can we be clear about the _intent_ of this obs-syntax?
> Is the intent to be able to read/display/print ancient messages which
> people still have on file? In which case, please can we say that there is
> no longer any expectation that obs messages can still be transmitted and
> delivered (by RFC2821 or otherwise), and hence only MUAs (but not MTAs)
> are REQUIRED to accept them.
> Or, alternatively, is the intent that some ancient software still
> generates messages using the obs-syntax, and hence MTAs MUST still accept
> them? In which case, for how much longer?
I see little if any justification for additional elaboration of the intent
here. As far as I'm oncerned the intent covers both your "alternatives' and
quite a few other things as well.
More generally, the problem with trying to nail down intent is that once you do
so the ability of the construct to meet other, as-yet-unplanned needs may be
compromised. See below for an example of another possible use of the obs-
syntax - helping with interop requirements - should we make our own lives
harder down the road simply because this document didn't say that one
intent of this was to make feature enumeration easier?
> Moreover, does it make sense to distinguish between obs constructs that
> were theoretically permitted by RFC822 but in practice never seen in the
> wild, as opposed to those which actually saw significant usage at one
> time? IOW what possibilities exist for the eventual removal of at least
> some of the weirder obs constructs?
The grammar is always quite complex and confusing. Adding another splitting
point would make it even more complex and confusing. Additionally, I really
don't think we need yet another round of interminable arguing over whether or
not some system that hasn't been seen or heard of in several decades did such
and such or so and so.
I will also point out that the obsolete syntax split will be very helpful if we
have to engage in a supported feature enumeration exercise as part of moving to
draft standard. As it stands all we would have to do is demonstrate that
support exists to consume this junk, not produce it. Identification of some
subset of obsolete features that are supposedly never used could easily
bring up the question of whether or not such features should be removed
completely, which I fear would unavoidably send us straight down a huge
rathole.
So, while I get your point and see some benefit to tracking the implementation
status of obsolete features (and non-obsolete ones as well), I don't believe
the benefits of doing so exceed the costs. If this is to be done it should be
done in some other document or perhaps just a web page.
(Incidentally, I suspect that any such collection exercise will, if conducted
properly, surprise you in how many of the festures you haven't seen personally
were actually used some time and some where. But that's just a guess on my
part.)
> >2. Lexical Analysis of Messages
> >
> >2.1. General Description
> >
> >
> > Note: This document specifies that messages are made up of
> > characters in the US-ASCII range of 1 through 127. There are
> > other documents, specifically the MIME document series ([RFC2045],
> > [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that
> > extend this specification to allow for values outside of that
> > range. ...
> It is likely that the extensions from the EAI WG will shortly be added to
> that list. Any possibility of a mention now?
Given that EAI is chartered to produce expermental specifications, IMO a
mention here is really not appropriate.
> >2.1.1. Line Length Limits
> >
> > There are two limits that this specification places on the number of
> > characters in a line. Each line of characters MUST be no more than
> > 998 characters, and SHOULD be no more than 78 characters, excluding
> > the CRLF.
> Can we de-emphasise that SHOULD, and make it clear that this is a matter
> of good practice (in the sense of BCP) rather than a normative feature?
That would be a significant change in normative language from RFC 2822 and
could easily be seen as requiring a reset to proposed Moreover, if memory
serves, this language went into RFC 2822 not because the WG wanted it but
rather because the IESG insisted on it.
The specific member of the IESG that insisted on it is gone now, but the
sentiment behind the requirement may live on for all I know.
Besides, I think a SHOULD is actually appropriate here. SHOULD means you should
do it unless you have a really good reason not to.
> Perhaps s/SHOULD/should/? Too many agents have used this as an excuse to
> rewrite lines en route (maybe there should be a SHOULD NOT for that).
If so, they are relying on a flagrant misreading of the document. Attempting to
prevent such exercises is itself and exercise in futility - the best you can
ever do is point out that the claim isn't supported by the actual language.
As for having a SHOULD NOT about agents altering messages in transit, IMO the
place for that - assuming it makes sense to do - would be the SMTP
specification, not here.
> Perhaps also some informative reference to 'format=flowed' might be in
> order.
That cannot be done meaningfully without also referring to MIME. While the
present layering of these specification is awkward when it comes to stuff like
this, I think having all sorts of informational cross references would confuse
as much as it clarifies.
> > The more conservative 78 character recommendation is to accommodate
> > the many implementations of user interfaces that display these
> > messages which may truncate, or disastrously wrap, the display of
> > more than 78 characters per line, in spite of the fact that such
> > implementations are non-conformant to the intent of this
> > specification (and that of [I-D.klensin-rfc2821bis] if they actually
> Where did that '78' come from? I am aware of lots of systems that do
> horrid things such as you mention if there are 80 characters in a line,
> but I am aware of none where problems arise with exactly 79. In other fora
> where I have seen this discussed, the consensus was that exceeding '79'
> was the signal for troubles to start.
I've always felt that the 78 character limit was one byte lower than it really
needed to be. But I a long way from convinced that now is the time to change
this.
> >2.2. Header Fields
> >
> >2.2.3. Long Header Fields
> >
> > The process of moving from this folded multiple-line representation
> > of a header field to its single line representation is called
> > "unfolding". Unfolding is accomplished by simply removing any CRLF
> > that is immediately followed by WSP. Each header field should be
> > treated in its unfolded form for further syntactic and semantic
> ^^^^^^^^^
> > evaluation.
> 'Semantic' yes, but why is that 'syntactic' there?
Don't you have to parse things like address fields in order to then perform
semantic analysis? Syntactic not only seems appropriate, IMO it would be an
error not to have it.
> >2.3. Body
> >
> > o Lines of characters in the body MUST be limited to 998 characters,
> > and SHOULD be limited to 78 characters, excluding the CRLF.
> Again, that 'SHOULD' is a matter of BCP.
Same argument as before.
> >3. Syntax
> >
> >
> >3.2. Lexical Tokens
> >
> > Note: Readers of this specification need to pay special attention
> > to how these lexical tokens are used in both the lower-level and
> > higher-level syntax later in the document. Particularly, the
> > white space tokens and the comment tokens defined in section 3.2.3
> > get used in the lower-level tokens defined here, and those lower-
> > level tokens are in turn used as parts of the higher-level tokens
> > defined later. Therefore, the white space and comments may be
> > allowed in the higher-level tokens even though they may not
> > explicitly appear in a particular definition.
> All of which can be _exceedingly_ confusing. There was much discussion on
> this list about 12 months ago about an alternative syntactic improvement
> suggested by Bruce Lily, and I thought we had reached a consensus then to
> bring it in. It is possible, even at this late stage, to do so?
I agree with that it is confusing. Howevver, I did not find Bruce's alternative
helped matters all that much. Nor do I recall any strong consensus to bring it
in. In fact what I recall is almost exactly the opposite: That since we're
attempting to move to draft now we would make every effort to keep the changes
to the absolute minimum. A wholesale change to the grammar doesn't even come
close to meeting that goal.
> >3.2.2. Quoted characters
> >
> >
> > Note: The "\" character may appear in a message where it is not
> > part of a quoted-pair. A "\" character that does not appear in a
> > quoted-pair is not semantically invisible. The only places in
> > this specification where quoted-pair currently appears are
> > ccontent, qcontent, dcontent, no-fold-quote, and no-fold-literal.
> We have already noted that no-fold-quote, and no-fold-literal can go. But,
> as I have pointed out in a separate thread, you would remove a severe
> interoperability problem with Netnews if you removed it from <dcontent> as
> well (allowing just a "\" to appear as a normal character).
As I believe I stated in an earler response, I am opposed to removing it. It is
simply not possible to know everything that's out there and just because we
don't know about something is no excuse to break it. I could live with moving
it to the obsolete syntax but that's as far as I'll go.
> >3.2.3. Folding white space and comments
> >
> > Strings of characters enclosed in parentheses are considered comments
> > so long as they do not appear within a "quoted-string", as defined in
> > section 3.2.5. Comments may nest.
> That is not strictly correct, as a "\)" may appear in a <comment> without
> closing the comment.
But that's a literal, no an enclosing parentheses. I really don't think making
the text explicit about this case will clarify things, but again, if you have
text to suggest...
> >ctext = NO-WS-CTL / ; Non white space controls
> > ;
> > %d33-39 / ; The rest of the US-ASCII
> > %d42-91 / ; characters not including "(",
> > %d93-126 ; ")", or "\"
> Do you _really_ want to permit NO-WS-CTL in a <comment>?
RFC 2822 did, so the question becomes one of do we want to change
this away from what 2822 said?
Like it or not, control characters have long been allowed in a lot of places
where they really don't belong. I remain to be convinced that this one
narrow case is worth worrying about.
> > Throughout this specification, where FWS (the folding white space
> > token) appears, it indicates a place where folding, as discussed in
> > section 2.2.3, may take place. Wherever folding appears in a message
> > (that is, a header field body containing a CRLF followed by any WSP),
> > unfolding (removal of the CRLF) is performed before any further
> > lexical analysis is performed on that header field according to this
> > specification. That is to say, any CRLF that appears in FWS is
> > semantically "invisible."
> Eh? That seems to be confusing "lexical analysis" with "semantic
> analysis". If it had said "before any semantic analysis is performed" I
> would have understood it.
I agree - "semantic" would better here.
> >3.2.5. Quoted strings
> > qtext = NO-WS-CTL / ; Non white space controls
> > ;
> > %d33 / ; The rest of the US-ASCII
> > %d35-91 / ; characters not including "\"
> > %d93-126 ; or the quote character
> Again, do you really want to permit NO-WS-CTL in a <quoted-string>?
Same response.
> >3.2.6. Miscellaneous tokens
> >
> > Three additional tokens are defined, word and phrase for combinations
> > of atoms and/or quoted-strings, and unstructured for use in
> > unstructured header fields and in some places within structured
> > header fields.
> >
> > word = atom / quoted-string
> >
> > phrase = 1*word / obs-phrase
> >
> > utext = NO-WS-CTL / ; Non white space controls
> > %d33-126 ; The rest of US-ASCII
> >
> > unstructured = (*([FWS] utext) *WSP) / obs-unstruct
> <phrase>s, <unstructured>s and <comment>s are the places where RFC 2047
> raises its ugly head. It is the most confusingly written RFC I have
> encountered (and it could be considered as separate from the rest of
> the MIME standards, since it can be used without the MIME-Version header).
> For a truly outrageous suggestion, we might incorporate the whole of RFC
> 2047 into here, cleaning it up in the process. No, that is too much to
> propose at this juncture, but there are a couple of lesser things we might
> do to help:
> 1. Include <encoded-word> in the syntax at all the proper places (which
> might at least encourage inventors of new extension headers to follow
> suit). It would need a convincing explanation, of course.
I am strongly opopsed to this. If RFC 2047 is confusing, the time to argue that
is when it is revised. We cannot fix it's problems (assuming there actually are
any to fix) by incorporating some subset of references to it in another
document.
> 2. And if that is a step too far, we could still point out that sequences
> of the form "=? ... ? ... ? ... ?=" have a special significance within RFC
> 2047 (whether they exceed that 76 character limit or not), and that such
> sequences SHOULD NOT be used within <phrase>s, <unstructured>s and
> <comment>s unless that special significance is intended.
An informational reference to RFC 2047 would be OK with me.
> >3.3. Date and Time Specification
> > A date-time specification MUST be semantically valid. That is, the
> > day-of-week (if included) MUST be the day implied by the date, the
> > numeric day-of-month MUST be between 1 and the number of days allowed
> > for the specified month (in the specified year), the time-of-day MUST
> > be in the range 00:00:00 through 23:59:60 (the number of seconds
> > allowing for a leap second; see [RFC1305]), and the zone MUST be
> > within the range -9959 through +9959.
> why not "within the range -2359 through +2359"?
I have no objection to restricting the range, but whatever we do needs to agree
with other specifications that deal in time zones. RFC 3339 appears to allow
-2459 through +2459.
> >3.4. Address Specification
> > When it is desirable to treat several mailboxes as a single unit
> > (i.e., in a distribution list), the group construct can be used.
> > ...
> > Because the list of mailboxes can be empty, using the group construct
> > is also a simple way to communicate to recipients that the message
> > was sent to one or more named sets of recipients, without actually
> > providing the individual mailbox address for each of those
> > recipients.
> s/each of/any of/ or s/each of/some of/
Agreed.
> >3.4.1. Addr-spec specification
> >
> > An addr-spec is a specific Internet identifier that contains a
> > locally interpreted string followed by the at-sign character ("@",
> > ASCII value 64) followed by an Internet domain. The locally
> > interpreted string is either a quoted-string or a dot-atom. If the
> > string can be represented as a dot-atom (that is, it contains no
> > characters other than atext characters or "." surrounded by atext
> > characters), then the dot-atom form SHOULD be used and the quoted-
> > string form SHOULD NOT be used. Comments and folding white space
> > SHOULD NOT be used around the "@" in the addr-spec. A liberal syntax
> > for the domain portion of addr-spec is given here; it is left to
> > other specifications (e.g., [RFC1034], [RFC1035], [RFC1123],
> > [I-D.klensin-rfc2821bis]) to give more precise limitations on the
> > syntax.
> Can we strengthen that by saying that the 'liberal syntax' MUST be further
> restricted to conform to some published specification such as the ones you
> have listed (without precluding further such specifications in the future,
> of course)?
No, because that would usurp the perogative of other specifications to
specify what conformances criteria apply to their additional restrictions.
More generally, it strikes me as a really bad idea to have a MUST for which
compliance can only be determined by consulting an incomplete and open-ended
series of other specifications. This in effect would make it impossible to be
able to claim you have a compliant implementation since you cannot possibly
know when another specfication would be added to this list.
> >dcontent = dtext / quoted-pair
> >
> >dtext = NO-WS-CTL / ; Non white space controls
> > ;
> > %d33-90 / ; The rest of the US-ASCII
> > %d94-126 ; characters not including "[",
> > ; "]", or "\"
> I have already pointed out, in a separate thread, the severe
> interoperability problems with Netnews of this definition of <dcontent>
> (at least insofar as its use within <msg-id> is concerned). The
> troublesome items are <quoted-pair>, NO-WS-CTL, SP and ">" (though "\" in
> dtext would be OK). My suggestion for restricting the 'liberal syntax'
> above was also directed at mitigating this problem.
And IMO you failed to achieve sufficient support to result in a specification
change. As I said previously, I can live with making the use of quoted-pairs in
dtext part of the obsolete syntax, but that's as far as I can see us going.
The alternative approach I actually favor is one I have previously described:
Add some text that says that domain literals in message ids should be generated
using the most restrictive syntax and with well-defined semantics, i.e. an IPv4
or IPv6 literal. To mind the bigger problem here is that someone will generate
something like [foobar] here instead of putting in an actual global IPv4 or
IPv6 address. If we encourage people to use domain literals with defined
semantics we solve several problems at one go.
> > .... In both cases, how addressing is
> > used and how messages are transported to a particular host is covered
> > in [I-D.klensin-rfc2821bis]. These mechanisms are outside of the
> > scope of this document.
> There may be other transport mechanisms than I-D.klensin-rfc2821bis. So it
> would be better to say "is covered in separate documents such as
> [I-D.klensin-rfc2821bis]".
I don't feel strongly about this either way.
> >3.5. Overall message syntax
> >
> > A message consists of header fields, optionally followed by a message
> > body. Lines in a message MUST be a maximum of 998 characters
> > excluding the CRLF, but it is RECOMMENDED that lines be limited to 78
> > characters excluding the CRLF. ...
> Again, that is a matter of BCP. "recommended" would be quite strong
> enough.
Again, such recommendaations are what SHOULDs and RECOMMENDED are for and I'm
opposed to making such a change at this point.
> >3.6. Field definitions
> >
> > The header fields of a message are defined here. All header fields
> > have the same general syntactic structure: A field name, followed by
> > a colon, followed by the field body. The specific syntax for each
> > header field is defined in the subsequent sections.
> I have already pointed out, in a separate thread, the severe
> interoperability problem that arises with Netnews if you do not require a
> SP after the colon. Since every MUA I am aware of routinely inserts that
> SP, I cannot see that anything would be lost by requiring it here.
And as I commented previously, not everything that has an submissiion client in
it is an MUA. There are quick and dirty submission clients embedded in all
sorts of places - one of the advantages of SMTP is that you can code a quick
and dirty client very easily - and leaving out every possible character is
exactly the sort of things these gizmos do. Heck, they even do it when they've
actually got plenty of space to space - unnecessary optimization is RAMPANT in
the embedded systems world.
I am therefore strongly opposed to disenfranchising such systems.
> > | | | | |
> > | keywords | 0 | unlimited | |
> > | | | | |
> Why is Keywords unlimited (in Netnews it is 1)? It is no big deal since
> this field is so seldom used. But its presumed intended use of indexing
> collections of email messages using this field would be simplified if only
> one occurrence was allowed (the obs syntax would still allow multiple
> occurrences, of course, and wording similar to that in 4.5.3 could be
> used).
I could live with such a change, but OTOH I'm not sure I see much point in
making it. The same set of arguments that it doesn't have an impact also make a
case for leaving it alone.
> >3.6.2. Originator fields
> > The originator fields indicate the mailbox(es) of the source of the
> > message. The "From:" field specifies the author(s) of the message,
> > that is, the mailbox(es) of the person(s) or system(s) responsible
> > for the writing of the message....
> Are those sentences intended to be normative, BCP (or even deliberately
> vague :-) ).
Don't see any capitalized words there, do you? So I guess there are
no compliance implications.
> For example, some people 'munge' their From: addresses in order to appear
> anonymous, or to confuse address harvesters. Whether that is a desirable
> practice or not is none of our business, but a normative interpretation of
> those words would seem to rule it out. I might well agree that it is not
> BCP, but it happens.
> The wording currently proposed by the USEFOR WG for this is:
> Contrary to [RFC2822], which implies that the mailbox or mailboxes in
> the From header field should be that of the poster or posters, a
> poster who does not, for whatever reason, wish to use his own mailbox
> MAY use any mailbox ending in the top level domain ".invalid"
> [RFC2606].
> But if RFC2822 does not actually imply that, then we might have to think
> again.
And IMO it should not imply that. The last thing email needs at this point is
more license to use invalid addresses.
> Or maybe this issue really belongs under Security Considerations?
> > In all cases, the "From:" field SHOULD NOT contain any mailbox that
> > does not belong to the author(s) of the message. See also section
> > 3.6.3 for more information on forming the destination addresses for a
> > reply.
> Hmmm! That has a distinctly normative feel to it :-( .
There are capitalized words there so it isn't just a feeling. And IMO those
words are, if anything, too weak.
> >3.6.3. Destination address fields
> >
> > The destination fields specify the recipients of the message. Each
> > destination field may have one or more addresses, and each of the
> > addresses indicate the intended recipients of the message. The only
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> indicates an intended recipient
Seems reasonable.
> > difference between the three fields is how each is used.
> >3.6.4. Identification fields
> >
> > The "Message-ID:" field contains a single unique message identifier.
> > The "References:" and "In-Reply-To:" field each contain one or more
> > unique message identifiers, optionally separated by CFWS.
> ^^^^^^^^^^
> Interoperability with Netnews would be improved without that "optionally".
Perhaps, but like it or not Netnews compatibility is not our primary goal here.
> AFAICS all current MUAs routinely include some WSP there (probably
> because they are following the lead of RFC 1036).
At one point I actually had to change our parser to handle the case where there
was no space there, so I'm fairly sure that not everything out there inserts
the spaces.
> > no-fold-literal = "[" *dcontent "]"
> As already mentioned, the present definition of dcontent causes severe
> interoperability problems with Netnews.
Yes, and your repetition of the point without further concrete arguments in
favor or making the change is if anything weakening your case, not
strengthening it.
> > The "In-Reply-To:" and "References:" fields are used when creating a
> > reply to a message. ..., while the
> > "References:" field may be used to identify a "thread" of
> ^^^^^^
> is often
> > conversation.
> >
> > The "References:" field will contain the contents of the parent's
> > "References:" field (if any) followed by the contents of the parent's
> > "Message-ID:" field (if any). If the parent message does not contain
> > a "References:" field but does have an "In-Reply-To:" field
> > containing a single message identifier, then the "References:" field
> > will contain the contents of the parent's "In-Reply-To:" field
> > followed by the contents of the parent's "Message-ID:" field (if
> > any). If the parent has none of the "References:", "In-Reply-To:",
> > or "Message-ID:" fields, then the new message will have no
> > "References:" field.
> It would be useful to mention that when the References field gets too long
> it MAY be pruned (the minimum requirement being to retain the first and
> the last two entries - including the one just being added). I have known
> of cases where References fields grew to such a length (and MUAs in the
> followup chain had failed to introduce folding, or even removed folding
> already present) that the 998 limit was breached with disastrous
> consequences.
Adding such a suggestion would be fine with me were it not for the context of
this effort - every such change increases the likelihood of a problem getting
to draft.
> > The message identifier (msg-id) itself MUST be a globally unique
> > identifier for a message. ...
> It would be useful to say here that two msg-ids can always be compared for
> equality by a simple octet-by-octet comparison (but, of course, one would
> first have to ensure that property was true).
But that's exactly the problem, isn't it? The property is NOT guaranteed
at the present time.
> > ..... Since the msg-id has
> > a similar syntax to addr-spec (identical except that comments and
> > folding white space are not allowed), a good method ...
> ^
> and quoted-strings
> (as already noted)
Seems OK to make this change.
> >3.6.5. Informational fields
> >
> > The informational fields are all optional. The "Subject:" and
> > "Comments:" fields are unstructured fields as defined in section
> > 2.2.1, and therefore may contain text or folding white space. The
> > "Keywords:" field contains a comma-separated list of one or more
> > words or quoted-strings.
> That last sentence is redundant, because a <word> cam already be a
> <quoted-string>.
The problem is that it isn't clear whether this refers to the generic idea of a
word or the specific ABNF production for word. So, while it may be somewhat
redundant, I thknk it is actually clearer the way it is.
> > subject = "Subject:" unstructured CRLF
> >
> > comments = "Comments:" unstructured CRLF
> >
> > keywords = "Keywords:" phrase *("," phrase) CRLF
> Why did Organization get left out? It is a defined field within Netnews,
> but it is also already widely used within Email.
Organzation was not defined in either RFC 822 or RFC 2822. According the IANA
registry it is only defined in Netnews, but regardless of other places it is
defined not is absolutely not the time to be adding it to the 822 family of
specifications.
> > .... When used in a reply, the field body MAY start with the
> > string "Re: " (from the Latin "res", in the matter of) followed by
> > the contents of the "Subject:" field body of the original message.
> If we are going to discuss Latin Grammar, then please let us to so
> correctly. "Res" is the nominative form of the fifth declension noun
> meaning "thing", "matter", "issue", etc. "Re" is an abbreviation of the
> phrase "in re" meaning "in the matter of", and in which "re" is the
> ablative form of the same noun (the preposition "in" is always followed by
> an ablative in static cases such as this, though it takes the accusative
> form - e.g. "in rem" - in dynamic cases where the meaning is "into").
> so if, instead of
> the string "Re: " (from the Latin "res", in the matter of)
> you write
> the string "Re: " (an abbreviation of the Latin "in re", meaning "in
> the matter of")
> all will be correct.
Yep, now that I think about it you're correct. This is a reasonable change.
Alternately, the whole thing about the Latin could be omitted.
> > .... The
> > "Keywords:" field contains a comma-separated list of important words
> > and phrases that might be useful for the recipient.
> Actually, its main intent was to be picked up by search engines and the
> like (agreed, the search engine might belong to the recipient).
Um, not hardly. The definition and use of keywords in email dates back to the
mid 70s, long before storage was cheap enough to waste on compiling indices of
interpersonal or even list mail. At that point the intent really was to aid the
recipient in classifying messages, nothing more and nothing less.
In any case, since "useful to the recipient" seems to cover search engines as
well as countless other uses, I really don't see much need for additional
elaboration here.
> >3.6.6. Resent fields
> >
> > When resent fields are used, the "Resent-From:" and "Resent-Date:"
> > fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.
> > "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
> > identical to "Resent-From:".
> Why the SHOULD for Resent-Message-ID? What evil befalls if it is omitted?
I'm not a big fan of how resent- has been handled in more recent
specifications, but in this particular case I think the intent is obvious: the
message is in some sense "new" to the transport system so having a new id is a
good idea. It's not like there's an id shortage...
> >3.6.7. Trace fields
> >
> > The trace fields are a group of header fields consisting of an
> > optional "Return-Path:" field, and one or more "Received:" fields.
> > The "Return-Path:" header field contains a pair of angle brackets
> > that enclose an optional addr-spec. The "Received:" field contains a
> > (possibly empty) list of tokens followed by a semicolon and a date-
> > time specification. Each token must be a word, angle-addr, addr-
> > spec, or a domain. Further restrictions are applied to the syntax of
> > the trace fields by specifications that provide for their use, such
> > as [I-D.klensin-rfc2821bis].
> Can be find a better word instead of "token" here? "Token" usually means
> some sort of keyword (e.g. as used in the MIME standards). "Item" or
> "sub-field" are possible alternatives.
I would prefer item as well. But I don't feel strongly about it.
> >3.6.8. Optional fields
> >
> > Fields may appear in messages that are otherwise unspecified in this
> > document. They MUST conform to the syntax of an optional-field.
> > This is a field name, made up of the printable US-ASCII characters
> > except SP and colon, followed by a colon, followed by any text which
> > conforms to unstructured.
> >
> > The field names of any optional-field MUST NOT be identical to any
> > field name specified elsewhere in this document.
> >
> > optional-field = field-name ":" unstructured CRLF
> >
> > field-name = 1*ftext
> >
> > ftext = %d33-57 / ; Any character except
> > %d59-126 ; controls, SP, and
> > ; ":".
> >
> > For the purposes of this specification, any optional field is
> > uninterpreted.
> This is misleading, because it has to cover all new header fields
> introduced by extensions and these will be, in general, structured. For
> example, does the use of <unstructured> here imply that RFC 2047 may be
> used freely on any header field not defined by this document - clearly
> 2047 was not intended to imply that, but it would not be hard to read it
> that way. Better to invent some new term <foobar> with the same syntax as
> <unstructured>, and then to say in that last sentence that any internal
> structure of a <foobar> has to be defined elsewhere.
> >4. Obsolete Syntax
> >
> > Earlier versions of this specification allowed for different (usually
> > more liberal) syntax than is allowed in this version. Also, there
> > have been syntactic elements used in messages on the Internet whose
> > interpretation have never been documented. Though some of these
> ^^^^^^^^^^^^^^ ^^^^
> interpretations Eh? I thought none of them
> was to be generated.
These both seems like good changes to make to me.
> > syntactic forms MUST NOT be generated according to the grammar in
> > section 3, they MUST be accepted and parsed by a conformant receiver.
> which begs the question "what is a 'receiver'?" See earlier discussion.
I think this is reasonably clear and I don't see much value in trying to get
into defining the overall email architecture here. We have another document for
that.
> > .... This
> > allowed many complex forms that have proven difficult for some
> > implementations to parse.
> Which sounds like a good reason for no longer requiring agents to parse
> them :-( .
Perhaps if this case had been made effectively six years ago. Now is not the
time.
> >4.1. Miscellaneous obsolete tokens
> >
> > Note: The "period" (or "full stop") character (".") in obs-phrase
> > is not a form that was allowed in earlier versions of this or any
> > other specification. Period (nor any other character from
> > specials) was not allowed in phrase because it introduced a
> > parsing difficulty distinguishing between phrases and portions of
> > an addr-spec (see section 4.4). It appears here because the
> > period character is currently used in many messages in the
> > display-name portion of addresses, especially for initials in
> > names, and therefore must be interpreted properly. In the future,
> > period may appear in the regular syntax of phrase.
> But this is not an "obsolete" construct. We discussed this around 12
> months ago, and the consensus then was that it ought to be renamed as an
> <extended-phrase>, and moved out of the Obsolete Syntax.
I don't recall the discussion, but even if that was the consensus at the time
we were unaware of the constraints of this revision exercise. I am therefore
opposed to making this change at this point.
> Observe also that threat that it might one day be promoted to the regular
> syntax. Are we ready yet to implement that threat? Probably not, but its
> day will surely come. But it needs to be said in a more conspicuous place,
> not hidden away in a section with "obsolete" in its name.
I agree with the overall sentiment but now is not the time...
> Likewise for <obs-phrase-list), wich is only used in <obs-keywords>. But
> do we really care whether or not you are allowed to write
> Keywords: Joe Q. Public ?
> >
> >
> >obs-qp = "\" (%d0-127)
> >
> >obs-body = *((*LF *CR *(obs-text *LF *CR)) / CRLF)
> >
> >obs-text = %d0-9 / %d11-12 / ; %d0-127 except CR and
> > %d14-127 ; LF
> >
> >obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
> >
> >obs-utext = %d0-8 / %d11-12 / ; %d0-127 except CR, LF,
> > %d14-31 / %d33-127 ; and white space
> The syntax given for these obs-constructs includes also the syntax for
> their regular counterparts, which makes it very hard work to discover
> exactly where the difference lies because of the huge redundancy that is
> introduced. For example, if you had written
> obs-qp = "\" %d0
> nothing would have changed, but it would be immediately obvious what the
> difference was. Most of the obs-syntax could be re-written in such a
> non-redundant manner, though I grant you there are a few cases which would
> be difficult.
The argument about fixing really obscure issues once again applies.
> >4.3. Obsolete Date and Time
> >
> > The syntax for the obsolete date format allows a 2 digit year in the
> > date field and allows for a list of alphabetic time zone
> > specifications that were used in earlier versions of this
> > specification. It also permits comments and folding white space
> > between many of the tokens.
> >
> > obs-day-of-week = [CFWS] day-name [CFWS]
> >
> > obs-year = [CFWS] 2*DIGIT [CFWS]
> >
> > obs-day = [CFWS] 1*2DIGIT [CFWS]
> >
> > obs-hour = [CFWS] 2DIGIT [CFWS]
> >
> > obs-minute = [CFWS] 2DIGIT [CFWS]
> >
> > obs-second = [CFWS] 2DIGIT [CFWS]
> >
> > obs-zone = (( "+" / "-" ) [CFWS] 4DIGIT) /
> ..............
> This lot was particularly difficult to spot the differences. I believe
> that in <obs-hour> the first [CFWS] is unnecessary,
Yes, it appears to be because the trailing [CFWS] in obs-year takes
care of it. I'm not sure that it is worth eliminating, however - it
is entirely possible I've missed something.
> and the [CFWS] at the
> end of <obs-second> might be better moved to the start of <obs-zone>,
> since that reflects better the way FWS is treated in the regular syntax.
Again, seems reasonable, but a bit late in the game to make such changes.
> >4.4. Obsolete Addressing
> >
> > There are three primary differences in addressing. First, mailbox
> > addresses were allowed to have a route portion before the addr-spec
> > when enclosed in "<" and ">". The route is simply a comma-separated
> > list of domain names, each preceded by "@", and the list terminated
> > by a colon. Second, CFWS were allowed between the period-separated
> > elements of local-part and domain (i.e., dot-atom was not used). In
> > addition, local-part is allowed to contain quoted-string in addition
> ^^ ^^^^^^^^^^^
> was
> > to just atom. Finally, ....
> ^^^^^^^^^^^^
> in lieu of any of those period-separated atoms
Agreed.
> >5. Security Considerations
> >
> > Care needs to be taken when displaying messages on a terminal or
> > terminal emulator. Powerful terminals may act on escape sequences
> > and other combinations of ASCII control characters with a variety of
> > consequences. They can remap the keyboard or permit other
> > modifications to the terminal which could lead to denial of service
> > or even damaged data. They can trigger (sometimes programmable)
> > answerback messages which can allow a message to cause commands to be
> > issued on the recipient's behalf. They can also affect the operation
> > of terminal attached devices such as printers. Message viewers may
> > wish to strip potentially dangerous terminal escape sequences from
> > the message prior to display. However, other escape sequences appear
> > in messages for useful purposes (cf. [ISO.2022.1994], [RFC2045],
> > [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) and therefore
> > should not be stripped indiscriminately.
> Eh? what "other escape sequences" do you have in mind? I am not aware of
> any meaningful use of NO-WS-CTLs in any of those standards. OTOH, if that
> list is correct, should RFC 2231 be added to it?
You appear to have NO-WS-CTLs on the brain. This section is pretty clearly
focused on control characters in body text, not headers. And since MIME allows
the use of alternate charsets, some of which make extensive use of ISO 2022
escape sequences, the point about not stripping them indecriminantly seems
especially well taken. Indeed, if memory serves, it is not all that uncommon to
find Asian text in one of these charsets that's been damaged by control
character removal, so much so fixup utilities exist to try and correct such
damage.
> > Many implementations use the "Bcc:" (blind carbon copy) field
> > described in section 3.6.3 to facilitate sending messages to
> > recipients without revealing the addresses of one or more of the
> > addressees to the other recipients. Mishandling this use of "Bcc:"
> > may disclose confidential information which could eventually lead to
> > security problems through knowledge of even the existence of a
> > particular mail address. For example, if using the first method
> > described in section 3.6.3, where the "Bcc:" line is removed from the
> > message, blind recipients have no explicit indication that they have
> > been sent a blind copy, except insofar as their address does not
> > appear in the message header section. Because of this, one of the
> > blind addressees could potentially send a reply to all of the shown
> > recipients and accidentally reveal that the message went to the blind
> > recipient. When the second method from section 3.6.3 is used, the
> > blind recipient's address appears in the "Bcc:" field of a separate
> > copy of the message. If the "Bcc:" field sent contains all of the
> > blind addressees, all of the "Bcc:" recipients will be seen by each
> > "Bcc:" recipient. Even if a separate message is sent to each "Bcc:"
> > recipient with only the individual's address, implementations still
> > need to be careful to process replies to the message as per section
> > 3.6.3 so as not to accidentally reveal the blind recipient to other
> > recipients.
> But how could such revelation be avoided? Surely, if a blind recipient
> replies to any message, his identity will be given away by the From header
> of the reply? I see nothing in 3.6.3 that helps with this problem.
In the case of reply-to-all, sure. But the case this appears to be addressing
is when the reply is being sent to the originator only. The originator
presumably knows who he or she bcc'ed so nothing is directly revealed by doing
this. However, if the reply manages to promote a bcc address to a Cc or To
field, a reply to that reply could easily reveal the original blind carbon
action.
More generally, it just seems like a good idea to try and keep bcc and other
reipient addresses separate when possible.
> >6. IANA Considerations
> >
> > This document has no actions for IANA.
> Oh yes it does!
> RFC 3864 requires IANA to maintain a registry of header fields within
> Email, News and HTTP. Anybody who defines a header field is obliged to
> provide a template for use in that registry.
> In the case of RFC 2822, Graham Klyne wrote a set of templates in RFC
> 4021. But these all reference RFC 2822 as the relevant specification
> document, and so will become outdated as soon as 2822bis appears. On top
> of that, they are all (IMHO) unnecessarily verbose.
> So you need to write a full set of revised templates in here. I suggest
> you look at draft-ietf-usefor-usefor-12 for how we laid out those
> templates for USEFOR (carefullly avoiding such verbosities :-) ).
I'm very much afraid that you are correct about this. I see little choice but
to include such templates in this revision. I'd really rather not if there
was a way out, but I just don't see one.
> >Appendix A. Example messages
> >
> > Messages are delimited in this section between lines of "----". The
> > "----" lines are not part of the message itself.
> That is indeed an excellent notation. The Bad News is that you have
> nowhere used it :-( .
Yes, and so this sentence would best be removed.
> >Appendix A.1.2. Different types of mailboxes
> >
> > This message includes multiple addresses in the destination fields
> > and also uses several different forms of addresses.
> >
> > From: "Joe Q. Public" <[email protected]>
> > To: Mary Smith <[email protected]>, [email protected], Who? <[email protected]>
> > Cc: <[email protected]>, "Giant; \"Big\" Box" <[email protected]>
> > Date: Tue, 1 Jul 2003 10:52:37 +0200
> > Message-ID: <[email protected]>
> >
> > Hi everyone.
> >
> > Note that the display names for Joe Q. Public and Giant; "Big" Box
> > needed to be enclosed in double-quotes because the former contains
> > the period and the latter contains both semicolon and double-quote
> > characters (the double-quote characters appearing as quoted-pair
> > construct). ...
> ^^^^^^^^^
> constructs
Agreed.
> >Appendix A.1.3. Group addresses
> >
> > From: Pete <[email protected]>
> > To: A Group:Chris Jones <[email protected]>,[email protected],John <[email protected]>;
> > Cc: Undisclosed recipients:;
> > Date: Thu, 13 Feb 1969 23:32:54 -0330
> > Message-ID: <[email protected]>
> >
> > Testing.
> >
> > In this message, the "To:" field has a single group recipient named A
> ^
> "
> > Group which contains 3 addresses, and a "Cc:" field with an empty
> ^
> "
> > group recipient named Undisclosed recipients.
> Wouldn't it be better to show a Bcc: header for the "Undisclosed
> recipients" example?
Not necesarily - it depends on what's intended, and the document is silent on
that. A cc: field with "undisclosed recipients: ;" is intended to convey the
fact that there are other recipients to everyone who gets the message. Putting
this in a bcc field, which often as not is only included in some message copies
but not others, could be intended to convey that informaation to only a subset
of the recipients. Or it could have have gone to everyone. There's no way
to tell.
> >Appendix A.4. Messages with trace fields
> >
> > As messages are sent through the transport system as described in
> > [I-D.klensin-rfc2821bis], trace fields are prepended to the message.
> > The following is an example of what those trace fields might look
> > like. Note that there is some folding white space in the first one
> ^^^^^^^
> folded
> > since these lines can be long.
No, this is a term of art, not a description of what's there.
> >Appendix A.5. White space, comments, and other oddities
> >
> > White space, including folding white space, and comments can be
> > inserted between many of the tokens of fields. Taking the example
> > from A.1.3, white space and comments can be inserted into all of the
> > fields.
> >
> >From: Pete(A wonderful \) chap) <pete(his account)@silly.test(his host)>
> >To:A Group(Some people)
> > :Chris Jones <c@(Chris's host.)public.example>,
> > [email protected],
> > John <[email protected]> (my dear friend); (the end of the group)
> >Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ;
> >Date: Thu,
> > 13
> > Feb
> > 1969
> > 23:32
> > -0330 (Newfoundland Time)
> >Message-ID: <[email protected]>
> >
> >Testing.
> >
> > The above example is aesthetically displeasing, but perfectly legal.
> Though legal, you should point out that it contains things that are
> deprecated by 3.3 and by 3.4.1, and that agents might well choke on them.
I don't oppose it but OTOH I can't get excited about repeating the warning in
this context.
> >7. References
> >
> >7.2. Informative References
> >
> > [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
> > USENET messages", RFC 1036, December 1987.
> RFC 1036 is not actually referenced anywhere in the document. Moreover, if
> you DO have a need to reference it (please do :-) ) then you ought to
> refer to draft-ietf-usefor-usefor-12 instead.
The RFC Editor will yank any orphaned (Or is it widowed? Who cares?) references
so this really isn't worth worrying about. If we want to do soemthing about it,
let's remove it entirely.
Ned
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.