From: Bruce Lilly (blilly@erols.com)
Date: Mon May 19 2003 - 23:15:33 CDT
Pete Resnick wrote:
> On 5/16/03 at 1:59 PM -0400, Bruce Lilly wrote:
> How about the bare CR and LF rule in 2.3?
2.3 refers to message bodies, not header fields. In any event, that is
trivially handled as:
body = *(1*998text CRLF) [1*998text]
(the last part accommodates RFC 2046 multipart messages with an epilogue,
which does not necessarily end with CRLF)
> How about the table in 3.6?
That refers to the number of each type of field, which hs nothing to
do with the topic under discussion, viz. the ABNF which describes a
field's syntax.
> There are some things that are required for interoperation that are
> impossible (or at least really difficult) to put in the ABNF.
Yes, but the issue under discussion isn't one of those.
>> 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).
>
>
> Nonsense. It is perfectly easy to comply with the
> must-have-non-whitespace-content-on-initial-field-line rule in your
> example:
>
> From: (Comment to deal with broken parsers)
> =?Extended_UNIX_Code_Packed_Format_for_Japanese*cel-gaulish?q?a?=
> <a@b.com>
Sorry, no. That violates RFC 1036 section 2.1.1 and RFC 2822 section 3.4
paragraph 3.
>> 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).
>
>
> See previous answer. Compliant and doesn't affect the semantics.
Nope. *NOT* compliant.
> By definition, if there are interoperability issues in one environment
> that do not exist in the other
Exactly what interoperability issues arise in this case -- specifically
what component needs to parse From header fields and fails to do so
when the field body starts on a continuation line?
> , there are going to be messages which
> cannot be reliably transported between the two. That is the difficulty
> in being a gateway. I have yet to see an example from you where a
> gateway can't at least do a reasonable job.
See above. Which *current* gateways do "a reasonable job" on examples
such as given? Or are you talking about hypothetical gateways?
> The must-have-non-whitespace-content-on-initial-field-line rule isn't
> there for common UAs (assuming by that you mean combined UAs), so I
> don't understand why you think this argument applies to what we're
> discussing.
So I ask again; what component needs to parse From header fields and
fails to do so when the field body starts on a continuation line? If
there is no such component, then there is no need for such a blanket
rule.