From: Bruce Lilly (blilly@erols.com)
Date: Sat Mar 20 2004 - 09:05:26 CST
The current Usefor draft is unclear about several matters related
to followups (independent of whether the followup is to a single
message or multiple messages):
Section 8.6 presents rules for initializing Newsgroups and Distribution
fields with nebulous wording like "initialized from the precursor's
[...] header". Newsgroups Followup-To, and Distribution, though not
MIME header fields, are defined with optional MIME Content-Type/Content-
Disposition parameters. It is unclear whether those optional
parameters should be part of the initialization. If so, it is unclear
whether that applies to all or only some parameters. It is further
unclear whether or not all parameters (including all which might be
defined in the future) for Followup-To are valid in Newsgroups and
vice versa.
When considering followups to multiple messages, there are additional
complications. First, handling parameters as well as newsgroups or
distributions is not trivial; the newsgroup- or distribution-list
will have to be combined (in some unspecified manner) independently
of how the parameters are combined (in some unspecified manner); the
raw field contents cannot simply be concatenated, since all parameters
must appear after the newsgroup/distribution list. It is also not
clear what should happen in the case of a parameter attribute which
has several possible but mutually exclusive values (e.g. "yes" / "no")
where the values for that attribute differ among the messages being
followed up.
The MIME parameter mechanism has no provision for applying parameters
to a subset of list elements (unlike, say, the methods used in RFC 2156
or RFC 2533).
All of which indicate that specification of MIME parameters is a
premature *implementation restriction* posed as a "solution" to a
"problem" that does not exist. Once again I strongly recommend that
specification of MIME parameters be dropped except for cases where
there is at least one such parameter defined and where the rules
for handling parameters for generation, injection, transport,
filing, following-up, replying, gatewaying, etc. are clearly
specified. Reminder, RFC 2026 says "A Proposed Standard should have
no known technical omissions". As it stands, handling of parameters
in most of the fields for which provisions are made in the Usefor
draft, as well as handling of followups to multiple messages, comprise
known technical omissions.
In order to allow for future extensions along the lines of RFC 2533,
header fields currently defined with MIME parameters which are
incompletely specified, in addition to having parameters removed
from the specification should use FWS rather than CFWS in the
specification (except where that might conflict with RFC 2822 or
other relevant standards).
#################################################################
#################################################################
#################################################################
#####
#####
#####
#################################################################
#################################################################
#################################################################