Hello I have several comments as follows, I hope you can give the comments your consideration. To my understanding, the Requirement is a general IDN requirement,so first,it should have a good framework for many possible solutions,however ,there are so many hints or restrictions. I suggest we should find them and delete them. second, the Requirement should take future possible resolutions into account,unfortunately,it has been paid so much attention to transitional and temporal ways. Maybe we can think the requirement in general ,complete and long term way, and can include the temporal thoughts, similar to IPV6 case. And, I have some comments on certain items in requirement: [1] It MUST make the minimum number of changes to existing protocols on all layers of the stack. It MUST continue to allow any system anywhere to resolve any internationalized domain name. ��any system��should be any idn-compatible system [4] The protocol MUST NOT require that the current DNS cache servers be modified to support IDN. If a cache server can have additional functionality to support IDN better, this additional functionality MUST NOT cause problems for resolving correctly functioning current domain names. If the requirement is subject to IDN final solution, it should not have restrictions on cache server. If the requirement is only considering temporal solution, the requirement should clearly say it is a temporal requirement. I suggest we change the [4] to: The IDN compatible cache server MUST NOT cause problems for resolving correctly functioning current domain names. [5] A caching server MUST NOT return data in response to a query that would not have been returned if the same query had been presented to an authoritative server. This applies fully for the cases when: - The caching server does not know about IDN - The caching server implements the whole specification - The caching server implements a valid subset of the specification what is specification?it need a clarification. [33] An IDN-capable resolver or server SHALL NOT generate more traffic than a non-IDN-capable resolver or server would when resolving an ASCII-only domain name. The amount of traffic generated when resolving an IDN SHALL be similar to that generated when resolving an ASCII-only name. The traffic is a important factor ,but not only.We should also consider the efficiency, simplicity and other things of the IDN protocol. I suggest we delete this item because we should find a solution which has the best ratio among little traffic, good efficiency, simplicity and others. [35] Within a single zone, the zone manager MUST be able to define equivalence rules that suit the purpose of the zone, such as, but not limited to, and not necessarily, non-ASCII case folding, Unicode normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or raditional/simplified Chinese equivalence. Such defined equivalences MUST NOT remove equivalences that are assumed by (old or local-rule-ignorant) caches. I do not know why we have this item? If the equivalence rules are be defined by zone manager,the global ones will be inconsistent and ambiguous. Thanks for your consideration wenhui __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/
