From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Thu Nov 21 2002 - 09:01:41 CST
I have now received votes from the following:
Bill McQuillan
Claus Färber
Kent Landfield
Thorfinn
Russ Allbery
Charles Lindsey
Per Abrahamsen
Paul Overell
Forrest J. Cavalier III
Erland Sommarskog
Shmuel (Seymour J.) Metz
Clive D. W. Feather
That still leaves a lot of regular contributors to this list unaccounted
for. Please can we have a full turnout so as to gauge the true feeling of
this WG. Vote closes midnight GMT next Thursday.
STRAW POLL
----------
The purpose of this poll is to establish the position of the Usefor WG on
three issues that appear to be contentious:
Issue 1 - (8BIT HEADERS)
Issue 2 - SPLIT THE DOCUMENT)
Issue 4 - (MIME-STYLE HEADERS)
Votes are to be mailed to chl@clw.cs.man.ac.uk.
Voting closes at midnight GMT on November 28th.
A second Call will be published after approximately 1 week.
Full details of all votes, including who cast them, will be included in the
Results.
The intention is to achieve a Final Resolution of these problems. Whatever
we now decide, that will be what goes in the document. We are not going to
have these debates again. The Chairman has given his full approval to this
approach.
Clearly Issue 1 is the main one, and several alternatives have been
provided, and you are asked to rank them in order of preference. The results
will be tallied by the "Condorcet" method which will ensure that, if there
exists a single alternative which the marjority of people rank higher than
any other, then that will be the winner.
However, in order to see whether that winner is "acceptable" to the majority
(i.e. to establish whether it has a consensus) an additional "alternative
#X", or "Consensus Limit" has been provided, with the meaning "beyond this
point there is no consensus", or "over my dead body", or "abandon the
project", or however else you like to put it.
You are asked to include #X within your ranking to show that you would
accept the majority view on anything you ranked above X, but that you would
regard anything you ranked below X as unacceptable.
Please endeavour to include every alternative somewhere in your ranking,
whether above or below X. You may rank two alternatives as equal if you
regard them as equally good (or equally bad), but alternatives you fail to
rank at all will just be treated as "equal, but at the bottom of your list".
I have also included an #X alternative under Issue 2. I did not think it
necessary to do so with Issue 4.
Note that we are not saying in advance how large a margin over X would be
needed to count as "consensus". Moreover, if A is the winner but there is an
option B, less preferred by the majority than A, but with a better margin
over X, then we might decide that it is wiser to go with B. Alternatively,
there might be a winner but no consensus. How to proceed in all these cases
will have to be decided by our Chairman, but if we are completely stuck and
there is no reason to suppose that further discussion will resolve it, then
that will probably mean taking it to the IESG.
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,
posting to any moderated group with UTF-8 in any header.
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.
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' (CONSENSUS LIMIT)
---------------------------------
This is a placeholder for people to indicate what they could "live with".
Options ranked above 'X' mean "these are in my order of preference, but I
would accept any of them". Options ranked below 'X' 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) - resolved.
---------------------------------
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.
There is a selection of alternatives here, from least aggressive to most
aggressive, specifying removal of the feature from various sets of headers.
Alternative #1:
Remove from Sender only
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
The question of whether 'Supersedes' is properly considered a mail
header is addressed in the NOTE in 6.15 relating to X.400 and RFC 2156.
0000000000000000remove this line and all above when replying 0000000000000
--------------------------------------------------------------------------
00000000000000000000000000000000000000000000000000000000000000000000000000
Please insert your name [ ]
And your email address [ ]
For each Issue, you are asked to rank the alternatives by writing '1'
against your first preference, '2' against your second, and so on (you may
also write the same number against several alternatives to indicate no
particular preference between them). The #X (Consensus Limit) alternative
should be ranked so as to divide those alternative that you could "live
with" from those you could not.
Issue 1 - (8BIT HEADERS)
------------------------
#0 (the PRESENT DRAFT) [ ]
#1 (STRICT EMAIL COMPLIANCE) [ ]
#2 (8bit in MODERATED - MUST NOT) [ ]
#3 (8bit in MODERATED - SHOULD NOT YET) [ ]
#4 (SEND 8bit REGARDLESS) [ ]
#5 (ALL 8bit ENCODED on the wire) [ ]
#6 (ALL 8bit ENCODED; NO I18N NEWSGROUPS) [ ]
#X (CONSENSUS LIMIT) [ ]
Issue 2 (SPLIT THE DOCUMENT)
----------------------------
#1 (YES, Split it) [ ]
#2 (NO, Don't Split it) [ ]
#X (CONSENSUS LIMIT) [ ]
Issue 4 (MIME-STYLE HEADERS)
----------------------------
To remove the 'other-parameter' (aka extension-parameter)
from the listed headers:
#1 (Sender only) [ ]
#2 (Sender, Date, Message-ID) [ ]
#3 (Sender, Date, Message-ID, Keywords, References) [ ]
#4 (Sender, Date, Message-ID, Keywords, References, Supersedes) [ ]
00000000000000000000000000000000000000000000000000000000000000000000000000
--------------------------------------------------------------------------
00000000000000000000000000000000000000000000000000000000000000000000000000
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