RE: alpha v0.2

[Andrew Draper <ADRAPER@altera.com>]

My comments are inline below.  I have one general question, which relates to
the language in the document.  Are we using "should" and "must" in the
strong sense, or in the conventional language sense.  If we are using them
in the strong sense then I think some of the requirements have used the
wrong word.

> 2.1 Compatibility and Interoperability
>
> The best solution is one that maintains complete compatibility with 
> current DNS standards as long as it meets the other requirements in 
> this document. 
> 
> [JS: ?? i am not sure if there can be such solution!! :P]

The solutions I am thinking of come pretty close.  The only thing in the
existing DNS which is fundamentally incompatible with IDNs is the character
set restriction!  Thus I think this is a good requirement.

(Of course if the requirements are contradictory then there is a problem).

> "There can be no "flag days" nor a split DNS."
> 
> [JS: I do not understand what this means. I think we need to elaborate
> this further]

I assumed "no flag days" was a well known expression.  It means that the
protocol should allow DNS components to be upgraded in any order, at any
time, with new features available to all who have upgraded and no problems
to those who haven't.

The "no split DNS requirement" is essentially the same as the earlier
paragraph starting "The same name resolution request..."

> In addition, IDN must
> 
> 1. provide a record which can contain internationalised text 
>    (similar to TXT RR). [1 request to remove this as it is not IDN]

If we are to internationalise the DNS then we should internationalise
everything which contains human representable characters.  I think this
consists of labels and TXT records at the moment.

> --- need comments ---
> Must allow I18C in DNS queries.
> Must allow I18C in DNS RR response.
> Must allow I18C in DNS TXT records. 
> Must allow I18C in DNS CNAME records.
> Must allow I18C in DNS PTR records.
> ---

I disagree with "Must allow I18C in DNS TXT records" for backwards
compatibility reasons - in any event this requirement contradicts the one
above.  I think all the rest are covered by the overall goal of IDN which I
would summarise as "Must allow I18C in DNS labels".  Thus I suggest removing
this block of text.

> 2.3 Canonicalization

I don't think there is any disagreement that the protocol will need to use a
canonicalisation algorithm (not if we have "must retain case-insensitive
comparison for ASCII" as a minimum).  The only question is what should that
algorithm be.

As I understand it, the requirements document will be passed on to a group
of DNS experts who will then define a protocol.  People in this group
understand case folding issues and the like.  DNS experts don't necessarily.
I think the canonicalisation algorithm should be clearly specified in the
requirements document (preferably by reference).

If we decide to leave this problem unsolved in the requirements then it will
still need to be solved before a protocol can be designed - that just slows
down the process a bit more.

> 5. Security Considerations
> 
> Any solution that meets the requirements in this document must not 
> be less secure than the current DNS. Specifically, the mapping of 
> internationalized host names to and from IP addresses must have the 
> same characteristics as the mapping of today's host names.

Not sure I understand what the second sentence means.  In any event, the
DNS does more than just map names to and from IP addresses.

I suggest replacing it with "In particular, a protocol to allow the use of
IDNs must be compatible with DNSSEC."

    Andy