Subject: draft-klensin-net-utf8-07

From: Alfred Hönes <[email-masked]>
Date: Thu, 10 Jan 2008 19:01:57 +0100 (MEZ)

Hello,
after studying the Internet-Draft authored by you,
         draft-klensin-net-utf8-07 ,
I once again would like to point you to a few small textual flaws
I found left in the current version of that memo, and some metadata
considerations.

(1)  Section 4, last paragraph -- word replication

Please remove the spurious duplicate word 'were' :

   Were such changes to be were made, the IETF would be ...
---                        ^^^^^
   Were such changes to be made, the IETF would be ...

(2)  Appendix B

(2a)  list item # 4., 3rd-to-last line -- typo

    s/unlkely/unlikely/

(2b)  last paragraph

The draft says:

   It is worth noting that the telnet IAC character (an octet consisting
   of all ones, i.e., %xFF) itself is not a problem for UTF-8.  [...]

For clarification, I suggest to amend this sentence,
explaining why that's the case, for instance:

   It is worth noting that the telnet IAC character (an octet consisting
   of all ones, i.e., %xFF) itself is not a problem for UTF-8, because
   it is not a legal codepoint in UTF-8 and as such can easily be
   discerned by a telnet style command processor that will strip the
   entire command sequences from the data stream before handing the
   proper Network Unicode text to the application layer (or a user
   interface).  [...]

(3)  Relationship to other documents

The last item in D.2 says:

   o  Clarified relationships to existing protocols, stressing that this
      is not, in itself, a proposal to change any of them.

This is in contrast to the heading of the memo saying:
  Obsoletes: RFC 698 (if approved)      <-- Telnet extended ASCII Option
  Updates: RFC854 (if approved)         <-- Telnet

IMHO, the above statement does not hold strictly any more with
the current draft text.

But 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?

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.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 19 Jan 2008 12:00:34 +0100

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.

> 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

---

From: Chris Newman <[email-masked]>
Date: Thu, 24 Jan 2008 16:37:25 -0800

> to this end, a substantive IANA Considerations section needs to be

I think these would distract from the primary focus of net-utf8.  However, they 
are good proposals and if you wrote them up in a separate document, it's very 
likely you could find a friendly area director to sponsor them ;-)

                - Chris

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 25 Jan 2008 11:43:04 +0100

Chris Newman wrote:

> good proposals and if you wrote them up in a separate document, it's
> very likely you could find a friendly area director to sponsor them ;-)

The 2616bis folks, friendly or otherwise, could then reference it,
the "HTML5" cabale could also make use of it.  At the moment it is
not clear whose "fault" UTF-7 is, but they do want to get rid of it.

 Frank