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

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 10 Jun 2011 18:34:14 +0300

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?

Mykyta Yevstifeyev

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Jun 2011 17:44:20 +0200

On 2011-06-10 17:34, Mykyta Yevstifeyev wrote:
> 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
> ...

Yes. Why do we care?

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 10 Jun 2011 18:48:22 +0300

>> http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis. Any thoughts on
We care to have a formal record of UTF-1, as I explained above.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Jun 2011 17:56:29 +0200

> We care to have a formal record of UTF-1, as I explained above.

Why do we care if we do not use it?

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Jun 2011 19:45:43 +0200

> http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf as a basis.  Any thoughts
> on this?

Yes.  The time of the IESG and the IETF  and the RFC Editor is precious.
 In order for the work to be done it should be important to do for the
sake of guiding actual implementations.  As such, let me restate
Julian's question:

    * Which implementors or what user base are in need of knowing either
      the proper application of UTF-1 in our various specification or
      that it should not be used (e.g., marked Historic)?

If you cannot enumerate at least a small group where this has actual
impact, let me suggest that we allow for this gap in our compendium of RFCs.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Jun 2011 14:25:11 -0400

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

>> 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.   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).

    john

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Jun 2011 20:44:44 +0200

On 10 June 2011 17:34, Mykyta Yevstifeyev wrote:

> I suppose it could be formally documented
> in Historic RFC

In theory.  But the IETF (etc.) never used UTF-1
for anything.  ISO deprecated UTF-1 years ago,
and of course they still formally document it:

http://www.itscj.ipsj.or.jp/ISO-IR/178.pdf

Admittedly that page is hard to find, but OTOH
the en-wikipedia UTF-1 article lists it as its
one and only external reference (at the moment).

> Any thoughts on this?

Unless somebody did it already:  It would be a
very good thing to deprecate UTF-7 "officially"
in an RFC, because UTF-7 is at least in theory
an IETF invention.

There was an AD willing to sponsor this effort
in 2007, maybe the new ADs also like the idea.
The author of the UTF-7 RFC has no objections
(and should certainly get credits for his stunt
 to register a "moving target" as IANA charset
 before UTF-8 existed, and when Unicode was
 still only registered with a version number).

As far as HTML5 and WhatWG care about standards
they should also welcome if UTF-7 is "formally"
dead.  If you volunteer for this effort you can
also talk about UTF-1 "just for the records" if
you wish.

-Frank

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 11 Jun 2011 06:49:27 +0300

10.06.2011 21:25, John C Klensin wrote:
> 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
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)...
> 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...
> 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
Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 11 Jun 2011 07:17:42 +0300

> in an RFC, because UTF-7 is at least in theory
Indeed; however if we want to deprecate its use, we should provide 
reasonable justification for it.  Maybe a reason may be "UTF-7 was 
written specially for RFC 822 purposes, which is obsolete", but I am not 
sure if it is appropriate.
> also talk about UTF-1 "just for the records" if
I'll then firstly discuss the issue with ADs before taking any action.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 13 Jun 2011 16:08:32 +0900

I agree with what others have said, and will stay short (and 
unfortunately a bit blunt):

UTF-1, like most UTF-X (where X isn't 8/16/32, and maybe also 7) are 
totally irrelevant. Spending time on such stuff is just wasteful. The 
'historic' description is to relabel stuff that was in an RFC without a 
'historic' label. That doesn't apply to UTF-1. UTF-1 is in the IANA 
charset registry (http://www.iana.org/assignments/character-sets), but 
so are several others that are completely useless, too. Enough said.

Regards,   Martin.

On 2011/06/11 0:34, Mykyta Yevstifeyev wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>