Re: Re: Re: Pqx9: In the matter of: Subject-header and "Re: "

From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Thu Jun 19 2003 - 05:57:54 CDT


In <3EF05A7D.8010603@Sonietta.blilly.com> Bruce Lilly <blilly@erols.com> writes:

>You appear to (continue to) be talking about UAs munging the
>subject field body for the purpose of sorting for display, which
>is not an interoperability issue, and does not warrant use of
>MUST or MUST NOT.

Nobody is talking about "munging" the Subject field in a UA. We are only
talking about a common practice amongst user agents of ignoring a (single)
"Re: " when performing certain operations. That "munges" nothing.

> There simply is no issue w.r.t. "Re: " that
>warrants use of such wording; if some transport software does
>something based on the content of an unstructured field, it is
>broken and irrelevant.

Nobody has suggested that transport software should do anything special
with any unstructured field. Please stick to the discussion in hand.

> What some UA software author chooses to
>do with an unstructured field for purposes of display (aside from
>what is required by RFC 2047) is neither an interoperability issue
>nor an issue that belongs in the syntax and semantics document.

Our present draft is more than a "syntax and semantics document". If, as
has been proposed, we later split it into a syntax/semantics document and
a protocol document, then this restriction clearly goes in the protocol
document.

>It is no more appropriate than requirements on the content of an
>Organization field, a Comments field, or a Content-Description field
>(all of which are unstructured).

There is no law of the universe (or of the IETF) that states that
standards may not ascribe special meanings to certain forms within
'unstructured' headers. Indeed, RFC 2822 does so with "MAY" wording.

Whilst I might agree that conveying machine-readable intelligence in a
Subject header is a Bad Thing, the fact is that this particular practice
is widespread, in both email and news, and even has some blessing from RFC
2822. Therefore it is perfectly proper, if we see fit, for our standard to
document the correct format of this practice, just as we have already
documented other practices that are in common usage but nowhere written
down precisely. That is what standardization is all about.

Our draft has little to say about what reading agents should do (I suppose
it could have said that the text of an article that is displayed MUST be
the text that was received, and not some capricious alteration made for
political correctness, but I suppose that can be taken as obvious).
Generally, what reading agents do is not a major concern because they are
the end point of the chain. But reading agents DO need to now what inputs
they can expect (and that is the point of this standard).

When, it comes to posting and followup agents, however, our draft can and
does say much more (because posting and followup agents are not end points
of the chain). The particular issue here is a proposed restriction on what
a followup agent can do: namely that it MAY automatically add a single
"Re: ", but it MUST/SHOULD NOT add a second "Re: ". If is is proper for
RFC 2822 to say that it "ought" (whatever that means) not to add a second
"Re: ", then it is equally proper for our draft to strengthen that by
saying that it MUST/SHOULD NOT do it, if we see fit.

The ONLY question we have to decide is whether we consider it is
sufficiently important for reading agents to be able to assume that a
single "Re: " is all they need contend with for us to make that
strengthening (bearing in mind that existing practice in reading agents
seems to be to make that assumption).

-- 
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



This archive was generated by hypermail 2.1.7.