From: John Stanley (stanley@peak.org)
Date: Fri Apr 13 2001 - 20:41:10 CDT
Charles Lindsey (chl@clw.cs.man.ac.uk):
>I think it is up to our chairman to say to what extent we should be
>revisiting issues that we debated and decided one or two years ago.
I think it is up to each of us to find patently absurd statements in this
draft and prevent them from becoming part of the final standard. Every
absurd comment in the final standard is just one more thing that will keep
it from ever being implemented.
>> Software SHOULD
>> NOT attempt to interpret headers not described in this standard or in
>> its extensions,
>Because new headers are going to appear in the future,
I am not talking about the future. I am talking about right now. MIME
headers are already defined, yet THIS DRAFT says that software SHOULD NOT
attempt to interpret them.
Now, as far as MIME being a pimple on the ... well, not worth the effort,
I'm all for a statement that it should not be interpreted in news. I'm
trying to find a way to keep Pine from paying attention to it. But
just before you say it should not be interpreted, you say it can be
used. That's what is patently absurd. "You can use headers from this whole
collection of different standards, but software SHOULD NOT attempt to
interpret anything except what you find in this standard or its
extensions."
>(which is what you appear to be saying)
What I appear to be saying is that it is absurd to tell people that news
articles can use any of a very large set of headers but that software
should limit itself to interpreting only a very limited subset of those
headers. I am saying neither that the software should be interpreting them
all nor none of them. I'm pointing out nonsense. Here's the fork in the
road. You can go one way or the other, but not both. Pick one.
>I agree that is maybe a bit too strong, but I see no other way to word it
>that does not give carte blanche to upstart implementors (a certain Mr
>Gates springs to mind) to invent new "features" that turn out to make
>Usenet unusable for everyone else. That has happened too many times in the
>past.
USENET is unusable? What? When did this happen? Boy, you take a nap after
lunch and you miss everything. Most of it is not worth using, but that's
not the same thing, and it wasn't caused by Bill Gates.
New features will be implemented even if you put "N0BODY is allowed to
invent NOTHING NEW no more!" in this standard. If they don't work, they
tend not to be adopted. If they do, then they've not made USENET unusable.
In fact, the people who have done the most to make USENET less usable have
deliberately ignored the part of the current standard that lists the
people who are authorized to issue cancels. You don't seriously expect a
new standard will limit anything someone really wants to do, do you?
> Yes, for X-headers, but not MIME (since MIME is described in this
> draft).
MIME headers have their own set of RFC in which they are described. I
think it is pretty uppity to claim that this draft describes MIME in any
significant way. It is also pretty uppity to think that you've described
all the MIME headers that will ever be.
> (in the way that X-No-Archive did not affect anything
>within Usenet, though it did affect what was done in archives that were
>not a part of Usenet itself).
It is also pretty uppity to start trying to draw lines between what is and
is not USENET. "We don't need this function because the people it supports
aren't really part of USENET anyway..." is how it is usually worded. It
sure seems too many people ON USENET were talking about how the
dissappearance of DejaNEWS disrupted their use of USENET for DejaNEWS to
be considered "not a part of USENET itself."
And if a web page isn't "part of USENET", you've just invalidated every
USENET newsgroup poll for the last three years, since every CFV has been
available on at least one web page during that time. And that doesn't
count Deja.
>s/them/header-parameters/
>Note that the introduction of header-parameters is mainly for future
>proofing (a bit like folding in the Newsgroups header, though one hopes
>the "future" is a bit shorter in that case). We discussed it and agreed it
>way back.
Agreed what "way back?" That you would cloud the meaning of a paragraph
by using a pronoun that has no clear antecedant. Fine. Ok. Excuse me for
asking.
>That stuff is straight out of Son-of-1036. This is the first time anyone
>has raised it as a problem.
There is always a first time. "This is the first time" is not an
argument for the status quo. If there is no case sensitivity, then there
is no preferred case convention that SHOULD be followed. And no, this is
not even the first time someone has raised this as a problem, it has
appeared in a recent discussion in news.groups about the failure of Google
to honor X-No-Archive headers. Someone chimed in claiming that the user
was using the "wrong case" as defined by the "standard".
>I have put a back reference to 4.2.1, and changed the word "defined" in
>4.2.1. to "established":
That's even sillier. This draft does not "establish" headers, it defines
them. Headers are "established" when they become commonly accepted and
used. The X-No-Archive header is well established in USENET even though it
is not defined here. The "Summary" header is defined here but not
established as a useful header.
The proper change, if any, is to say that there are no DEFINED headers
that are experimental, but then that isn't really true. I can issue an
informational RFC for an X-header and make it defined, just not by the
news standard or one of its extensions.
I think Russ is right, if I understand him right. X-headers are too
nebulous for serious use, but they make arguments about what to call the
header while it is still experimental go away. Maybe they should go away
completely.
>I think harm could arise if a reading agent saw an Xref header with an
>article number left over from some upstream site and presumed that it was
>meaningful on the local server
Then say "Local Xref headers MUST be removed..." To say that ALL local
headers must be removed because a specific one of them might cause some
confusion is silly.
Here's a good example. Site B uses a scoring system with nocems, etc, and
records the nocem data in a local header. Site C gets news from B and
likes B's system. THIS draft says that site C MUST remove (not MAY remove,
not SHOULD remove, MUST remove) the header that carries the information it
wants. That's absurd.
>>If I type
>>my name at the end of an article, is this a "signature" as defined by this
>>standard and am I violating it by not jumping through the hoop?
>Yes.
To claim by use of a MUST that I am creating some interoperability problem
by typing my name at the end of an article is patently absurd. Nothing
breaks, nothing blinks, nothing even hiccups. So then I start typing my
name and my phone number at the end. Then I start adding my street
address. At what point does something start breaking? When does news go
POOF if I don't use a sigdash? What justifies this MUST?
>There have been user-agents that have done
>this wrongly in the past, and have caused much grief and flammage as a
>result.
"Grief and flammage" are the wheels upon which much of this USENET thingy
runs. Fine hardened steel comes from forges burning hot. Is this a
technical standard or a netiquette one? We've already got one for
netiquette. If this is going to be another, let's just drop it now and get
on with real life.
>If someone can tell me a good nroff hack to make it do that ...
Do as we say and not as we do... Did you actually NOT include the
mandatory space in the copy you sent IETF?
>That is purely to remove what would otherwise by an ambiguity in the
>syntax. Hence the MUST NOT is correct ...
An ambiguous syntax describing a header that agents are told they SHOULD
NOT enforce anyway is hardly a case of serious interoperability issues.
The only issue I see in the Subject header is that some agents add
back-references willy nilly and lines start looking like "Re: Re:
Re: ARMM: ..." That's the behaviour that should be restricted. There is no
use anymore for Re: in the subject. It is covered by References, which is
MANDATORY and has been mandatory for many years. User agents don't need it
to thread, and they don't need it to tell the user the message is a reply.
Subject should be returned to user-entered and leave it at that. Just like
Summary and Keywords except inheritable.
>Can you suggest a wording that covers it? "may remove instances of a
>purported back-reference..."? I think the intended meaning is clear,
>unless read with deliberate ill-will.
What is "it" that needs covering? You mean "non-standard back-reference"?
"It" doesn't exist. It is either a back-reference or it is not. Agents
should not screw with what they don't understand is the guiding principle,
isn't it? If it isn't a back-reference as defined here, then it can be
ANYTHING, and they don't understand it. Thus they should not screw with
it.
For example, some groups have been using keywords in the subject to help
readers select articles. Are you telling me that a group that finds that
the keywords "RE" or "SV" are appropriately descriptive should find those
keywords stripped from its articles because an ignorant agent thought they
were "back references", even though "back reference" has a simple and
explicit definition that neither of those fits?
>The fact that some injecting agents are not as omniscient at their authors
>would believe does not alter the fact that some of them DO attempt such
>stupidities.
Yep. And it is stupid for us to admit we know it happens without fixing
it. That's as much as a stamp of approval.
> I presume it was a
> real problem that had been observed in practice.
Then the text should be a restriction on injecting agents to prevent it
from being conforming behaviour. When it is a MUST NOT, then it is not an
injecting agent, it is rogue software, when something tries doing it
wrong.
"The requirement for the From header is any address belonging to the
poster. Because injecting agents cannot determine which addresses meet
this requirement, they MUST NOT attempt to enforce it by replacing user
provided entries with their own guesses."