[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Re: stability
On 12:04 12/03/2005, Simon Josefsson said:
I think PR-29 is a useful example to consider when deciding how much
trust you should place in the UTC's stability guarantees.
> Also, IDNA apps depend on tables for converting from various non-Unicode
> encodings to Unicode. This is another place where instability could
> affect lookups, potentially even in dangerous ways. Stringprep and IDNA
> already mention this issue in their Security Considerations sections.
I try to understand the best way for ccTLDs to approach the variations in
Unicode tables and a possible punycode update. I also try take into account
the impact of the revision of BCP 047 (RFC 3066) engaged by the WG-ltru
(which seems mainly motivated by W3C concerns).
1. the IDN Tables are in fact the list of Unicode points accepted by a
Registry manager to form domain names in the "virtual zone" related to that
table. This table may or may not be related to a language in the way RFC
3066 means it. Let for example take ASCII 256, it does not include every
French characters, but includes characters used in many European countries.
I don't think any European ccTLD Registry Manager would object to support
all the ASCII 256 characters and to add the missing ones which would not
conflict - but would be faced with the problem of their ASCII equivalent
(French "oe" as 2 characters instead of one, for example). The reason why
is that there are/will be more and more words of European languages being
accepted in other languages. Specially in commercial, cultural, societal
areas which are a good source of domain name. Just let think about sport
champions, singers, etc.
This means that the list of accepted characters would not relate to a
determined language, while the IANA calls for its registration in
documenting it with the language/script attributes which are those
considered by the WG-ltru draft.
We therefore need another tag system for the IDN tables. This tag is
attached to many management aspects, registrant support, homograph control,
etc. It must also be clearly documented to the SLD zone managers if one
want to push them to respect the same rules for 3+LD labels.
This could lead to a virtual zone management BCP (preferable?), or to an
IDN Table support part in the WG-ltru Draft (my first idea, but I am less
inclined to that now, unless we propose that a IDN Table is made of the
addition of the language tables accepted by the TLD Registry Manager, but
obviously IESG has not followed my suggestion of a more complete tag review
permitting to document tag operations, like tag(eu)=sigma european language
tags).
I think this does not create a problem for the European scripts. But I have
no idea about the non Latin scripts?
2. the IDN Tables adopted by a ccTLD Manager (either code by code, or as
the addition of IDN language tables) are contractual annexes to the IDN
registration contracts. The ccTLD Manager should word in its terms and
conditions what happens if the code supporting a character is changed, or
if punycode is updated resulting in the same change. My understanding is
that such a change will result in having the registered IDN to transcode in
another ACE label.
- if this label does not exist the two versions should be registered for free.
- if the new label conflicts with an existing label, we have a problem -
but I understand this is unlikely?
- I understand we should not have the case of a stringprep failure where
there was none before? Or that this should then result in an update?
Then the ccTLD will have to document its new IDN Table. This means that she
will add the new code to the table. But she will not be able to remove the
former code since it is still used, but she should be able to mention that
it cannot be used in requests of names - only in free CNAMEs.
Also a program should help the ccTLD Registry to parse her table to make
sure all the listed codes are correct (last date of change).
Am I correct with this?
jfc
=====================================================
For your convenience:
Draft: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-00.txt
Charter: http://ietf.org/html.charters/ltru-charter.html
gmane: http://dir.gmane.org/gmane.ietf.ltru
If you were Bcced for information and not familliar with the IETF process:
http://www.ietf.org/rfc/rfc2026.txt
http://www.ietf.org/rfc/rfc2418.txt
http://www.ietf.org/rfc/rfc3934.txt
http://www.ietf.org/rfc/rfc3669.txt
http://www.ietf.org/rfc/rfc3160.txt
http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
=====================================================
Jon Postel (RFC 1591): "The IANA is not in the business of deciding
what is and what is not a country. The selection of the ISO 3166 list
as a basis for country code top-level domain names was made with
the knowledge that ISO has a procedure for determining which
entities should be and should not be on that list."
=====================================================
Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing the
same thing, choose one. If a previous design, in the Internet context
or elsewhere, has successfully solved the same problem, choose the
same solution unless there is a good technical reason not to.
Duplication of the same protocol functionality should be avoided as far as
possible, without of course using this argument to reject improvements."
=====================================================
It seems that what works for countries and ISO 3166 since 1978 should
apply to languages and to ISO 693.
=====================================================