From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Fri Apr 02 2004 - 09:37:43 CST
In <406CCD94.4040102@erols.com> Bruce Lilly <blilly@erols.com> writes:
>If a followup agent inserts 4 characters at the beginning of a Subject
>field which contains an encoded-word on the first line, causing the
>length of that line to exceed the maximum allowed for a line containing
>an encoded-word, then that followup agent should bear responsibility
>for re-folding the field to comply with the relevant requirements;
>the user shouldn't have to deal with that (in any event, he is unlikely
>to recognize the problem, since encoded-words are likely to be displayed
>in decoded form), and there may still be old injection agents or those
>which do not conform to the requirements imposed on injection agents
>by the draft, and those will not necessarily fix the problem even if
>the user makes no changes to what the followup agent supplies. In the
>case cited (followup agent makes some transformation), the followup
>agent should probably be *required* to ensure that the modified field
>complies with all relevant standards....
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.
>> You have a strange idea of "likely", especially as that header is
>> syntactically incorrect. You are asking for a lot of extra verbiage to
>> prevent what would be totally bizarre misreadings of the text.
>No, I am not "asking for a lot of extra verbiage"; I am asking that
>a field body be called a field body, period.
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.
>>>That doesn't address the case (which you most recently introduced) of
>>>a followup to multiple messages. Nor is there an explicit provision
>>>for rejection of a proto-article containing "poster" along with newsgroup
>>>names, nor is there any provision for excluding "poster" as a newsgroup
>>>name or newsgroup name component.
>>
>>
>> "poster" is forbidden as a newsgroup-name in 5.5.1. As a component, it
>> would be allowed.
>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" I suppose
you are going to tell me next that it is "syntactically legal" for an
encoded word to exceed 75 characters?
> Injection agents
>are required to reject proto-articles with syntactically illegal
>content, but that doesn't apply since the syntax is legal. Now
>that could be fixed by defining the Newsgroup field body content
>differently...
No, I have fixed it by removing the word "syntactically" from 8.2.2
Step 4.
>> 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.
>Presence of which does not preclude the draft becoming a Proposed
>Standard, but will prevent it from progressing along the Standards
>Track until the issue is resolved. IOW, we're going to have to
>address the issue sooner or later.
It doesn't seem to have prevented people from proposing to move RFC 2822
further along the standards track.
>> We are constrained by existing usage in both the Followup-To and
>> Mail-Copies-To headers. I hear no serious proposal to change that.
>I have made such a proposal. Mail-Copies-To is introduced in the draft,
>so is not a constraint.
Mail-Copies-To is in widespread current use, so it is a considerable
constraint.
> 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.
Does anyone else support Bruce's proposal? If so, let us take it to a
separate thread.
>> 2. The content of the Subject-header SHOULD by default be copied
>> from that of the precursor's Subject-header, possibly preceded
>> by the case sensitive string "Re: " (known as a "back-
>> reference") unless it already begins with that string.
>>
>> Clearer?
>Equally clear and equally objectionable, for the same reason; it implies
>that "Re: " is always a "back-reference".
No, it says that a certain "string" may be prepended in a certain
situation. It also defines the term "back reference" to mean "the string
'Re: ' that is sometimes prepended to a Subject header by a followup
agent", and that meaning is quite sufficient for all other usages of that
term in the draft (including where it says that any other string is
unlikely to be recognized as fitting the description).
>You have that backwards also; I am objecting to imposing an additional
>burden on existing agents by requiring them to treat it as case-sensitive
>when generating it.
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.
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.
-- 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