Subject: RFC 1345 mnemonics table not consistent with Unicode 3.2.0

From: Ben Finney <[email-masked]>
Date: Fri, 24 Aug 2007 07:55:40 +1000

Howdy all,

In attempting to implement some of the RFC 1345 mnemonic sequences,
I've been trying to match up the information in that document with the
Unicode data for version 3.2.0. Unfortunately, at some point it seems
the two have become inconsistent with each other.

I searched the list archives but couldn't find any previous discussion
of this specific issue, so I put some time into collecting information
on the differences. I hope these findings can lead to an update to RFC
1345 that makes the mnemonics table consistent with the Unicode
standard.

The attached program 'check-rfc1345' (also uploaded to
<URL:http://pastebin.ca/668483>) runs under Python 2.4 or later, and
uses the standard library module 'unicodedata' to check the table of
mnemonics in RFC 1345. Its input is the table, stripped of any blank
lines or other data not part of the table, and ensuring one complete
entry per line.

For each line of input, it will attempt to parse the space-delimited
fields of the described table, and then attempt to match up the
ordinal number (the hexadecimal character number) and character name
against the corresponding data in the Unicode data set. Where there is
a discrepancy it will output a message describing the problem.

The file 'rfc1345-mnemonics.txt' (uploaded to
<URL:http://pastebin.ca/668469>) is the table I've reconstructed from
'rfc1345.txt' as described above. Running this table through
'check-rfc1345' gives errors for 267 of the table entries. The output
I get is attached to this message as 'rfc1345-unicode-errors.txt'
(uploaded to <URL:http://pastebin.ca/668473>).

These errors can be grouped as follows, with one or more examples of
the program output and my comments on possible remedies:

Entries which are not conformant with the table definition
----------------------------------------------------------

<stdin>:1854: ordinal 'indicates' name 'unfinished (Mnemonic)'
        Unicode 3.2.0 has no name 'unfinished (Mnemonic)'
        Not a valid ordinal

There is only one entry in this category. It has only two fields
instead of the specified three.

To aid automatic parsing of the table it would be helpful if this
entry was either removed (since there is no mnemonic listed), or
somehow made conformant with the specification for the table.

Entries with extraneous information in the name
-----------------------------------------------

<stdin>:248: ordinal '0138' name 'LATIN SMALL LETTER KRA (Greenlandic)'
        Unicode 3.2.0 has no name 'LATIN SMALL LETTER KRA (Greenlandic)'
        Unicode 3.2.0 ordinal 0138 has name 'LATIN SMALL LETTER KRA'

<stdin>:461: ordinal '0402' name 'CYRILLIC CAPITAL LETTER DJE (Serbocroatian)'
        Unicode 3.2.0 has no name 'CYRILLIC CAPITAL LETTER DJE (Serbocroatian)'
        Unicode 3.2.0 ordinal 0402 has name 'CYRILLIC CAPITAL LETTER DJE'

Entries of this sort have extraneous commentary in the "name" field,
but without this the name does match the corresponding Unicode
character.

To aid automatic parsing of the table, these entries should have only
the Unicode character name in the name field.

Entries with different names for the same character
---------------------------------------------------

<stdin>:241: ordinal '0131' name 'LATIN SMALL LETTER I DOTLESS'
        Unicode 3.2.0 has no name 'LATIN SMALL LETTER I DOTLESS'
        Unicode 3.2.0 ordinal 0131 has name 'LATIN SMALL LETTER DOTLESS I'

<stdin>:974: ordinal '2103' name 'DEGREE CENTIGRADE'
        Unicode 3.2.0 has no name 'DEGREE CENTIGRADE'
        Unicode 3.2.0 ordinal 2103 has name 'DEGREE CELSIUS'

These entries have names that are, for some reason, different to the
current Unicode name for the character; however it is clear to a human
reader that they describe the same character.

To aid automatic parsing of the table, these entries should simply be
correctly named as per the Unicode data.

Entries with different names that may describe a different character
--------------------------------------------------------------------

<stdin>:380: ordinal '0388' name 'GREEK CAPITAL LETTER EPSILON WITH ACUTE'
        Unicode 3.2.0 has no name 'GREEK CAPITAL LETTER EPSILON WITH ACUTE'
        Unicode 3.2.0 ordinal 0388 has name 'GREEK CAPITAL LETTER EPSILON WITH TONOS'

<stdin>:1413: ordinal '3004' name 'IDEOGRAPHIC DITTO MARK'
        Unicode 3.2.0 has no name 'IDEOGRAPHIC DITTO MARK'
        Unicode 3.2.0 ordinal 3004 has name 'JAPANESE INDUSTRIAL STANDARD SYMBOL'

It isn't clear, without a thorough knowledge of orthography and
related issues, whether these differing names describe the same
character.

If these should be determined to be the same character, the mnemonic
table entry name should be made the same as the current Unicode name.

If not, a decision needs to be made as to whether the entry should be
removed, replaced with the corresponding Unicode character using the
same mnemonic, or added as a separate entry (with the existing
mnemonic) along with the current Unicode character (with a separate,
new mnemonic).

Entries with different names that clearly describe different characters
-----------------------------------------------------------------------

<stdin>:898: ordinal '1f01' name 'GREEK PSILI AND ACUTE ACCENT'
        Unicode 3.2.0 has no name 'GREEK PSILI AND ACUTE ACCENT'
        Unicode 3.2.0 ordinal 1f01 has name 'GREEK SMALL LETTER ALPHA WITH DASIA'

<stdin>:903: ordinal '1f06' name 'GREEK DIAERESIS AND VARIA'
        Unicode 3.2.0 has no name 'GREEK DIAERESIS AND VARIA'
        Unicode 3.2.0 ordinal 1f06 has name 'GREEK SMALL LETTER ALPHA WITH PSILI AND PERISPOMENI'

These entries have a name that does not appear in the current Unicode
data, and the ordinal is clearly assigned to an altogether different
character from the one described by the table.

If the named character exists in the current Unicode standard, its
correct ordinal and name should be updated in the table.

If not, a decision needs to be made as to whether the entry should be
removed, replaced with the corresponding Unicode character using the
same mnemonic, or added as a separate entry (with the existing
mnemonic) along with the current Unicode character (with a separate,
new mnemonic).

Entries whose character appears at a different ordinal
------------------------------------------------------

<stdin>:902: ordinal '1f05' name 'GREEK PSILI AND PERISPOMENI'
        Unicode 3.2.0 ordinal 1f05 has name 'GREEK SMALL LETTER ALPHA WITH DASIA AND OXIA'
        Unicode 3.2.0 name 'GREEK PSILI AND PERISPOMENI' has ordinal 1fcf

<stdin>:1680: ordinal 'fe90' name 'ARABIC LETTER BEH INITIAL FORM'
        Unicode 3.2.0 ordinal fe90 has name 'ARABIC LETTER BEH FINAL FORM'
        Unicode 3.2.0 name 'ARABIC LETTER BEH INITIAL FORM' has ordinal fe91

These entries name a Unicode character whose current ordinal is
different to that specified in the table.

The table should be updated with the correct ordinal number.

Entries that may not be Unicode characters
------------------------------------------

<stdin>:1819: ordinal '001e' name 'RECORD SEPARATOR (IS2)'
        Unicode 3.2.0 has no name 'RECORD SEPARATOR (IS2)'
        Unicode 3.2.0 has no character ordinal 001e

<stdin>:1888: ordinal 'e022' name 'ARABIC LETTER ALEF FINAL FORM COMPATIBILITY (IBM868 144)'
        Unicode 3.2.0 has no name 'ARABIC LETTER ALEF FINAL FORM COMPATIBILITY (IBM868 144)'
        Unicode 3.2.0 has no character ordinal e022

These entries give a character name not in the Unicode data, and the
ordinal is not in the Unicode ISO 10646 character set as specified in
the RFC.

If characters from different character sets are to be specified in
this table, then perhaps each table entry should specify which
character set contains the character at that ordinal.

Alternatively, the decision could be made that characters not found in
ISO 10646 (as specified in the description of the table) should not
have an entry in the table.

It is also possible that these *are* Unicode characters, but neither
the name nor ordinal match the current data. In this case, the table
entry should be updated to contain the correct Unicode ordinal and
exact character name.

Thanks for reading this far; I hope this analysis is useful, and look
forward to an update for RFC 1345 that addresses these issues.

-- 
 \    "Simplicity and elegance are unpopular because they require hard |
  `\                work and discipline to achieve and education to be |
_o__)                                appreciated."  -- Edsger Dijkstra |
Ben Finney

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 23 Aug 2007 21:34:53 -0700

Hi -

> From: "Ben Finney" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, August 23, 2007 2:55 PM
> Subject: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
...
> forward to an update for RFC 1345 that addresses these issues.
...

(1) What be the point of an update to RFC 1345?  A modern developer
should be going directly to the ISO and Unicode documents for reference.
The rest of the material in there is close to being in the category "historical
curiosity," IMO.

(2) If *you* think an update would be a worthwhile exercise,  you have
thereby nominated yourself for writing the internet draft for an update.
Good luck finding someone to review it.

Randy

---

From: Ben Finney <[email-masked]>
Date: Sat, 25 Aug 2007 12:48:40 +1000

> should be going directly to the ISO and Unicode documents for

RFC 1345 gives mnemonic strings for many useful characters, and there
are a number of character input systems that use this standard for the
purpose of standard key sequences for entering those characters.

I'm not aware of a Unicode or ISO table similar to the table of
character mnemonics in RFC 1345, leaving an update to the RFC as the
best option I can see. I'd be happy to learn of a freely-implemented
popular standard mnemonic table that is equal or better.

> (2) If *you* think an update would be a worthwhile exercise, you
> have thereby nominated yourself for writing the internet draft for
> an update.

Perhaps. I don't have anything close to the knowledge that obviously
went into the writing of RFC 1345.

> Good luck finding someone to review it.

I'll take that as your note of disinterest in the topic. Thanks for
discussing so far.

I wonder if there aren't others closer to IETF than me who also feel
RFC 1345 serves a useful purpose as described above.

-- 
 \       "It is seldom that liberty of any kind is lost all at once."  |
  `\                                                     -- David Hume |
_o__)                                                                  |
Ben Finney

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 24 Aug 2007 22:49:37 -0700

Hi -

> From: "Ben Finney" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, August 24, 2007 7:48 PM
> Subject: Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
>
...

RFC 1345 is *not* a standard.  It is an informational RFC.
 
Randy

---

From: Ben Finney <[email-masked]>
Date: Sat, 25 Aug 2007 16:33:09 +1000

"Randy Presuhn" <[email-masked]> writes:

> Ben Finney wrote:

Duly noted.

The issue remains that the informational RFC presents useful mnemonics
for many characters, and there doesn't appear to be such a thing from
Unicode or ISO. That's the point of an update to RFC 1345: it serves a
purpose that I can't see served comparably well elsewhere.

-- 
 \        "I used to work in a fire hydrant factory. You couldn't park |
  `\                       anywhere near the place."  -- Steven Wright |
_o__)                                                                  |
Ben Finney

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 25 Aug 2007 00:08:35 -0700

Hi -

> Sent: Friday, August 24, 2007 11:33 PM
...
> purpose that I can't see served comparably well elsewhere.

There's plenty of stuff, e.g.:

http://www.unicode.org/charts/PDF/U0000.pdf
http://www.unicode.org/charts/charindex.html
http://www.unicode.org/charts/symbols.html

But the names and mnemonics aren't necessarily the same as what RFC 1345
uses, and the ones RFC 1345 uses are not what I've seen any application use.
Yes,  the recode library is already "out there", but I think it serves mainly to underscore
the point that complete alignment is probably neither likely nor desirable.

Still, if you think this is worth doing, please write an i-d and hope for comments!

Randy

---

From: Ben Finney <[email-masked]>
Date: Sat, 25 Aug 2007 17:37:24 +1000

"Randy Presuhn" <[email-masked]> writes:

> Ben Finney wrote:
> > The issue remains that the informational RFC presents useful
> > mnemonics for many characters, and there doesn't appear to be such
> > a thing from Unicode or ISO. That's the point of an update to RFC
> > 1345: it serves a purpose that I can't see served comparably well
> > elsewhere.
> 

I can't help thinking you're missing what I'm saying about the table
of character mnemonics in section 3 of RFC 1345. It presents three
fields per table entry: a character mnemonic, the ordinal number, and
the character name. The mnemonics are sequences of ASCII characters as
mnemonics for (mostly) non-ASCII characters.

None of the links you point to above have anything like this. They
have character *names* (descriptions) and character *ordinals*
(numbers), but not the *mnemonics* (sequences of ASCII characters with
mnemonic correspondence to the entry character) that are the point of
the table I'm referring to.

If you thought I was interested merely in a correspondence between
character ordinal and name, I can see why you'd point to the
references above. But I'm specifically talking about the mnemonics
table, which I don't see improved upon outside RFC 1345.

> Still, if you think this is worth doing, please write an i-d and

Again, I'm hoping on this list to attract the attention of someone
closer to knowledge about what went into RFC 1345. I thank you for
your encouragement so far.

-- 
 \     "I must say that I find television very educational. The minute |
  `\   somebody turns it on, I go to the library and read a book."  -- |
_o__)                                                     Groucho Marx |
Ben Finney

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 25 Aug 2007 16:41:11 -0700

> purpose that I can't see served comparably well elsewhere.

You might not find much enthusiasm in the character-encoding community 
for the mnemonics published in RFC 1345, and later as the so-called 
"repertoiremap" in ISO/IEC TR 14652.  These have been widely criticized 
for their incompleteness, (real or perceived) arbitrariness, and lack of 
extensibility to scripts not already covered.

Most people will agree that "a plus apostrophe" makes a handy mnemonic 
for "a with acute," and "c plus comma" works well for "c with cedilla," 
but the system tends to break down rather quickly after that, with Greek 
letters identified by an asterisk, Cyrillic by an equal sign, Hebrew by 
a capital letter and plus sign, Arabic by a small letter and plus sign, 
etc.  There are numerous exceptions to these guidelines, especially when 
the letters in question don't map cleanly to Basic Latin, and a large 
number of non-ideographic characters have no mnemonic at all, even some 
that were defined in ISO 10646 at the time RFC 1345 was published.

That is why you are unlikely to find an update to RFC 1345 that brings 
the mnemonics up to date with 10646/Unicode: the task is almost 
impossible, given the limitations of the system.

The motivation for inventing these mnemonics seems to have been to 
specify characters "in a coded character set independent way," which was 
perhaps a sensible goal in 1992 when the Universal Character Set was 
quite a bit less universal.  Today, however, virtually all non-10646 
character sets are mapped to 10646 code points, not to alphabetic 
mnemonics.  Almost any charatcer that can be found in a national or 
industry charset can be found in 10646.  The need for a notation 
independent of 10646 has passed.

Most modern operating systems allow the user to change the keyboard 
layout (or define one's own) to gain access to frequently used 
characters, and many applications and OS's define a special keystroke 
(such as Ctrl+Q) that allows entry of any arbitrary character by 
Unicode/10646 code point.  You might consider one or both of these 
approaches as an alternative to using RFC 1345 mnemonics for data entry. 
Or, you can go ahead and use the mnemonics as they are, but resign 
yourself to the fact that they will probably never be updated.

Speaking only for myself, as always.

--
Doug Ewell · Fullerton, California, USA · RFC 4645 · UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

---

From: Ben Finney <[email-masked]>
Date: Sun, 26 Aug 2007 12:11:00 +1000

[People, please don't send me copies of list messages by mail. I'm
subscribed to the list and read it via a non-mail interface.]

"Doug Ewell" <[email-masked]> writes:

> "repertoiremap" in ISO/IEC TR 14652.  These have been widely
> criticized for their incompleteness, (real or perceived)
> arbitrariness, and lack of extensibility to scripts not already
> covered.

Thanks for this. I agree that, for *encoding* and *naming*, the
mnemonics aren't much use anymore; we have superior encodings and
Unicode names, so the properties you (correctly) ascribe to the
mnemonics in RFC 1345 are not much use for those purposes.

The "repertoiremap" of ISO/IEC TR 14652 is apparently meant to be for
character transmission and translation only. It seems more extensible
for that purpose than the mnemonic approach in RFC 1345.

There is one specific application of the RFC 1345 mnemonics for which
I've not seen a superior reference: direct character *input* at a
keyboard using an input method program. There are numerous programs
(e.g. Emacs, SCIM) that support the RFC 1345 character mnemonic table
as an input method for typing key sequences to input the corresponding
characters.

> Most people will agree that "a plus apostrophe" makes a handy
> mnemonic for "a with acute," and "c plus comma" works well for "c
> with cedilla," but the system tends to break down rather quickly
> after that, with Greek letters identified by an asterisk, Cyrillic
> by an equal sign, Hebrew by a capital letter and plus sign, Arabic
> by a small letter and plus sign, etc.

So long as the table follows some kind of system (and the definition
of the RFC 1345 character mnemonic table does at least explain the
scheme it uses for those character sets), it is still useful as a
means of remembering short, discrete mnemonics for a large set of
characters.

> There are numerous exceptions to these guidelines, especially when
> the letters in question don't map cleanly to Basic Latin, and a
> large number of non-ideographic characters have no mnemonic at all,
> even some that were defined in ISO 10646 at the time RFC 1345 was
> published.

Yes, the system does have its limits; a mnemonic table cannot
reasonably expect to map mnemonic pure-ASCII keyboard characters to
*every* set of characters in ISO 10646. But with those limits
acknowledged, the mnemonic system can be useful for those character
sets where there *is* a reasonable expectation of such a mapping.

> That is why you are unlikely to find an update to RFC 1345 that
> brings the mnemonics up to date with 10646/Unicode: the task is
> almost impossible, given the limitations of the system.

Indeed. My initial comment was merely that even the characters that
*are* covered by the mnemonic table are not in accord with the current
Unicode data. To the extent that the character mnemonic table is
useful, it is surely undermined if the data are wrong.

> specify characters "in a coded character set independent way," which
> was perhaps a sensible goal in 1992 when the Universal Character Set
> was quite a bit less universal.

I'm beginning to understand the gap of understanding here; I've been
approaching this discussion caring *only* about the character mnemonic
table in RFC 1345, whereas others have (reasonably) approached the
discussion in the context of the entire RFC document and its apparent
purpose.

> Today, however, virtually all non-10646 character sets are mapped to
> 10646 code points, not to alphabetic mnemonics.

This is true for the purpose of *encoding*, but for the purpose of
*input* at a non-remapped largely-ASCII keyboard, input method
programs certainly do map ASCII mnemonic sequences to non-ASCII
characters.

> Almost any charatcer that can be found in a national or industry
> charset can be found in 10646.  The need for a notation independent
> of 10646 has passed.

I think it's clear that the domain of keyboard character input clearly
needs brief mnemonic ASCII sequences, not numeric ordinals or
descriptive character names, to map to the desired characters.

Thanks very much for the discussion, it's becoming clearer now. Two
further questions:

I'd like to discuss this with the people who made the original RFC
1345 character mnemonic table. How would I get in touch with the
authors of RFC 1345?

It wasn't my intention to write a new discussion draft, but it seems
that since my purpose is significantly different to the broad purpose
of RFC 1345 that a new draft aimed at the purpose I have in mind may
be warranted. What should I read (URLs please) before doing so?

-- 
 \         "If we don't believe in freedom of expression for people we |
  `\         despise, we don't believe in it at all."  -- Noam Chomsky |
_o__)                                                                  |
Ben Finney

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 30 Aug 2007 14:51:51 -0700

> be warranted. What should I read (URLs please) before doing so?

The original author of RFC1345 has his email address in the  
document.  Other people who were involved seem to be listed in the  
Acknowledgements.  If you recognize any of their names in postings to  
this list I'd suggest they might be fair game for further queries :)

For the guidelines on doing a new draft, please read http:// 
www.ietf.org/ietf/1id-guidelines.html.

Another place you might start discussion of similar work is on the  
Apps Discuss list -- https://www1.ietf.org/mailman/listinfo/discuss

I suggest that list because although the IETF hasn't done anything  
quite like standards for keyboard entry before, at least the Apps  
area seems like the closest layer.  There are also i18n experts  
(although Randy and Doug did already reply to this thread).

If the IETF were to consider something like RFC1345 today, there  
would be a lot of questions like
  - whether a registry would be more appropriate than a static  
document, after all it's a set of fields that might be extended,
  - how one would determine whether any two implementations were  
interoperable, or if that's a sensible concept in this context
  - whether another standards organization wouldn't be a better place  
for detailed char set mappings

For all I know those conversations occurred with RFC1345, but we'd  
still have them again :)

thanks
Lisa Dusseault

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 31 Aug 2007 01:00:22 +0200

Lisa Dusseault wrote:
>
>
> If the IETF were to consider something like RFC1345 today, there would 
> be a lot of questions like 
I just feel like being blunt today:

RFC 1345 was a bad idea at the time. It was published without IETF 
review, and contains errors, both in design and in details, that would 
have been caught if people who could have done the review had been asked 
to do so.

RFC 1345 is best ignored. If you want to name characters, use Unicode.

                    Harald

---

From: John C Klensin <[email-masked]>
Date: Thu, 30 Aug 2007 19:23:29 -0400

--On Friday, 31 August, 2007 01:00 +0200 Harald Alvestrand
<[email-masked]> wrote:

>> For all I know those conversations occurred with RFC1345, but
>> we'd  still have them again :)
> RFC 1345 was a bad idea at the time. It was published without
> IETF review, and contains errors, both in design and in
> details, that would have been caught if people who could have
> done the review had been asked to do so.
> 

Harald, Ben has pointed out one important use for something like
1345, which involves references to characters in programming
languages and command interfaces.  The Unicode names are bad
news for that, I certainly don't want 

	characterNamed(SLOBBOVIAN LOWER CASE COMBINATION
	LEFT-HANDED SPANNER)

in those contexts, and that is what Unicode would give me.  Our
current solution to that problem seems to be U+[N[N]]NNNN, which
is pretty unattractive (except when compared to all of the other
alternatives).  On the other hand, one could argue that 1345
inadvertently proves that no shorter set of mnemonics is going
to work across all of Unicode without becoming pretty arbitrary
and discriminatory against scripts not familiar to the creator
as well as difficult to extend.

     john

---

From: Ned Freed <[email-masked]>
Date: Thu, 30 Aug 2007 16:29:11 -0700 (PDT)

> as well as difficult to extend.

Exactly so. To the extent RFC 1345 is problematic, it is because its domain of
applicability is quite limited. But within that narrow domain it actually can
perform a useful function.

And this only serves to point out that the reasoning behind quite a few of the
criticisms I've seen of RFC 1345 over the years, including, I regret to say,
Harald's latest outburst, is on fairly shakey ground: Just because something
doesn't solve the general case of the problem (which at it happens is almost
certainly unsolvable) doesn't mean it cannot provide a useful solution to a
much narrower problem. The baby may not be that large, but that's not
sufficient justication for tossing it with the bathwater.

The other serious issues with RFC 1345 are that it contains a number of errors
and is more than a little out of date. Of course these could be corrected with
a revision.  However, given the extremely  hostile reception this document and
underlying approach continues to receive in the IETF, I see little chance of
these issues being corrected - I for one would be happy to help work on an
update which among other things would need to make the scopy of applicability
much clearer, but I frankly don't have the energy to deal what I am confident
would be a major struggle to get the resulting document through the process. So
we're effectively stuck with the current version, warts and all. More's the
pity.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Aug 2007 20:02:22 -0400

The biggest problem I see with RFC 1345, other than its somewhat
ambiguous and uncertain applicability, is that IETF doesn't seem
well-positioned to maintain it.  There aren't many people who
participate in IETF who have the kind of expertise needed to do a
competent job of revising it.  And I think we'd have a difficult time
attracting such expertise to work on an informational document.  And of
course we have limited resources that might be better focused on efforts
that are closer to our core competency.

---

From: Ben Finney <[email-masked]>
Date: Fri, 31 Aug 2007 10:04:33 +1000

[People, again, please don't send me copies of messages to the list.]

> Apps Discuss list -- https://www1.ietf.org/mailman/listinfo/discuss

Thanks very much for the useful pointers.

> would be a lot of questions like [...]

Yes, those need to be addressed, and thank you for raising them.

Okay, that's it for this thread I suppose; if anything further is to
happen, I (or someone else) need to raise a new draft. Thanks again
to everyone who contributed to my understanding.

-- 
 \       "Holy contributing to the delinquency of minors, Batman!"  -- |
  `\                                                             Robin |
_o__)                                                                  |
Ben Finney

---

From: Ned Freed <[email-masked]>
Date: Thu, 30 Aug 2007 18:59:31 -0700 (PDT)

> well-positioned to maintain it.

That argument would probably hold if we were attempting to build this from
scratch or trying to build something that covers more than the area RFC 1345 is
actually useful for. But we aren't doing that. What's needed here is a cleanup,
not a fresh start.

> There aren't many people who
> competent job of revising it.

I quite simply disagree with this assessment. As long as the scope is correct
we have ample expertise for this. This is not the IETF of circa 1990 and quite
a few of us have gained considerable expertise in a bunch of different areas we
knew next to nothing about back then.

> And I think we'd have a difficult time
> attracting such expertise to work on an informational document.

No, what we'll have is a difficult time due to politics.

> And of course we have limited resources that might be better focused on
> efforts that are closer to our core competency.

I'm a bit unclear on what these resources are in this volunteer organization
that we have that can be focused on tasks as needed. But hey, if we have them,
then I'm all for using them on the really critical stuff. And a RFC 1345 update
definitely does not qualify as  critical.

In any case, I have always stated that I for one would be more than willing to
work on this (and I happen to have considerable expertise in this area) were it
not for the difficulty I predict will arise in getting it through the process.
Now, perhaps in your opinion my priorities are completely messed up, but with
all due respect, that's just not a call you get to make.

				Ned

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Aug 2007 19:43:34 -0700

Hi -

> From: "Ned Freed" <[email-masked]>
> To: "Keith Moore" <[email-masked]>
> Cc: "Lisa Dusseault" <[email-masked]>; "Ned Freed" <[email-masked]>; "IETF General Discussion Mailing List"
<[email-masked]>; "Ben Finney" <[email-masked]>; "Harald Alvestrand" <[email-masked]>; "John C Klensin"
<[email-masked]>
> Sent: Thursday, August 30, 2007 6:59 PM
...
...

Since I've spoken up much earlier in this thread...

I have no objection to the idea of an independent submission for an *informational*
RFC updating or superceding RFC 1345, if there are folks willing to do the work
and who think it would be worthwhile.  However, I also have no interest in spending
any time working on it or reviewing it.

Randy

---

From: Keith Moore <[email-masked]>
Date: Fri, 31 Aug 2007 01:24:52 -0400

> then I'm all for using them on the really critical stuff.
well, I _wish_ we could focus resources on some critical areas.  it
doesn't seem like we have a shortage of critical work to do.

I don't have an inherent objection to people working on a revision to
1345, or to IETF publishing it, as long as there are enough people and
sufficient expertise to do it competently.   at the same time I
recognize that IESG and the RFC editor have finite resources, and that
it is sometimes prudent for them to limit their organizations' commitments.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 31 Aug 2007 02:00:56 -0400

--On Thursday, 30 August, 2007 16:29 -0700 Ned Freed
<[email-masked]> wrote:

> Exactly so. To the extent RFC 1345 is problematic, it is
> because its domain of applicability is quite limited. But
> within that narrow domain it actually can perform a useful
> function.

Agreed. And perhaps that suggests a way forward if people are
willing to do the work (from my point of view, your efforts and
Ben's would probably be most of what is needed; I'd be happy to
review and maybe make whatever small contributions I could).

> And this only serves to point out that the reasoning behind
> quite a few of the criticisms I've seen of RFC 1345 over the
> years, including, I regret to say, Harald's latest outburst,
> is on fairly shakey ground: Just because something doesn't
> solve the general case of the problem (which at it happens is
> almost certainly unsolvable) doesn't mean it cannot provide a
> useful solution to a much narrower problem. The baby may not
> be that large, but that's not sufficient justication for
> tossing it with the bathwater.
> 
> The other serious issues with RFC 1345 are that it contains a
> number of errors and is more than a little out of date. Of
> course these could be corrected with a revision.  However,
> given the extremely  hostile reception this document and
> underlying approach continues to receive in the IETF, I see
> little chance of these issues being corrected - I for one
> would be happy to help work on an update which among other
> things would need to make the scopy of applicability much
> clearer, but I frankly don't have the energy to deal what I am
> confident would be a major struggle to get the resulting
> document through the process. So we're effectively stuck with
> the current version, warts and all. More's the pity.

Maybe I am, for a change, a little more optimistic about this
than you are.   While it was not the case a few years ago, I
think an increasingly large fraction of the community is coming
to understand the principle that i18n tools, such as Unicode,
are, in many or most cases, just tools to permit localization
while permitting an international base.  Viewed in that light, a
set of code-mnemonics for a specific, identified, subset of
characters is reasonable and a core problem with 1345 is that it
attempts to be much too broad.

If an offspring of 1345 were defined as having, e.g., only
European languages using Roman-derived scripts in scope, then I
think there is more than adequate expertise around to review a
proposal and sufficient stability to not be affected by Unicode
changes, and that there should be no significant issue with IETF
sign-off or even standardization.

Just my opinion, obviously.

    john

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 31 Aug 2007 08:13:10 +0200

> as well as difficult to extend.
Two different threads here: one about the idea of mnemonics, the other 
about this specific document's implementation of it...

Actually I used 1345 mnemonics in a fairly hefty piece of work back in 
1995 (draft-alvestrand-lang-char, I think the latest published version 
was -03). Ten years later, I'm unable to figure out what characters I 
was trying to point to in some cases; somehow, characters snuck in where 
"it's obvious that the mnenmonic for X has to be *X", but 1345 doesn't 
provide a definition for "*X". For cases where the correct mnemonic was 
"+X" and the draft specifies "*X", it's impossible to tell by anything 
short of character-by-character lookup that I goofed.

Based on that experience in working with 1345, I claim that the idea of 
a larger set of "mnemonics" than what one can memorize in an hour or two 
for handling data in a wider character set than the one you're writing 
in is a Bad Idea. Tried it, didn't work.

In programming language constructs intended to be read and maintained by 
people who aren't familiar with the script they're maintaining and 
aren't willing to bother looking up the code every time they use it, 
"characterNamed(SLOBBOVIAN LOWER CASE COMBINATION LEFT-HANDED SPANNER)" 
is exactly the right construct, in my opinion; if people can read the 
script, an UTF-8 environment is a far cleaner solution than any possible 
mnemonic set.

The second part of my criticism involves the tables in 1345 that claim 
to show existing character sets and what characters they contain. These 
tables are defined inconsistently with their base specifications (ISO 
646 IRV-NO is a 94-character ISO 2022-based charcter set, but presented 
in 1345 as if it was an 128-character one, without explaining what 
control character set it is matched with to create that set, for 
instance), and, as Ned says, contain errors.

Both are good reasons to ignore 1345 as it currently stands, in my opinion.

If anyone wants to resolve the second by creating a revision, feel free. 
But I don't see how it can help with the first one.

                           Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 31 Aug 2007 08:39:38 +0200

One part I didn't catch when first replying to this thread was Ben's 
focus on input methods.
I'm curious about that - could someone give more details?

In particular:

- Is there any consistency among the input methods in how mnemonics are 
framed? That is, how do you tell the IME that you're starting a 
mnemonic? Do you switch into "mnemonic mode" and type several of them, 
or do you enter them as <leadin> <mnemonic> <leadin> <mnemonic>?

- How do the input methods deal with finding the end of a mnemonic? 
While a lot of character mnemonics of 1345 are 2-characer, there are a 
lot that are not , and there doesn't seem to be a consistent character 
set for "intermediate" and "ending" characters ("16" is "VULGAR FRACTION 
ONE SIXTH", while "16." is "NUMBER SIXTEEN FULL STOP").

I'm curious to learn about whether the IMEs (EMACS and SCIM was 
mentioned) actually use 1345 or some adapted subset of it - if the 
latter, documenting the adapted subset that has proved useful in 
practice might be a worthwhile exercise.

                     Harald

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 31 Aug 2007 11:04:13 +0200

> news for that, I certainly don't want 

I wouldn't be suprised if that was the case. There is an old paper
referenced (*) by the groff_char manual pages which discusses some
principles one can use if you only have two ASCII chars to name
things. There must an even older paper somewhere from Kelt and me
which discusses these principles.

	jaap

(*) An  extension  to the troff character set for Europe, E.G. Keizer, K.J.
       Simonsen, J. Akkerhuis; EUUG Newsletter, Volume 9, No. 2, Summer
       1989

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 31 Aug 2007 16:32:13 +0200

> popular standard mnemonic table that is equal or better.

Hi Ben.  The Unicode Character Database files contains, at least as far
as I understand your request, a list of code points and their mnemonic
strings.  The description of the database is available from:

ftp://ftp.unicode.org/Public/UNIDATA/UCD.html

The database itself is available from:

ftp://ftp.unicode.org/Public/UNIDATA/

in the UnicodeData.txt file:

ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt

Unlike the IETF, the Unicode Consortium has agreed to change and now use
copying conditions on the character database that is compatible with
free software licenses (in particular, the license permits
modifications).  The license is available from:

http://www.unicode.org/copyright.html#Exhibit1

Note that unless the author of RFC 1345 agrees, you don't have similar
permission to extract the tables and use them in your implementations.

/Simon

---

From: "Doug Ewell" <[email-masked]>
Date: Fri, 31 Aug 2007 11:33:28 -0700

Simon Josefsson <simon at josefsson dot org> wrote:

> Hi Ben.  The Unicode Character Database files contains, at least as 
> far as I understand your request, a list of code points and their 
> mnemonic strings.  The description of the database is available from:
>

None of those provides a list of short mnemonic strings for Unicode 
characters, such as a' for "a with acute" and o/ for "o with stroke" and 
j3 for "Greek iota below."  This is what Ben is looking for.