From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Sun Nov 10 2002 - 06:13:28 CST
LIST OF ISSUES
--------------
The following issues will need to be decided by a Straw Poll, but first
we need to get the wording of the alternatives correct, so that we all
know exactly what we are voting on.
The main change from the previous list arises from some discussions with
Forrest, who wanted the result to show a clear indication of whether
consensus had been achieved. There is now a new "Alternative X" which
means "beyond this point there is no consensus", or "over my dead body",
or "abandon the project", or however else you like to put it.
So if your preferred various options A through F in that order, you
might vote
A > B > C > X > D > E > F
which means "I prefer A, then B, then C, but I would accept any of them;
but D, E and F are unacceptable, though D is less objectionable thaf E".
So in case the majority like D, E and F you have still had your say in
influencing the choice between them.
If, when the votes are counted, there is a preferred option (say A)
which also beats X by a handsome margin, then we are home and dry with a
consensus for A.
If there is a preferred option A, but no option beats X by a handsome
margin, then we have no consensus. What do we do then? Carry on arguing?
Go to the IESG and say "the majority wants to go with A, but it does not
amount to a consensus"? Abandon the whole project? Let us cross that
bridge when we come to it.
And it is also possible that there is an option B, less preferred by the
majority than A, but with a better margin over X. In that case maybe we
decide to take B as a compromise.
Note that we are not saying in advance how big "handsome is". Clearly
99:1 would count; 51:49 would not. All that we can be sure of is that
the vote will give us the evidence we need to see exactly where we
stand.
Note that I have also added an alternative #6 to omit internationalized
newsgroup-names entirely. I don't think anyone actually supports that
position, but it is useful to have both extreme positions in the vote,
just to place everything in perspective.
Also, the wording of Alternative #2 is incomplete. Is was Per's
suggestion (I think) and I have emailed him asking for clarification,
but heard nothing back.
Issue 1 - 8bit headers
----------------------
Alternative #0 (the PRESENT DRAFT)
----------------------------------
a) UTF-8 is allowed in headers.
b) RFC 2047/2231 is also allowed and is required for the mailed
component of posted-and-mailed.
c) Newsgroup-names are encoded (5.2.2) when posted-and-mailed or sent to
moderators, but are raw UTF-8 on the wire.
d) Gateway implementors have some discretion (8.8.2) as to the extent of
compliance with the email standards.
e) Injecting agents at sites that choose to carry moderated I18N groups
require to be upgraded.
f) Posts to a moderated ASCII group via non-upgraded injection agents
may get munged by MTAs en route to the moderator if they contain
UTF-8 in any headers, especially if octets in the range 0x80-9f are
present (as in maybe 73% of Unicode code points). Even though the
great majority of such posts might work, if it fails once for a given
injector/moderated-group pair, it will likely fail always for that
pair. The post would still be propagated to the ASCII group(s).
Alternative #1 (STRICT EMAIL COMPLIANCE)
----------------------------------------
a-c) As #0
d) Include explicit requirements on how to transform headers (for
posted-and-mailed and moderators, not necessarily for other gateways)
so as to be fully compliant with the email standards (that would
include headers in body parts of multiparts, and so recursively).
e-f) As #0
Alternative #2 (8bit in MODERATED - MUST NOT)
-------------------------------------------
a-d) As #0
e) Current injecting agents unaffected.
f) Disallow
moderation of non-ASCII groups,
cross-posting between any moderated groups and non-ASCII groups.
{Question: what about other UTF-8 headers in moderated groups? This
was Per's proposal, so could he clarify this?}
Alternative #3 (8bit in MODERATED - SHOULD NOT YET)
---------------------------------------------------
a-d) As #0
e) Injecting agents require to be upgraded in the longer term.
f) Discourage
moderation of non-ASCII groups,
cross-posting between any moderated group and non-ASCII groups,
posting to any moderated group with UTF-8 in any header
until injecting agents/moderators/email systems are able to handle
them. This could be done by requiring injection agents to convert to
RFC 2047/RFC2231/5.5.2, by requiring encapsulation of such cases, or
other means to be discussed; but at the same time warning that these
facilities would only become available over time.
Alternative #4 (SEND 8bit REGARDLESS)
-------------------------------------
Define only how to transform a newsgroup name into a moderator's
email address alias. Specify sending UTF-8-xtra-char in email
headers. Even though this would not be compliant with current email
standards, just hope that the IETF will still accept this draft.
{I think this was Forrest's straw man, intended to be a parody of the
present draft. It is left in unless he wants to remove it or reword it.}
Alternative #5 (ALL 8bit ENCODED on the wire)
---------------------------------------------
a) Remove all references to the use of raw UTF-8 in headers from the
document.
b) All non-ASCII in headers would be handled by RFC 2047/2231 or
by specially-designed encodings.
c) In particular, the canonical form of newsgroup-names on-the-wire
would be some 7bit encoding of its Unicode name, chosen to permit
continued use of the present moderstors.isc.org convention. Encoding
could be punycode, 5.2.2, newsgroup components beginning '_', or
something else.
e) Current injecting agents unaffected.
f) Current posting arrangements unaffected.
Alternative #6 (ALL 8bit ENCODED; NO I18N NEWSGROUPS)
-----------------------------------------------------
a-b) As #5
c) Only ASCII newgroups-names, as RFC 1036.
d-e) As #5
Alternative 'X' (NO CONSENSUS)
------------------------------
This is a placeholder for people to indicate what they could "live
with". Options ranked above #7 mean "there are my order of preference,
but I would accept any of them". Options ranked below #7 mean "I regard
these as unacceptable, and my order of preference merely indicates
increasing dislike".
Issue 2 (SPLIT THE DOCUMENT)
----------------------------
The document to be split into two - one for Standards Track and one for
Best Current Practice. Note that this does not involve ANY technical
change (such must be proposed separately as other issues). It is not
precluded that further "Netkeeping" material could be added to the BCP
document.
Issue 3 (USER AGENT) - withdrawn.
---------------------------------
{The matter of what to do with User-Agent is currently under discussion
with a proposed solution. So this is removed from the list of issues
unless/until that discussion fails to produce an outcome.}
Issue 4 (MIME-STYLE HEADERS)
----------------------------
To remove the possibility of other-parameters (aka extension-parameters)
from some or all of the headers that are already a part of email, so
that the article format is fully compliant with current email standards.
{I offer a selection of alternatives here, from least aggressive to most
aggressive. Other combinations can be offered if people want them.}
Alternative 1:
Remove from Sender
Alternative 2:
Remove from Sender, Date, Message-ID
Alternative 3:
Remove from Sender, Date, Message-ID, Keywords, References
Alternative 4:
Remove from Sender, Date, Message-ID, Keywords, References, Supersedes
{It is arguable whether 'Supersedes' is properly considered a mail
header at all. See NOTE in 6.15 relating to X.400 and RFC 2156.}
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