From: Bruce Lilly (blilly@erols.com)
Date: Wed Mar 03 2004 - 21:30:52 CST
J.B.Moreno wrote:
> 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?
Shall we presume that the article body does not discuss that text?
If so, then that text is not indicative of the topic of the message
and therefore does not conform to the specified semantics for Subject.
> What is it doing that the standard forbids it to do, or conversely what is
> it NOT doing that the standard requires it to do?
In this particular case, there is no syntax issue, and no protocol
issue (because Subject field content is exclusively for human
consumption). It's not a case of doing something forbidden or
failing to do something which is required. It does not conform
to the specified semantics, which is a different matter. It may
well irritate readers, and it may well irritate users of that
newsreader (possibly to the point that there is only one user :-).
However it causes no network damage (that might not be the case if
the text inserted were 3 MB long) and does not affect
interoperability. Consequently it is of *relatively* minor
importance. A hypothetical poster using such a newsreader would
be free to delete that text or to insert something like "Send
spam to planb@newsreaders.com". A user or indeed any reader
could claim (with validity) that that hypothetical practice of that
hypothetical newsreader distorted the semantics assigned to the
Subject header field by the relevant standards. And as there is
no enforcement body for the Internet or Usenet, you could ignore
those complaints. And users could use a different product, and
other readers could killfile any message with that text in the
Subject. It doesn't matter much in the grand scheme of things.
> Now, their grounds for wanting the standard written so as to make the above
> compliant is that the user can hand enter the above, and so we can't forbid
> the software from doing it -- because it's impossible to tell the difference
> between what the software did and what the human did, and we can't control
> the human.
As long as it is understood that the scope of that statement is
in regard to a Proposed Standard related to protocol issues, maybe
yes, primarily because there are no protocol issues involved. The
caveat in that is that:
a) the issue isn't so much "control[ling] the human" as it is
asserting his freedom to be able to do the right thing w.r.t.
the specified semantics if his topic corresponds to the Subject
b) not so much that we "can't forbid the software from doing it" as
we "shouldn't" because it would be pointless to do so (the
user can override, and even if he does not, there is no real
harm)
c) the syntax is compliant for sure, but I don't think anybody would
be willing to claim that that has any bearing on the semantics
> 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.
You are wrong; users are not permitted to override References.
> 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".
Your examples relate to semantics, not syntax. Specifically they relate
to semantics which affect protocol issues such as duplicate detection
and suppression, cross-references for threading, and propagation. None
of which apply to the Subject field, and none of which support your
assertion that "Re: " should be a syntax issue.
> 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).
Your point?
> So, the fact that it is not possible to run just the headers and body of an
> article through a program and have it spit out "non-compliant" or
> "compliant"
It is indeed possible to do so and detect syntax errors (or state
definitively that there are no syntax errors) [or in the case of
an ambiguous syntax specification, one can state that there is
an issue related to that ambiguity].
>, doesn't mean we should be silent on the issue.
Indeed, it might not be possible to detect semantic errors which
have protocol consequences, including those that might lead to
network damage or hamper interoperability. Yet we should specify
parts of the system appropriately to avoid damage, etc.
However, where semantics have no protocol consequences, though
we might well have something to say about the intended semantics,
either directly or by reference to another document which specifies
those semantics, and we might well say something in an Information
class document about non-protocol issues (e.g. user convenience),
it would be inappropriate to place requirements or restrictions on
agents in a Proposed Standard dealing with syntax, semantics
(remember, we're talking about semantics with no protocol
consequences in this case), and/or network operations.