From: Bruce Lilly (blilly@erols.com)
Date: Fri Apr 02 2004 - 06:37:54 CST
Henry Spencer wrote:
> On Thu, 1 Apr 2004, John Stanley wrote:
>>In which RFC regarding news is "Re: " defined to mean something?
>
>
> All the RFCs -- severely obsoletely though they both are -- regarding news
> article format specifically call for this sequence to be prepended to the
> Subject contents (unless overridden by the user) when preparing a
> followup.
Calling for a sequence to be perpended and defining a meaning are two
different things. Moreover, both RFCs specifically and clearly indicate
that in the event of a conflict, RFC 822 -- from which the Subject
field was adopted in preference to the older news "Title" field, and in
which the Subject field is clearly defined as unstructured -- takes
precedence.
> Although they do not discuss their motives for doing so, the
> obvious inference is that its presence will be meaningful to the human
> reader and thus (possibly) to his software agent.
What *you* infer might be obvious to *you*, but it is by no means
unambiguous or certain that that is what was intended. It remains
*your* inference, not a definition in the RFCs.
> The RFCs whose drafts we are working on at this moment could similarly
> define it so (preferably more explicitly and with more explanation), or
> could refrain from doing this. In neither case is there an inconsistency.
In the former case, there would be a conflict with the RFC in which
the field is defined, viz. RFC 2822. That would be inconsistent with
both news RFCs (neither of which *defines* any meaning to "Re: ") as both
use RFC 822s definition of the field, viz. unstructured. In the latter
case, there need be no inconsistency. There are also other alternatives,
e.g. abandoning Subject in news and returning to Title, which can be
defined with whatever structure we decide upon.
> But it is the height of obstructionism to claim that they cannot do so
> because no other RFC has done so, when *all* the news RFCs in fact have,
> and when it is our decision whether to follow their lead or not.
John has made no such claim -- he asked a question (and you have
sidestepped that question). And your claim that two Informational
RFCs have defined something which they in fact have not defined is
spurious, as is your claim that this WG has authority to redefine a
field which comes under the auspices of a different WG, causing one
or more Standards Track RFCs to conflict with other Standards Track
RFCs. We have no such authority, just as we have no authority to
redefine the MIME-Version field.
>>Since the Subject header is not defined to carry such information in a
>>netnews environment...
>
>
> I'm actually inclined to agree with this, but only because you phrased it
> that exact way. The netnews Subject header, in the past, has not been
> defined clearly enough to say whether it carries such information -- i.e.,
> it is *not defined to* carry such information.
So here at the bottom, after presenting your inference about a different
question as fact about definitions, you get around to answering John's
question -- and the answer is that no RFC defines "Re: " to have any
meaning, your earlier self-inconsistent claims to the contrary
notwithstanding. And the Subject field *has* been clearly defined -- the
definition is in RFC 822; both RFCs 850 and 1036 clearly say so, going to
great lengths to affirm that in the event of any conflict, RFC 822 has
the definitive word.
> It is our job to define it. One way or the other.
No, we can do what RFC 850 did when it adopted use of fields defined in
the Internet Message Format, using such fields as they are defined by
the cognizant WG and its RFCs, or we can define extension fields consistent
with the Internet Message Format, or we can abandon use of the Internet
Message Format (and combined news/mail UAs, and access via IMAP), defining
an incompatible format which will make gateways more difficult and error-
prone than they already are. We cannot redefine an unstructured field
not under our control as a field with structure.