From: Pete Resnick (presnick@qualcomm.com)
Date: Tue May 20 2003 - 10:47:41 CDT
On 5/20/03 at 12:15 AM -0400, Bruce Lilly wrote:
>Pete Resnick wrote:
>>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.
I thought we were talking about syntactic statements in the text that
supplement the ABNF, providing further restrictions.
>>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.
No? I think the issue under discussion was whether it was reasonable
to have a restriction on top of the ABNF saying that there can't be
all white space followed by a CRLF after the ":" in a header field.
That sounds like exactly what I was referring to.
>>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
I see nothing in 2.1.1 which forbids comments elsewhere in address fields.
>RFC 2822 section 3.4 paragraph 3.
Which is a note saying that you SHOULD NOT use comments elsewhere in
the field if you want to avoid confusing an implementation looking
for a full name. If you are avoiding breaking INN, putting a comment
at the beginning of the field with the potential of confusing a few
implementations into displaying the wrong full name seems perfectly
legitimate. (And BTW: Please try to be consistent. This entire
argument is on the premise that we shouldn't have a restriction in
the text that is outside the ABNF, yet you use such a restriction
[though only a SHOULD NOT instead of a MUST NOT] to explain why I
can't satisfy a gatewaying requirement.)
>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?
See Russ's message.
pr
-- Pete Resnick <mailto:presnick@qualcomm.com> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102