From: Bruce Lilly (blilly@erols.com)
Date: Wed Apr 14 2004 - 19:56:55 CDT
Charles Lindsey wrote:
> It already is, because posting agents are *required* to do that, and
> followup agents are *required* to observe all the requirements of a
> posting agent.
Some clarification is warranted.
> The term "field body" (or rather "header body" in our case) is neither
> defined nor used in our draft (nor is it defined in any other document
> that I am aware of). Therefore it would require extra verbiage.
"[F]ield body" is defined in RFC 2822, section 2.2. The Usefor draft
already refers to RFC 2822 as a basis.
>>The ABNF permits single-component newsgroup-names in the Newsgroups
>>header field, i.e. it is syntactically legal.
>
>
> You take a very narrow view of the term "syntactically legal"
No, I am pointing out the fact that the ABNF does not agree with the
text of the draft. That discrepancy can and should be rectified.
>>> NOTE: There is no provision in this standard for a followup to
>>> have more than one precursor (though it might be permitted in
>>> some future extension).
>
>
>>That at least notes that there is an unresolved technical omission.
>
>
> No, it says it is not part of the protocol that we are defining.
The lack of provision is a known technical omission. If you maintain
that the text above does not acknowledge that, then please add text
which does so -- we'll need it when we come to address that omission.
> It doesn't seem to have prevented people from proposing to move RFC 2822
> further along the standards track.
RFC 2822 is a Proposed Standard. To advance beyond that stage, a
successor will have to address known technical omissions. In any event,
RFC 2822's successors' progress along the Standards Track is not our
concern.
>> While it is true that email addresses in
>>Followup-To would be a new extension, the worst that is likely to
>>happen is that some proto-article will be handed off with an email address
>>copied into Newsgroups, and the proto-article will be rejected to the
>>poster for correction.
>
>
> That is exactly the sort of extension we might be able to make in the
> future once we have established that MIME-style parameters are a feature
> of all headers. But for the moment it is a recipe for causing all sorts of
> presently working things to stop working.
No, the proposal has nothing whatsoever to do with "MIME-style parameters".
In fact, you have maintained that such parameters cannot be used with any
field whose field body might contain email addresses, so effectively you
have proved my earlier point that specifying such parameters in the syntax
is a premature constraint on possible future directions.
> How can generating a particular string possibly be "case sensitive"? There
> is no burden in writing the correct string, whatever it may be, as a
> literal in your program. The burden arises in those programs which need to
> interpret the string.
The burden is in requiring existing agents which generate "RE: " to change.
At least one such agent is among the three most widely used ones on Usenet.
> One of the greatest burdens imposed by RFC [2]822 was the requirement to
> recognize the local-part "POstMAstER" as equivalent to "postmaster" in an
> environment where every other local-part was supposed to be
> case-sensitive.
You are mistaken. Address local-parts are not defined as case-sensitive.
Whether or not a local-part other than the standardized functional names
(which date back at least as far as RFC 763) are considered case-sensitive
or case-insensitive is under the jurisdiction of the cognizant domain.