ietf-822
[Top] [All Lists]

For shame (Was: Re: RFC 2047 and gatewaying)

2003-01-15 14:04:52

Henry Spencer wrote:

non-ASCII newsgroup names are already in substantial use.

Really?  What percentage of the total number of newsgroups?
20%?  That would barely qualify as "substantial". I'd be
surprised if it amounts to a tiny fraction of that.

More to the point: how many in the millenium in which the
charter referring to "urgent attention" which formed the WG
was written? That's the same charter which says

  The Goal of this working group is to publish a standards-track
  successor to RFC 1036 that with particular attention to backward
  compatibility, formalizes best current practice and best
  proposed practice. The Group shall also aid and/or oversee the
  production of other Usenet related Internet Drafts and Standards.

"Standards-track" has a very specific meaning which precludes
the Usefor draft as it now stands due to a number of issues.
"Particular attention to backward compatibility" also has quite
specific meaning.

So where's the standards-track successor to RFC 1036 that pays
particular attention to backward compatibility? Oh that's
right, there isn't one.  OK, so how many of the "other Usenet
related Internet Drafts and Standards" has the WG produced? None.

Certainly by 1998, to use Bernstein's milestone, all the pieces were
in place to deal with the "urgent attention" issues (possibly
excepting newsgroups, which would not seem to be particularly urgent
considering that some five years later there is a mere handful
of affected newsgroups) in accordance with "The Goal" of
the WG. In 1998 MIME was in it's fifth year of deployment and third
incarnation, complete with full charset and language tagging in
compliance with the BCP RFC 2277.  The specific issue of
newsgroups could have been dealt with as one of the "other"
documents provided for in the charter.  The real shame is that
the pointless bickering has been going on for years in spite of
repeated calls to get on with a document addressing the issues
on which consensus (more on that below) can be reached, deferring
the remaining issues for a second document.  The bickering is
pointless precisely because The Goal of producing a *standards-track*
successor to RFC 1036 *with particular attention to backward
compatibility* ought to have resolved a large number of issues
a long time ago; issues that are still being (pointessly) debated.

Returning to consensus: I was amused and somewhat bewildered to
see that a poll of something like 9:8 was reported as "rough
consensus" of the WG.  As a past chairman of a[n] (IEEE) standards
committee and as present chairman of a section of an international
professional society of engineers, I have a clear concept of what
consensus means. Maybe I'm just an old fogey, but here's what it
*doesn't* mean (_recent_ dictionary definition additions notwithstanding):
- a particular vote count (there are separate terms, e.g. plurality,
  majority, 3/4 vote, etc.)
- there is disagreement on substantive matters
nor is consensus necessarily limited to a synonym for "unanimity",
which is one of the traditional dictionary definitions of consensus.
As I have always observed and practiced use of the term, "consensus"
means:
+ there is at least one proponent of the proposition in question
+ there is no opposition on substantive grounds to the proposition.
Those two simple principles are very powerful.  Consensus, as I have
thus summarized it, permits moving forward with action where there is
no opposition to a proposition, but for which there may be considerable
apathy (unlike requiring a majority of affirmative support to proceed).
It also prevents giving the imprimatur of the group to some proposition
which has serious shortcomings (unlike a majority). That is most
definitely a positive attribute, as it forces open debate on the
substantive issues, and such debate often leads to resolution of
the issues. That is not to say that a spurious objection (i.e. not
on substantive issues) can stall action, nor should it open debate
on frivolous matters -- that is why committes have chairmen; to
focus the group on the important issues, and to remain on track with
the group's purpose and goal.  In rare cases where consensus cannot be
reached, the proposition can be deferred for later discussion, or in
even rarer cases, tabled.

I would therefore like to suggest to the Usefor WG Chair that the WG
again consider extracting from the current Usefor draft, modified
where necessary, those items which are consistent with the goal of
the WG as documented in its charter (including the charter's
stipulation that the 1036 successor be eligible for standards-track
status and that it pay particular attention to backward compatibility),
with the objective of meeting that stated goal of the WG.  Remaining
content to be deferred to later discussion and action once that goal
is on its way to being achieved.

It is clear from recent discussion, much of it on ietf-822 only, that
the current draft has several provisions which preclude standards-track
status and that backward compatibility (in the sense in which that term
is used in the IETF) has not been properly addressed.  It follows that
the draft in its entirety has no chance of meeting the WG goal.

The review of the draft with that objective in mind need not be a lengthy
or difficult process; it should be fairly clear where there are backwards
compatibility issues, where there are standards-track issues (ref. RFC 2026),
and relevant BCP RFCS (e.g. 2277) can provide guidance -- this isn't rocket
science, and there has been considerable discussion both on usenet-format
and ietf-822.


<Prev in Thread] Current Thread [Next in Thread>