Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
Hi - > From: "Ben Finney" <[EMAIL PROTECTED]> > To: > Sent: Thursday, August 23, 2007 2:55 PM > Subject: RFC 1345 mnemonics table not consistent with Unicode 3.2.0 ... > Thanks for reading this far; I hope this analysis is useful, and look > 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
"Randy Presuhn" <[EMAIL PROTECTED]> writes: > (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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
Hi - > From: "Ben Finney" <[EMAIL PROTECTED]> > To: > Sent: Friday, August 24, 2007 7:48 PM > Subject: Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0 > > "Randy Presuhn" <[EMAIL PROTECTED]> writes: > > > (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. > > 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. ... RFC 1345 is *not* a standard. It is an informational RFC. Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
"Randy Presuhn" <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > "Randy Presuhn" <[EMAIL PROTECTED]> writes: > > > > > (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. > > > > 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. > ... > > RFC 1345 is *not* a standard. It is an informational RFC. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
Hi - > From: "Ben Finney" <[EMAIL PROTECTED]> > To: > Sent: Friday, August 24, 2007 11:33 PM > Subject: Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0 ... > 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. There's plenty of stuff, e.g.: http://www.unicode.org/charts/PDF/U.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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
"Randy Presuhn" <[EMAIL PROTECTED]> 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. > > There's plenty of stuff, e.g.: > > http://www.unicode.org/charts/PDF/U.pdf > http://www.unicode.org/charts/charindex.html > http://www.unicode.org/charts/symbols.html 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 > hope for comments! 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
[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 PROTECTED]> 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. > > 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. 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. > 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. 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 a
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
On Aug 25, 2007, at 7:11 PM, Ben Finney wrote: 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? 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___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
Lisa Dusseault wrote: 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 :) 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
--On Friday, 31 August, 2007 01:00 +0200 Harald Alvestrand <[EMAIL PROTECTED]> wrote: >> For all I know those conversations occurred with RFC1345, but >> we'd still have them again :) > 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, 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]], 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
> --On Friday, 31 August, 2007 01:00 +0200 Harald Alvestrand > <[EMAIL PROTECTED]> wrote: > >> For all I know those conversations occurred with RFC1345, but > >> we'd still have them again :) > > 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, 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]], 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
[People, again, please don't send me copies of messages to the list.] Lisa Dusseault <[EMAIL PROTECTED]> writes: > 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 Thanks very much for the useful pointers. > If the IETF were to consider something like RFC1345 today, there > 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
> 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. 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 > participate in IETF who have the kind of expertise needed to do a > 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
Hi - > From: "Ned Freed" <[EMAIL PROTECTED]> > To: "Keith Moore" <[EMAIL PROTECTED]> > Cc: "Lisa Dusseault" <[EMAIL PROTECTED]>; "Ned Freed" <[EMAIL PROTECTED]>; > "IETF General Discussion Mailing List" ; "Ben Finney" <[EMAIL PROTECTED]>; "Harald Alvestrand" <[EMAIL PROTECTED]>; "John C Klensin" <[EMAIL PROTECTED]> > Sent: Thursday, August 30, 2007 6:59 PM > Subject: Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0 ... > 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. ... 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
> 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
--On Thursday, 30 August, 2007 16:29 -0700 Ned Freed <[EMAIL PROTECTED]> 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
John C Klensin wrote: --On Friday, 31 August, 2007 01:00 +0200 Harald Alvestrand <[EMAIL PROTECTED]> wrote: 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]], 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
> 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 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
Ben Finney <[EMAIL PROTECTED]> writes: > "Randy Presuhn" <[EMAIL PROTECTED]> writes: > >> (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. > > 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
Simon Josefsson 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: 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 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. -- 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
Hi - > From: "Doug Ewell" <[EMAIL PROTECTED]> > To: > Cc: "Simon Josefsson" <[EMAIL PROTECTED]>; "Ben Finney" <[EMAIL PROTECTED]> > Sent: Friday, August 31, 2007 11:33 AM > Subject: Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0 ... > 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. ... What is "mnemonic" also depends on the language in use, even if written using Latin alphabet. For example, RFC 1456 was much more mnemonic for Vietnamese, and still sees some use not only as an input method, but as an encoding, despite the ubiquity of Unicode support. I see mail almost weekly that uses RFC 1465. I don't recall seeing mail that used RFC 1345. But please don't read this as voicing support for RFC 1456! My point is solely that context is important in determining what is "mnemonic". Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 1345 mnemonics table not consistent with Unicode 3.2.0
John C Klensin wrote: > Ned Freed wrote: [...] >> 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). +1 A version of Lynx uses these mnemonics for Unicode points when it's forced to limit its output to "codepage 850" characters. The effect was acceptable for en and de documents, or at least better than displaying question marks. I'd probably prefer to see a clearly delimited hex. representation in most cases, but that's a matter of taste and besides not the application Ben has in mind. So if somebody has a real application for these mnemonics they'd clearly wish that it's up to date and correct as far as possible. An I-D also discussing the alternatives and limitations would be fine. > 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. I'm not sure about "reasonable", but it's certainly "possible". > 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. Drawing the line will be difficult, RFC 1345 tried to cover more than MES-1. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
