--On Friday, 31 August, 2007 01:00 +0200 Harald Alvestrand
<harald(_at_)alvestrand(_dot_)no> 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]]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.
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf