Re: Various draft problems

New Message Reply About this list Date view Thread view Subject view Author view

From: Russ Allbery (rra@stanford.edu)
Date: Thu Apr 12 2001 - 18:36:49 CDT


Thanks, John. This and some other recent discussion has brought to light
a whole bunch of different things that I'm not particularly happy about.

John Stanley <stanley@peak.org> writes:

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

Seconded. I believe this sentence should simply be removed.

(I'm also opposed to the X- convention. I think it's ill-conceived and
makes it unnecessarily difficult to create a new, useful news header, and
I think that the problems with not using X- have been overstated and have
not appeared in practice.)

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

The whole header parameter thing continues to be a bad idea.

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

Seconded. Let's please drop the whole case convention stuff entirely. It
shouldn't matter, it definitely doesn't rate a SHOULD (since there's no
interoperability issue involved, and in fact we require there to not be an
interoperability issue), and that whole thing is just kind of dumb. Most
people will use the case convention from how it's presented in the RFC
without any prompting at all, and for those people who don't, what does it
matter?

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

Agreed; some other more precise and already defined term should be used
instead of "established."

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

Seconded.

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

Seconded. I don't think this should be in our draft at all (see other
messages about not adding additional structure to text/plain), but if it
is, it's at most an Ought.

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

Heh. :)

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

Which is, in fact, true; the user can arbitrarily edit the Subject header.
Including removing Re: and inserting Sv:. And there's no way for the
protocol to distinguish between user behavior and software behavior. That
makes the MUST NOT pretty hard to justify, as much as I hate that bogus
mistake too.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>


New Message Reply About this list Date view Thread view Subject view Author view


This archive was generated by hypermail 2b29.