Re: [apps-discuss] Documenting UTF-1 as Historic

John C Klensin <> Fri, 10 June 2011 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7048411E807C for <>; Fri, 10 Jun 2011 11:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LB1-SVWKzUuA for <>; Fri, 10 Jun 2011 11:25:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6411511E8075 for <>; Fri, 10 Jun 2011 11:25:14 -0700 (PDT)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1QV6OO-000Ni4-5n; Fri, 10 Jun 2011 14:25:12 -0400
Date: Fri, 10 Jun 2011 14:25:11 -0400
From: John C Klensin <>
To: Mykyta Yevstifeyev <>
Message-ID: <61A6FA2030E93A75C586A699@PST.JCK.COM>
In-Reply-To: <>
References: <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Apps-discuss list <>
Subject: Re: [apps-discuss] Documenting UTF-1 as Historic
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jun 2011 18:25:15 -0000

--On Friday, June 10, 2011 17:44 +0200 Julian Reschke
<> wrote:

> On 2011-06-10 17:34, Mykyta Yevstifeyev wrote:
>> Hello,
>> There are a number of RFCs defining transformation formats of
>> ISO 10646/Unicode - various UTFs. I mean RFC 3629 (UTF-8),
>> RFC 2152 (UTF-7), RFC 2781 (UTF-16) and others. However, I've
>> noticed UTF-1 isn't properly documented (or, at least, there
>> is no formal record of it). However, since UTF-1 has never
>> been widely used, I suppose it could be formally documented
>> in Historic RFC, taking
>> as a basis. Any
>> thoughts on this?
>> ...
> Yes. Why do we care?


Let me say that a little more strongly.

As far as I know, it isn't used on the Internet and definitely
is not used in any IETF protocol.  The document you cite was a
proposal to ISO/IEC JTC1/SC2, not to the IETF.  It went nowhere
in SC2 and, in particular, was not incorporated into ISO/IEC
10646 or any closely-related document.   To the best of my
knowledge, it was never proposed for use in the IETF, not that
it would make much difference if it had been.

If we were to expand our goals to include documenting (as
Historic) every bad idea proposed to some other SDO, or even
every bad idea proposed to the IETF, we would be very busy
indeed -- the population of bad ideas, or even possibly-good
ideas that did not achieve any level of standardization--  is a
rather extensive and target-rich environment.

Seriously, even proposing this has the appearance of either bad
judgment or a desire to waste the community's time.  I've tried
to be supportive of your efforts to tie up assorted loose ends
in the RFC Series and gaps in protocol definitions where that
work is actually useful, but this one is really over the line.

Perhaps your next proposal should be a URI type for SUPDUP.
While RFC 734 has been designated as HISTORIC, RFCs 736, 746,
747, and 749 have not been and there is no published analysis of
why SUPDUP didn't take off and why 734 was identified as
HISTORIC.  I think doing such a URI, or trying to develop that
documentation, would be a waste of time too, but at least SUPDUP
was believed by many of us to be a good idea, was defined in the
IETF (or actually in its predecessor), and was deployed and used
(although not, IMO, enough).