Hi Chris... Thanks for all the answers. They certainly help my understanding.
> The primary purpose is to carry human readable strings in Internet
> protocols.
I managed to figure this out, but thanks!
> in order to be approved as an IETF standards track protocol, new protocols
> need to support Internationalization (I18N) and consider
> Multilingualization (M17N).
This is good. It would have been nice to see your proposal before it reached
the stage of being an RFC, but I guess we can't all follow every development
in every field.
> Unicode does not solve the multilingual problem for CJK or blind people.
Oh, sigh... To that, I have to say, "you've been listening to the wrong
propaganda engines". There isn't really much of a multi-lingual problem with
CJK text, but I don't have the bandwidth to go into that here. (If anyone
else has the energy or time, they can chime in now...)
OK, you need language tagging of Unicode text.
> Rather than breaking the nice substring searching characteristics of UTF-8
AHA!!! Now you're onto something interesting. Why? What's the requirement
you're trying to fulfill? What's the bang-for-buck?
> I'm actively involved in designing the ACAP protocol
Don't know it. Is there an RFC? A brief explanation might do.
> Can you suggest how I might fix any specific problems you've identified?
Hm. I think the proposed format is, no personal affront intended, a hideous
abomination that will only harm the situation and the acceptance of Unicode,
and I think you should withdraw the RFC and do something different. For
instance, you could invent a simple, higher level protocol on top of Unicode,
and express it in plain text. Then you should encode THAT in UTF-8 and pass
it around on the net as UTF-8-encoded-whatever. You should *NOT!* use any
so-called "unused" bits in the published, widely-accepted UTF-8 standard.
While that might be clever (and M. Crispin is a clever man) not all cleverness
is desirable or appreciated in all contexts.
> A longer discussion of the topic is in RFC 2130 -- a document which carries
a
> lot of respect in the IETF community.
See Page 28. It's really gratifying to know this document has some actual
impact!
Keep on talking,
Rick
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT