From: Bruce Lilly (blilly@erols.com)
Date: Fri May 16 2003 - 12:59:55 CDT
Pete Resnick wrote:
> On 5/16/03 at 11:54 AM -0400, Bruce Lilly wrote:
>
>> Assuming that "mailbox-list" refers to the 2822 production (it's not in
>> the list of imported productions in sect. 2.4), that most certainly does
>> not incorporate the
>> must-have-non-whitespace-content-on-initial-field-line
>> rule since mailbox-list provides for line folding at its start.
>
>
> Ummmm....RFC 2822, third paragraph of 3.2.3, specifically contradicts
> the ABNF. You have a problem with that? If not, then why do you have a
> problem with this document adding an additional (and similar)
> restriction on the syntax?
I think the contradiction in 2822 is unfortunate, but it's a substantially
lesser problem than the issue w.r.t. the Lindsey draft for several reasons:
1. While the 2822 issue affects a single production (viz. FWS) and in
a very specific instance (a specific case of a continuation line),
the discrepancies in the Lindsey draft are numerous and affect the
ABNF for every header field (and presumably MIME-part header fields
as well).
2. It is possible to comply with the 2822 restriction without violating
MIME or other standards' restrictions, in every case. That is not the
case with the must-have-non-whitespace-content-on-initial-field-line
rule, as demonstrated by the example containing a long encoded-word
(which must conform to the RFC 2047 line-length limit rule).
3. A message containing the proscribed construct (essentially an "empty"
continuation line) can be easily transformed into a compliant message
simply and without affecting semantics (simply by eliding the line in
question). That is not the case for the Lindsey draft restriction.
(item #2 above affects message generators, this item (#3) affects
gateways and other message-processing entities).
4. 2822 is the common text message format standards (track) document.
It provides a single ABNF for From (and other) header fields. The
Lindsey draft claims compatibility with 2822, but is in fact
incompatible to varying degrees in a large number of ways (item #2
above being one of the more serious issues, making it impossible in
some circumstances to generate a compliant message).
5. There exist such things as common UAs (these are nearly ubiquitous
and include Netscape Communicator, Mozilla, MS Outlook/Outlook Express,
Pine, etc.) and which are affected by such additional (i.e. not in
the common message format) restrictions. This is a corollary of item #2;
such UAs may find it impossible to cope with the restrictions when
generating a message (which may be a followup).
6. Common UAs on the receiving end of messages must be able to parse and
cope with full RFC [2]822 syntax in any event. So the restriction does
nothing for them w.r.t. message parsing and display. This is the flip
side of the coin in items #2/#5; while the restriction imposes
(insurmountable!) difficulties w.r.t. message generation, there is no
corresponding benefit.
7. There are common messaging protocols (e.g. IMAP) which may be affected
by the differences. In this specific case, there may be no cause for
concern -- but that depends on where the restriction in the draft is
supposed to be enforced. Surely it's impractical to require enforcement
of idiosyncratic restrictions in all messaging UAs (see #5 above), some
of which have been working fine for decades. This may be a moot issue
in this case anyway -- item #2 is the real killer; if one cannot generate
a compliant message because of a specific restriction, it doesn't matter
where the restriction is enforced -- all bets are off.
8. 2822 has provision (via obs-FWS) which is documented (2822 section 4.2,
including ABNF) requiring conforming parsers to be able to accept that
which section 3.2.3 forbids generation of. The Lindsey draft has no
such provision, nor documentation, for an acceptance requirement for
conforming parsers which may encounter a field with (RFC 822-legal,
2822-legal, 2047-mandated) initial non-WS field body content appearing
on a continuation line, such as may be generated by an 822/2822/MIME-
compliant message generator.
Those are the obvious ones, just off the top of my head. There may be others.
[Pete, I've addressed most of these issues in off-list email to you dated
May 5, message ID <3EB6D577.4050303@Sonietta.blilly.com>, in a similar
context. Let me know if you didn't receive it, as I can resend it.]