Re: 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.
=====================================================