Unicode-1-1 and UTF-7 (was: draft-klensin-net-utf8-07)

Alfred HÎnes wrote:

Just an observation, hp-roman8 isn't registered, and apparently
my MUA has no clue what it is, this might be a case where using
the old RFC 1641 Unicode-1-1 could be "better" from my POV (you
likely have reasons for your choice, if it's only your software
you could trick it into using another charset in the address).

> if we accept the draft to change protocols (or at least one,
> Telnet), wouldn't it make sense to declare this draft to also
> obsolete RFC 1641, (RFC 1642 -->) RFC 2152, and perhaps other
> early IETF I18N documents as well?

That's IMO not the job of net-utf8, it's not about updating the
IANA charset registry, or deprecating (this version of) UTF-7.

It is a good idea to do this, and I *think* that Mark Davis (one
of the 1641-1642-2152 co-authors) and others also consider these
charsets as obsolete or historic.  But maybe not bad enough to
post a "1641 + 2152 to historic" Internet draft with some IANA
considerations about the charset registry.

If you feel that it should be done now how about trying it ?  In
the worst case your draft doesn't make it, no harm done compared
with the status quo.

> In particular, the registrations for legacy representations of
> Unicode should be marked "deprecated" in the IANA charset
> registry; to this end, a substantive IANA Considerations
> section needs to be added to the draft.

AFAIK you can't "unregister" a registered charset, you can only
update the registry entry with an updated source (that would be
your draft).  The source would need references to the old 2152
and 1641 definitions, because you don't want to change or copy
the charset definitions, you want to say that the charsets are
obsolete and the defining document historic.

Users of the charset registry trying to find out what UTF-7 *is*
still need to find the definition.  I sometimes get UNICODE-1-1
delivery status notifications from old mailers, so it's not yet
as dead as you might hope.  

Check http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=1641
and http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=2152 to
see if there are later standards with normative references to
RFC 1641 or 2152, if yes this "decruft" procedure could be more
ambitious than I think.

 Frank