From: Bruce Lilly (blilly@erols.com)
Date: Thu Apr 01 2004 - 20:19:00 CST
Charles Lindsey wrote:
> In <40661463.8000103@erols.com> Bruce Lilly <blilly@erols.com> writes:
>
>
>>Charles Lindsey wrote:
>>
>>>I have changed "taken" to "copied", if that makes you any happier. I see
>>>no need for "verbatim", since that is the normal meaning of "copied" in
>>>the absence of any other qualification. No, there are no transformations.
>>>Why should you suppose that there would be?
>
>
>>"possibly preceded by [...] 'Re: '" certainly is a transformation.
>
>
> Yes, but we were dicussing transformation in the "taking" (now "copying")
> phase.
And I answered your question "[w]hy should you suppose...". Note
that I have not suggested that there should be any transformation, but
that the text should be clear about what takes place.
>>Changes to line folding, comments (in structured fields), charsets,
>>languages, encoding algorithms in encoded-words (where allowed) etc.
>>either should be explicitly allowed (as transformations) or
>>explicitly prohibited.
>
>
> Those are all issues to be considered by the agent when it come to post
> the article after the user has done any editing he fancies upon the
> default headers copied from the precursor. At that point, it is just
> behaving as a posting agent. But some comment on the matter might be
> appropriate in USEAGE.
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. Of course, in the case of no
modification, there is little reason to require the followup agent to
perform such checks prior to handing the field to the user for editing.
>>When using "copied" in the context of taking
>>*field body* content from one field and using it as the *field body*
>>content of another field, we should be clear that that is what is meant,
>>since the field name is different. Else one is likely to see
>> Newsgroups: Followup-To: foo.example
>>etc. from naive implementations.
>
>
> 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.
>>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. 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...
>>You have introduced the topic, which has been part of this WG discussion.
>>Any proposed wording for the next revision of the draft should either
>>address it or note clearly that it is a known technical omission.
>
>
> Introducing the topic does not suddenly cause it to become a feature of
> Netnews. But I note that RFC 2822 contains wording to indicate that it is
> an unresolved issue. So I have written, after the first paragraph of 8.6:
>
> 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.
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.
>>>>Nor has
>>>>the relationship between Followup-To and Mail-Copies-To been addressed,
>>>>either for a followup to a single message, or for a followup to multiple
>>>>messages.
>
>
>
>>That still falls short of complete clarity, and is still unnecessary;
>>we could easily combine email address(es) into Followup-To (eliminating
>>Mail-Copies-To) since every email address contains '@', which can never
>>appear in a newsgroup name and does not appear in "poster".
>
>
> 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. 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.
>>>>> 2. The content of the Subject-header SHOULD by default be taken from
>>>>> that of the precursor's Subject-header, possibly preceded by the
>>>>> back-reference "Re: " (case sensitive), unless it already begins
>>>>> with such a "Re: ".
>
>
>>"the back-reference 'Re: '" implies that all occurrences of "Re: " are
>>"back-references", and that is not true.
>
>
> That is not what it says
It certainly is, with the conventional change of quoted double-quotes
to single quotes.
> so it cannot be what it implies. However, the
> intention is that it is to be permitted to prepend the string "Re: " only
> where that string was not already present.
That is different wording, which does not imply that "Re: " is always
a "back-reference".
> The term "back-reference" is not in widespread use, being invented only
> for the purposes of this draft, and the only place where it is used is
> here in 8.6 (apart from one mention in 5.4). However, it is still handy to
> have it, and it will be (is) useful in USEAGE. So here is a slightly
> changed wording:
>
> 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".
>>>I am not aware that Russ has noted any such thing (indeed, he explicitly
>>>said he had no problem with including an explanation of its Latin origin).
>
>
>>Then you have apparently ignored what he said in <87y8pvgury.fsf@windlord.stanford.edu>:
>
>
>>"Yes. "Re" isn't Latin. That entire line of discussion is inherently
>>absurd. It's derived from a Latin term, but it's used in both Usenet and
>>e-mail as an arbitrary label, not as a Latin word."
>
>
> And I note that he said that in response to your ridiculous assertion that
> anything not in upper case could not possibly be in Latin.
No, you have that backwards; if it is intended to be Latin, it should
be all upper-case (because Latin had no lower case).
> The main point of mentioning it in that NOTE is to make it clear that it
> is language-neutral, at least insofar as European languages are concerned
Something alleged to be in a particular language cannot be said to be
"language-neutral"! That is contradictory. Moreover, European languages
include German (and languages derived from German, e.g. English) which
has a separate lineage from Latin.
>>>But, in any case, that wording is in a NOTE and is not normative. It
>>>serves to explain to the reader the origin of the usage.
>
>
>>That might be useful in a non-normative practices document, but is
>>out of place in a Proposed Standard, whether for syntax/semantics or
>>network operations.
>
>
> Then why does RFC 2822 mention it (modulo a small error in Latin
> grammar)?
Ask RFC 2822's editor. I'm discussing issues with this draft here,
suggestions for changes to RFC 2822 belong elsewhere.
>>>The only reason it is made case sensitive here is that much existing
>>>software treats it as such. One might regret that, but it is so.
>
>
>>Not all existing software treats it as such, indeed I suspect that most
>>existing software treats it as case-insensitive. Moreover, one of the
>>three most widely used followup agents generates "RE: " (N.B. all
>>upper-case
>
>
> It you want to start a separate discussion as to whether you want to allow
> "Re: " to be case insensitive, then please do so, and the WG can consider
> it. It is a side issue so far as the present issue is concerned. My
> understanding is that many, if not most, agents treat it as case
> sensitive. Since you seem primarily concerned with deprecating the
> practice entirely (and even I would be happy to see it phased out), I
> cannot understand why you should also want to inflict an additional burden
> on existing agents to treat it case insensitively.
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.