Re: alpha v0.2

[James Seng <jseng@pobox.org.sg>]

Andrew Draper wrote:
> 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.

The word "should" and "must" are used as according to the BCP RFC2119. But do
feel free to comment on the use of "should" and "must" in this doc. It is
quite important to make sure we get the correct requirement lies down as
"must", "should" or "may".
 
> 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.

Great! :-) I look forward to seeing you working on a implementation document
once we finish with this requirement doc. :-)
 
> > "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.

Ok, I will add:

"IDN should allow upgraded to be done in any order, at any time, with new
features available to all who have upgraded and impose no new problems for
those who has not upgrade"
 
> 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.

Ok, will remove the TXT RR requirment.
 
> > 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.

The closest we have now is the Unicode TR-15. But anyone who has attempts to
do this will have nightmare :( at least i did...
 
> > 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."

"Any solutions that meets the requirements in this document must not be less
secure than the current DNS. Specifically, the operation functionity of
internationalized host name resolving must have the the same characteristics
as the resolving of current English host name. In addition, IDN must be
compatible with DNSSEC."

-James Seng