ietf-822
[Top] [All Lists]

Re: An appeal for closure

1991-12-26 16:06:00
I have no problem with putting RFC-CHAR on a standards track route
personally, although there are obviously a number of issues that have
to be attended to in the document itself (e.g. what constitutes
compliance, security issues (not a null point by _any_ means), and so forth).
However, technical work of this scale on character set standardization 
within the Internet appears to me to be beyond the purview of this group
as it is currently chartered. At the very least there needs to be widespread
knowledge that such work is in fact being done, since people who are not
interested in electronic mail but who are _very_ interested in character
set work may in fact have missed this development thread completely.

The work has been widely exposed, to character set groups like the ISO
SC2 WGs, the SC22 WGs including WG20 which actually have coded charater
set naming and conversion on their programme of work, and the character
set group  of the European standards organisation CEN, and I am working
closely with these people to produce the most accurate draft.
I believe my PR machine has spread the word to almost anybody who
has an interest in character set work.

Thus, desireable as it may in fact be, I see no chance whatsoever that
RFC-CHAR will reach any sort of closure before MIME does. (People more
involved with the formal level of things should feel free to contradict me
at this point.) From my perspective RFC-CHAR is just beginning its
journey, and the fact that it has received relatively little comment
on this list thus far is indicative less of closure than of widespread
ignorance of the significance of this work.

I believe RFC-CHAR has had something like a year of review (the first
draft appeared february 1991) and with implementations running in
production since february 1990, it seems to be quite well tested.

I don't mean to criticize Keld here at all. He has done a fantastic thing in
this document. It is practically the only character set proposal I've seen
(and I've read them all -- 8859, 2022, 10646 drafts, Unicode, and so on)
that makes sense to me as an evolutionary and extensible approach to the
mess. If anything this is a criticism of the IAB and IETF, which has
ignored character set issues for so long and as a result left its other
working groups (like this one) adrift in a sea of conflicting proposals. The
fact that Keld has been forced to use this group and no other as a sounding
board for his ideas and efforts is, in my opinion, a crock, but it is a
crock that is in no way Keld's problem.

I am also pursuing the issue in other groups as noted above.

But email is a major area for such a specification, the other
people that I have worked together with are also in (OSI) email
or related areas such as X.500. So communications is the only major
applications field I have been in touch with to date.

I think it is unfortunate if a group chartered with the solution
of character set problems in internet mail cannot consider themselves
to be able to accept RFCs like this.

Keld

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