From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Fri Apr 13 2001 - 06:17:54 CDT
In <Pine.LNX.4.10.10104121507340.2239-100000@spock.peak.org> John Stanley <stanley@peak.org> writes:
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. OTOH,
small imporovements to wording can always be considered where they are
non-controversial.
>4.2.1. Names and Contents
>> Software SHOULD
>> NOT attempt to interpret headers not described in this standard or in
>> its extensions,
>Then why not say that they SHOULD NOT be anything but what is described in
>this standard, instead of saying they SHOULD be anything in this standard,
>MESSFOR, extensions to those, MIME standard, or X headers?
Because new headers are going to appear in the future, with or without
official blessing and with or withour 'X-'s in front, and we don't want to
say that agents SHOULD refuse to accept such articles (which is what you
appear to be saying). OTOH, any agent that tries to interpet such a header
may end up doing more harm than good. Hence the "SHOULD NOT interpret".
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.
The meaning of the "SHOULD NOT interpret" is "don't do this unless you
really, Really, REALLY understand what you are doing". Having said that,
most of the new headers that get invented are largley for informative
purposes, so that the matter of "interpretation" does not arise.
>I.e., you've said in one sentence that you can use X-headers, but in the
>next you say software SHOULD NOT interpret them. And you can use MIME
>headers, but software SHOULD NOT interpret them.
Yes, for X-headers, but not MIME (since MIME is described in this draft).
As for the X-headers themselves, they are a well established feature of
many internet protocols, and I don't think we should be changing that
well-established principle. And they should not be used except for
informative purposes, or where their interpretation only affects things
external to Usenet (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).
>> On the other hand, posting agents SHOULD NOT generate them
>Them what? There is so much stuff between the start of the preceeding
>paragraph and the first sentence of this one that "them" is essentially
>antecedant-less.
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.
>> Header-names are case-insensitive. There is a preferred case
>> convention,
>Then they are not case-insensitive. If you tell people they should be a
>certain way and they don't have to be any certain way in the same
>paragraph, they will look at you funny. We've already seen the noise that
>this "preferred case" statement causes and the standard isn't even out
>yet.
That stuff is straight out of Son-of-1036. This is the first time anyone
has raised it as a problem.
>4.2.2.1. mentions "established headers". This is a fifth case not defined
>in 4.2.2. anywhere. I'd say that X-No-Archive is established, thus it is
>not experimental according to 4.2.2.1.
I have put a back reference to 4.2.1, and changed the word "defined" in
4.2.1. to "established":
Header-names SHOULD be either those for which a USENET-header-content
is established by this standard, or by [MESSFOR], or by any
extension to either of these standards including, in particular, the
Mime standards [RFC 2045] et seq., or else experimental headers
beginning with "X-" (as defined in 4.2.2.1).
>4.2.2.3. Local Headers "MUST be removed (and replaced as necessary) by
>serving agents when received."
>Did you mean "can be"? If a server does not care about some header that
>is local to some other site, and it does not understand that header, it
>should not do anything with it. Or it should be free to keep it if it
>likes it.
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 (even if the local server did not use article
numbers for some reason). So it is much better to get rid of them. But I
agree this is a SHOULD rather than a MUST, so I have changed it.
>4.3.2. ...
>> If a poster or posting agent does
>> append such a signature to an article, it MUST be preceded with a
>> delimiter line containing (only) two hyphens (ASCII 45) followed by
>> one SP (ASCII 32).
>This is a MUST? Does this meet the requirements of the RFC that defines
>how you use MUST? What news systems break if this is not done? 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. It is so by definition since if the "-- " is absent, then it is not a
"personal signature". So if you want it to be regarded as a signature,
then you MUST do it properly. There have been user-agents that have done
this wrongly in the past, and have caused much grief and flammage as a
result.
>4.6 An Example
>The sigdash marking the signature in the example does not have the
>trailing space that this draft says it MUST have.
If someone can tell me a good nroff hack to make it do that ...
>5.4. Subject
>> The pure-subject MUST NOT begin with "Re: ".
>Does THIS meet the requirements for MUST NOT as outlined in the standard
>for MUST NOT? What breaks if a subject begins with Re:? Especially when
>this requirement is followed by:
That is purely to remove what would otherwise by an ambiguity in the
syntax. Hence the MUST NOT is correct - if "Re: " is present, then it MUST
be parsed as a back-reference.
> Agents SHOULD NOT depend on nor enforce the use of back references by
> followup agents.
>> Followup agents MAY remove instances of non-standard back-reference
>If it isn't "back-reference" as defined herein, it is not "non-standard
>back-reference", it is just text. If you tell agents that they MAY remove
>what they think is a back-reference that isn't, you've told them they MAY
>mangle the Subject header in any way they want.
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.
>5.6.5. Suggested Verification Methods
> The following approaches for common transports are suggested in order
> to meet a site's verification obligations. They are not required, ...
>If they are not required, they are not an obligation.
It is the "approaches" that are not required, not the "verifications". Try
reading what the text actually says.
>5.2. From
> Be warned also that some injecting agents that have
> authentication information may choose to replace the From-
> content based upon the authenticated identity.
>I know of no possible way for an injecting agent to know that the address
>I have entered in the From header is not mine. To even hint that such
>information is available will cause injecting agents to try "good enough"
>which violates this standard. This paragraph should be removed.
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. The text in question is just a NOTE pointing that out. I do
not remember who proposed that text originally, but I presume it was a
real problem that had been observed in practice.
-- 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@clw.cs.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