From: Russ Allbery (rra@stanford.edu)
Date: Wed Mar 03 2004 - 19:25:48 CST
J B Moreno <planb@newsreaders.com> writes:
> If I write a newsreader according to the standard as they want it
> written, and when posting it inserts "Send $5 to planb@newsreaders.com
> via paypal to earn millions: " before the user's subject, how is that
> not a compliant article according to what they are saying?
It is a compliant article. It *has* to be a compliant article because
there is no way to distinguish it *at a protocol level* from an article
where a user entered the same text into the Subject header themselves.
Software which inserts such a string is poorly considered. I have no
problems with putting language into the standard which makes this clear
and specifies what the best course of action for an implementor is.
E-mail already has language that does this, and I think we should adopt
it. If people feel the need to give more rationale, I have no problems
with that.
I believe you are failing to distinguish between article format protocol
issues, client best practices, and quality of implementation issues. You
are combining them all into a giant "protocol" nail and whaling on that
nail with your standards hammer. Not everything is a nail.
> This is bogus on three grounds -- one, I can put anything I like into
> any header that I like without even resorting to telnet where everything
> that goes out is what I typed in, which means that all followup
> requirements are out the window (including References) if the user's
> ability to override is to be considered relevant.
An article without a References header is fully compliant with the article
format standard. It's simply not a followup.
This is one of those places where there are clearer ways of wording the
standard than to use MUST language. I don't believe it's the best wording
to say that followups MUST contain a References header of the appropriate
construction. A better phrasing would be to *define* followups as
containing such a header. Articles without a References header are still
compliant, and have to be compliant, because sometimes that's exactly the
intended semantics that the poster is trying to create. They are simply
not followups.
People intentionally start new threads while quoting existing messages all
the time.
> Two, we can't control what software does any better than we can control
> what humans do: if they do something that the standard forbids then they
> have done something the standard forbids, it's either stopped or it's
> not, that doesn't change the fact that it was non-compliant. If I write
> a newsreader and it reuses message-id's after 6 months, then it's
> non-compliant, but the article will still possibly get around; if my
> client doesn't include a References the articles it produces won't be
> dropped; a server that adds a random peer to a path header won't prevent
> the article from propogating to other servers it peers with. Having an
> error detected and the article dropped is *not* the definition of
> "broken" or "non-compliant".
I don't disagree with this.
> Three, although we can't tell the difference from the other end, we
> still address our statements to various software elements (server,
> relayer, injection agent and so forth), we can just as easily direct our
> statements at "humans" as we can at relayers (and in fact they are more
> likely to be aware of our requirements than older software).
We *can* do all sorts of things. Capability isn't the issue. What we
should not do is contradict ourselves, and calling a header unstructured
and then putting standards-level requirements on its contents means that
one half or the other of that statement is a lie. Either there aren't
really requirements or the header isn't actually unstructured.
It is entirely possible to declare the Subject header to be a structured
header. I just think it's a really bad idea, both because of the conflict
with e-mail and because doing so does not solve any important problem and
will not improve Usenet in any meaningful way. The resulting structure
cannot be relied upon by any reading client *anyway* and appears to be
there solely to address fears that use of "RE:" or "Sv:" or the like will
suddenly become significantly more widespread than they are at present
unless we make the Subject header structured, a fear that so far as I can
tell has no rational basis.
I am extremely frustrated that you seem to believe that unless we declare
Subject to be structured, we can't provide any meaningful guidance to
implementors at all concerning "Re: ". I don't understand how you could
hold this position, but you appear to be arguing it at length. Your
arguments are addressing straw men almost exclusively; I don't believe
have read a single serious followup addressing what I actually wrote and
what I actually proposed in the past week.
It's very difficult to remain patient in that situation.
To repeat again: I believe that our document should clearly tell client
implementors the preferred handling for "Re: " and should warn against
using some other string for that purpose. I do not believe that SHOULD or
MUST should be applied to this advice; I think such language would be both
contradictory and inappropriate, not to mention unnecessary. John and I
have both proposed language that I believe makes it quite clear to a
client implementor what the right thing to do is and what the consequences
of doing the wrong thing may be, and I've not seen any real attempt to
address those proposals in a meaningful way.
If you're honestly confused about my position, I would like to clarify it
until you understand it.
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>