For all those people just dying to know about this character (U+19DA),
the latest Unicode code chart listing it is here
http://www.unicode.org/charts/PDF/U1980.pdf
and the name of the character is NEW TAI LUE THAM DIGIT ONE.
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3(_at_)gmail(_dot_)com
On Thu, May 26, 2011 at 7:19 AM, Simon Josefsson
<simon(_at_)josefsson(_dot_)org> wrote:
The IESG <iesg-secretary(_at_)ietf(_dot_)org> writes:
The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'The Unicode code points and IDNA - Unicode 6.0'
<draft-faltstrom-5892bis-04.txt> as a Proposed Standard
Dear IESG,
Is the intention that this document will update RFC 5892 or not?
The document does not contain a "Updates:" header but the draft name
suggests otherwise to me, hence my question.
If the document does not update RFC 5892 (or some other document), I
support publishing this document because it will not affect my
implementation of RFC 5892.
If the document updates RFC 5892, in order to remain compliant with the
RFCs I would have to modify my implementation and make a backwards
incompatible change. Today U+19DA converts to xn--pkf. With this
document, I would have to raise an error for that input instead. I
believe a case-by-case evaluation for each modified code-point is a good
way to determine whether or not to add an exception in the IDNA tables.
I haven't seen any discussion why U+19DA is so harmful that it has to be
disallowed. On the contrary, everyone appears to agree that the code
point is not widely used and the implications of continue permitting it
are minor. Thus I would support publication of the document after
adding U+19DA to table BackwardCompatible (G) as PVALID.
I do realize that I may be in the rough part of the consensus here,
which happens, but I want to provide my feedback for the record and
allow the decision process to proceed. At least I will be able to shift
blame to someone else if/when my users gets confused by this. :-)
/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf