From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Mon May 19 2003 - 05:49:29 CDT
In <3EC5271B.7070809@Sonietta.blilly.com> Bruce Lilly <blilly@erols.com> writes:
>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:
>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).
But it has been explained to you by others on this list that your counter
example was so contrived as to be irrelevant to our discussions. People
are just not going to invent charsets or languages of that length. And if
the problem you have raised is a serious one, as you maintain, then please
show me how to cope with a From line containing the following (strict RFC
2822, please)?
=?Extended_UNIX_Code_Packed_Format_for_Japanese_with_Chinese_extensions*cel-gaulish?q?a?=
>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).
Anything acceptable according to our current draft (it is not the "Lindsey
draft", it is the current product of this WG) is aceptable to RFC 2822.
Item #2 is not "one of the more serious issues". It is in fact a Red
Herring.
>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).
A common UA will have to generate stuff within the intersection of RFC
2822 and USEFOR (that is the meaning of "common"). I doubt that is a
serious difficulty, because I believe they already do.
>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.
The particular restrictions we are discussing are intended to deal with
broken agents that might do unfortunate things with these cases. Sadly,
broken agents are a fact of life that Usenet has learned to live with over
the years. They are not going to go away. The draft is clear that it is
the posting agent that is REQUIRED to enforce this particular one. It also
says that all other agents SHOULD accept this case (which is rather easy
for them to do - they simply do not test for it).
>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.
The current USEFOR draft (not the "Lindsey draft") has "MAY accept" for
all the obs-syntax (we did not want to force every pure News agent to have
to accept syntax that has never ever appeared in Netnews) and "SHOULD
accept" for missing SP after the ':' and for empty content on the first
line.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5