From: Andrew Gierth (andrew@erlenstar.demon.co.uk)
Date: Tue May 07 2002 - 08:23:22 CDT
>>>>> "Charles" == Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
>> 1. It is still too long (two or three times longer than should be
>> necessary)
Charles> Yes, we could indeed take another 12 months on a complete
Charles> rewrite.
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.
Do you not think this is a problem? We are _not_ dealing with a
protocol as complex as OSPF, NFS, NTP or HTTP/1.1 here, to name the
better-known of the longer specifications.
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.
>> 2. It still attempts to introduce changes which are unnecessarily
>> incompatible with existing implementations (for example, the
>> introduction of purely cosmetic whitespace and folding, comments, or
>> parameters, into important machine-parsed headers)
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> They are all SHOULD NOT generate.
untrue - the draft even goes so far as to use "SHOULD" for folding the
Path header
>> 3. It still confuses technical issues with aesthetic and policy ones.
>> For example, the use of "MUST NOT" in connection with auto-creation of
>> groups from traffic is not justifiable on interoperability grounds.
>> Likewise for much of the section on newsgroup-names.
Charles> There has been a rough consensus within the working group to
Charles> include policy issues in the draft (but clearly indicated as
Charles> such). We have has a straw poll on the use of "Ought", and
Charles> have also cleared that usage with the area director.
Reviewing the list traffic at the time suggests that many of the
people responding supported retaining the policy issues only in the
interests of producing a completed draft, on the assumption that _any_
document was better than nothing.
I disagree; I think that the current draft is sufficiently bad that it
would be better in the long term for it to die, and for those changes
that are actually necessary to continue happening as they have done
for the past 15 years since RFC 1036, than for it to be published as
an RFC in its current form.
Charles> However, if there are particular cases that you want moving
Charles> from MUST to Ought, or vice versa, then now is the time to
Charles> raise them.
a preliminary scan through the text identifies the following
questionable uses of SHOULD or MUST:
4.5 "... Posting agents SHOULD endeavour to keep all header lines, so
far as is possible, within 79 characters by folding them at suitable
places... "
4.5 "... injecting agents SHOULD fold any headers generated
automatically by themselves ..."
5.5 reservation of _, +, - violates existing usage in some cases
5.5 "... Serving agents MUST NOT create new newsgroups simply because an
unrecognized newsgroup-name occurs in a Newsgroups-header ..."
[NOT RECOMMENDED might be more appropriate for that case]
5.6.2 "... In addition, it SHOULD then add
CRLF and WSP if it would otherwise result in a line longer than 79
characters."
6.9 "All other headers defined in this standard (excluding
variant headers, but including specifically the Message-ID-header)
MUST be identical in both the posted and mailed versions of the
article, and so MUST the body."
[existing practice with mailed copies often involves adding additional
text to the body of the mailed copy]
6.14 "Each mailbox contained in the Approved-content MUST be that of one of
the person(s) or entity(ies) in question, and one of those mailboxes
MUST be that of the actual injector of the article."
[counterexample: news.answers]
6.14 "If this header is not present in such postings, then
relaying and serving agents MUST reject the article."
[two objections here - firstly that relaying agents frequently do not
know what groups are moderated, and secondly that accepting unapproved
traffic is a valid policy choice, albeit one which is only rarely
useful. This also directly conflicts with 8.3, which uses "MAY" for
this issue as applied to relaying agents]
6.15 "Whatever security or authentication checks are normally applied to a
Control cancel message (or may be prescribed for such messages by
some extension to this standard - see the remarks in 7.1 and 7.3)
MUST also be applied to an article with a Supersedes-header. In the
event of the failure of such checks, the article SHOULD be discarded,
or at most stored as an ordinary article.
5.6.2 "The path-identity added MUST be unique to that agent"
when combined with
6.16 "An agent MUST use the same serving-name in Xref-headers as the path-
identity it uses in Path-headers."
[Xref is in the overview, and putting an FQDN in as the serving-name
can double the average size of the header. It's not unusual for sites
to choose a short, and quite likely non-unique, Path stamp for a spool
server for exactly this reason (I've seen "0" used), thus conflicting
with the uniqueness requirement]
8.2.2 "It SHOULD likewise remove any NNTP-Posting-Host or other
undocumented tracing header."
8.2.2 "... the posting agent MUST be informed ..."
[it may not be possible to do so]
8.7 "Any Injector-Info-header (6.19) or Complaints-To-header (6.20)
MUST be removed."
[retaining the original site's trace info is a valid policy decision
for a moderator who is not otherwise constrained by their own injector.
In fact it's often a nusiance for trace info in moderated groups to
point to the moderator; it causes false positives in spam-filtering]
8.7 "However, he MUST NOT alter the order in which the
newsgroups are listed in the Newsgroups-header."
[pgpmoose's crossposting scheme alters the order of groups in the
Newsgroups header]
-- Andrew.