Re: Internal LAST CALL

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

From: Andrew Gierth (andrew@erlenstar.demon.co.uk)
Date: Thu May 09 2002 - 00:56:46 CDT


>>>>> "Charles" == Charles Lindsey <chl@clw.cs.man.ac.uk> writes:

>> If published as an RFC, it would be one of the largest 40
>> RFCs. It's about two and a half times the size of RFC2822, and
>> comparable in size to all five of the core MIME RFCs put together.

 Charles> But if split into two or more RFCs, the total number of
 Charles> pages would actually increase.

I'm not suggesting splitting it (though I would support doing the
policy issues as a separate BCP if they were removed from the format
specification entirely).

I'm suggesting that it needs, at a minimum, a savage editing job to
reduce the verbosity of the stuff that _does_ belong there and remove
completely the material that simply doesn't belong there.

>> At the very least the archaeological formats should be deleted;
>> these are documented in other RFCs, which won't magically
>> disappear if this draft gets published.

 Charles> Are you offering to withdraw your objection if those
 Charles> archaeological formats are deleted?

no. They are a symptom of the problem, not the problem itself.

 Charles> But these are all directed to making a cleaner system, with
 Charles> better compatibility with Email, in the long term.

>> Compatibility with email does not require changes to the syntax of
>> headers never used in email (such as Path or Newsgroups).

 Charles> No, but it does make sense that whatever folding rules we
 Charles> have should apply evenly across all headers. And Newsgroups
 Charles> does appear in email quite often, as it happens.

Newsgroups is merely a user-defined header in email and is therefore
opaque. I reiterate my objection.

 Charles> They are all SHOULD NOT generate.

Why do you keep repeating this when I've already pointed out that it's
untrue for Path? You can read the SHOULDs for yourself in the spec.

>> untrue - the draft even goes so far as to use "SHOULD" for folding
>> the Path header

 Charles> An agent that does not accepted folded Path is already in
 Charles> breach of RFC 1036.

Tough. This is an area in which 1036 is more liberal than existing
practice allows.

 Charles> But the evidence is that folded paths propagate perfectly
 Charles> well. The only problem is that some agents unfold them
 Charles> before passing them on, which is naughty, but does not cause
 Charles> irreparable harm.

That's not the only problem. And I'm sorry, but injecting a handful of
articles and observing that they show up on some other sites does not
constitute much of a test.

>> a preliminary scan through the text identifies the following
>> questionable uses of SHOULD or MUST:

 Charles> OK, these can be discussed. I have started a separate thread
 Charles> to do so.

As Russ pointed out, the problem is not so much with the details of any
of these items, but the fact that they are there at all indicates a more
serious problem.

It's clear from the experience of both RFC 1036 and the mail RFCs that
mixing technical and policy issues in a document of this type is a bad
idea. (examples: the RFC 1036 language for "cancel", and the mail
standards requirements for "Postmaster")

-- 
Andrew.


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


This archive was generated by hypermail 2b29.