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

Mykyta Yevstifeyev <evnikita2@gmail.com> Sat, 11 June 2011 03:48 UTC

Return-Path: <evnikita2@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E7C22800B for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jun 2011 20:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.495
X-Spam-Level:
X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0l+41zY1c12 for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jun 2011 20:48:45 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 65FA7228007 for <apps-discuss@ietf.org>; Fri, 10 Jun 2011 20:48:45 -0700 (PDT)
Received: by fxm15 with SMTP id 15so2205303fxm.31 for <apps-discuss@ietf.org>; Fri, 10 Jun 2011 20:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rDo7Hm+90BjN/v6Bqyisl8JmtzqN66NRG3zCgGrIkZA=; b=w8lkRLWR5tj+WkqLieuebjAflgwBnxK4AO7MQc5QlW9yYHBTv8mz8UgdEr2lERYZ76 rNwuKtKCqHNUr7zIS5XQ4FUg07j/a4bdvTKVFju34/GQSgVG+h2m9QhxsISXaX0FrRhQ UqAumIbsn20xaerm4VaC54Q5UYTpZgKyxH/30=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dPN400FnktSw5dS67zI644MwYOUJ8hsgB6KVY2hZGr0811YT+QJHEo/PUlVidUASVM ftALIa6oG2/b1Wukc4iTBu6hbczIycTOvQGvdfajwkD4Iep4P+E7+IwWaJj5RNYn8RBU H4+sj6/E1D6/B0YgwTfCBdxDm8Ot+kAvq27MI=
Received: by 10.223.32.142 with SMTP id c14mr2725885fad.59.1307764124204; Fri, 10 Jun 2011 20:48:44 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id e16sm1268930fak.41.2011.06.10.20.48.42 (version=SSLv3 cipher=OTHER); Fri, 10 Jun 2011 20:48:43 -0700 (PDT)
Message-ID: <4DF2E5C7.30002@gmail.com>
Date: Sat, 11 Jun 2011 06:49:27 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
References: <4DF23976.4080301@gmail.com> <4DF23BD4.1080802@gmx.de> <61A6FA2030E93A75C586A699@PST.JCK.COM>
In-Reply-To: <61A6FA2030E93A75C586A699@PST.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Apps-discuss list <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Documenting UTF-1 as Historic
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jun 2011 03:48:46 -0000

10.06.2011 21:25, John C Klensin wrote:
>
> --On Friday, June 10, 2011 17:44 +0200 Julian Reschke
> <julian.reschke@gmx.de>  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
>>> http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis. Any
>>> thoughts on this?
>>> ...
>> Yes. Why do we care?
> Mykyta,
>
> 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.
Actually it did; the aforementioned document refers to Annex G of 
ISO/IEC 10646:1993 as authoritative definition of UTF-1.
>     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.
I don't consider it is necessary to document each bad idea as Historic, 
but rather an outdated idea, an idea, (citing RFC 2026) fallen into 
disuse or disfavor.  Certainly, documenting bad ideas is a bad idea 
(sorry for pun), but documenting ideas, which were once used but now 
not, and which were considered to be good makes some sense (at least, 
for the history)...
> 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.
Understand.
> Perhaps your next proposal should be a URI type for SUPDUP.
I wouldn't be so ironic, though...
> 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.
Actually, I also don't see at least when (and at most why) was 734 moved 
to historic, which is very unhelpful.  A good question is why all other 
SUPDUP-related RFCs weren't moved to Historic as well (2 of which are 
Proposed Standards, and they depend on Historic document).
>   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).
Mykyta Yevstifeyev
>      john
>
>
>