From: Bruce Lilly (blilly@erols.com)
Date: Wed May 21 2003 - 10:40:13 CDT
Pete Resnick wrote:
> On 5/20/03 at 12:15 AM -0400, Bruce Lilly wrote:
> I thought we were talking about syntactic statements in the text that
> supplement the ABNF, providing further restrictions.
We were talking about a specific provision, not incorporated in the
ABNF, regarding field structure and which leads to conflicts with
requirements in other standards. If you'd like to widen the discussion
to other areas which are problematic in the Lindsey draft, fine, but
let's please stick to this one issue in this thread -- we can't solve
all the world's problems, but we do need to produce a consistent, well-
engineered document.
>>> 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.
That's not impossible (nor really difficult -- not even moderately
difficult) to put in the ABNF. It's already been done and posted to
this mailing list for the Subject field (along with other issues
related to that particular field). It does mean that syntax for
every field differs from that given in 2822 and other relevant RFCs
(2045, 1864, 2156, 2424, 3282, etc.)
>>> 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-822 specifies that all text in parentheses is to be interpreted
as a comment. It is common in Internet mail to place the full name
of the user in a comment at the end of the "From" line. This
^^^^^^^^^^^^^
standard specifies a more rigid syntax. The full name is not
considered a comment, but an optional part of the header line.
Either the full name is omitted, or it appears in parentheses after
^^^^^
the electronic address of the person posting the message, or it
appears before an electronic address which is enclosed in angle
brackets. Thus, the three permissible forms are:
From: mark@cbosgd.ATT.COM
From: mark@cbosgd.ATT.COM (Mark Horton)
From: Mark Horton <mark@cbosgd.ATT.COM>
The original example was the third permitted type, i.e. a phrase followed by
and RFC 822 route-addr (angle-addr in 2822-ese). A comment before the
mailbox is not one of the permitted forms; one might expect
From: (Mark Horton) mark@cbosgd.ATT.COM
or even
From: (Mark Horton) Mark Horton <mark@cbosgd.ATT.COM>
to have been allowed, but apparently some software botches parsing of
address fields with a comment before the mailbox. And that's not unrelated
to the 2822 SHOULD NOT recommendation.
>> 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.
Yes, see above w.r.t. comments before the mailbox.
> 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.
Well, let's agree that it moves the breakage to a different piece
of software. But there's still breakage.
> (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.)
I've never claimed (either here or elsewhere) that RFC 2822 is
completely wart-free. Quite the contrary. That is not to say that
the restrictions *could not* be part of the ABNF -- the generate
grammar could provide for FWS, with CFWS relegated to the obs- syntax
(which compliant parser would still be required to accept). Yes,
my premise is that the ABNF and normative text should be as consistent
as possible in our documents. That other documents might not live up
to that standard is not an inconsistency on my part; it's a shortcoming
of those other documents (which are outside of the control of this WG).
And this isn't *just* a gatewaying requirement. It affects article
generation also; Charles says that a posting agent must enforce the
must-have-non-whitespace-content-on-first-line rule.
>> 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.
Obviously I have, since I replied to his questions about SMTP. Russ
stated that he considers that aspect of INN to be broken. I agree;
there's no *need* for INN to parse From fields -- Path, Newsgroups,
Distribution, Message-ID, Control, Approved yes, possibly a few
others as well, but there's nothing in the From field that's relevant
to news transport.
The basic issue with the specific requirement under discussion is the
conflict with other relevant standards. If the MUST is reduced to
SHOULD, there's a means for resolving the conflict -- the RFC 2047
hard limit on line length for lines containing encoded-words overrides
a SHOULD have-non-whitespace-content-on-first-field-line recommendation.
A side issue is getting all of the related MUSTs, SHOULDs, MUST NOTs,
and SHOULD NOTs logically consistent w.r.t. each requirement or
recommendation. Charles writes:
> 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
If it's an absolute requirement for non-whitespace content on the first
field line, then a field w/o non-whitespace content on the first line will
never arise, and a SHOULD accept is pointless. OTOH, if the
non-whitespace-content-on-first-field-line is a SHOULD (strong recommendation),
then the SHOULD accept seems reasonable (although it could be argued that
that should be a MUST accept).
If the non-whitespace-content-on-first-field-line is changed to a strong
recommendation (i.e. SHOULD rather than MUST) and parsing is changed to
MUST accept, then there's no need to incorporate the recommendation into
the ABNF. Even if parsing remains as SHOULD accept, I'll concede that
the ABNF need not have the syntax corresponding to SHOULD have non-whitespace
content recommendation. [that still leaves the issue of space-after-colon,
which differs from RFC 2822 to be dealt with in the ABNF, unless of course
that also is changed to SHOULD rather than MUST].
This is what I meant by my earlier comment that moving to compatibility
with RFC 2822 (and other relevant RFCs) sooner rather than later means
less work in preparing our documents -- MUST provisions related to syntax
should be consistent with the ABNF, and those that impose syntax that
differs from the other standards will require different ABNF to adequately
document the requirements.