Subject: [dns-dir] Fwd: TLD Names and RFC 1123

From: Olaf Kolkman <[email-masked]>
Date: Thu, 8 Oct 2009 10:35:19 +0100

I believe the discussion needs to move away from the directorate to a  
more public venue.

At the risk of forwarding a message without explicit consent: Here is  
a parallel comment, that had hit the IAB list but I'm not sure it  
ended elsewhere. (Since it is purely technical I am comfortable  
forwarding)

--Olaf

Begin forwarded message:

> From: John C Klensin <[email-masked]>
> Date: September 9, 2009 11:26:59 PM GMT+01:00
> To: Olaf Kolkman <[email-masked]>
> Cc: IAB IAB <[email-masked]>
> Subject: Re: TLD Names and RFC 1123
>
>
>
> --On Wednesday, September 09, 2009 18:47 +0200 Olaf Kolkman
> <[email-masked]> wrote:
>
>>
>> John,
>>
>> http://tools.ietf.org/html/draft-liman-tld-names-00
>>
>>
>> I am not quite sure what you mean by "1123" problem but if you
>> mean disambiguating 1123, then this document is about that.
>
> Ok.  I've looked through it and have two problems, one minor
> (because, in principle, it could still be overridden) and one
> major:
>
> Minor: There is really nothing ambiguous about the text in 1123.
> The relaxation for leading digits can't possibly apply to TLDs
> because the text about TLDs says "... the highest-level
> component label will be alphabetic" -- no digits, no hyphens:
> alphabetic.  I note that, if one ignores the "IDN testbed",
> nothing that ICANN has done so far violates that rule.  The
> current practice is still "alphabetic".
>
> Major: Given that changing the rule from "alphabetic" is one of
> those "changing engines in flight" situations, good and
> conservative design argues that we should make the minimal
> change need to accommodate a real and demonstrated need.  I note
> that "real and demonstrated need" is considerably different from
> "maybe someone would like to do this".
>
> That minimal change for IDNs is to allow IDNs in what the
> IDNA2008 drafts call "A-label form", i.e., an
> ASCII-compatible-encoding, using reversible Punycode conversion
> from valid IDNs labels, with the "xn--" prefix, but requiring
> that the native-character ("Unicode") form consist of letters
> only.  No compelling need has been shown for permitting digits
> or hyphens (or other characters), in all-ASCII (non-IDN) labels,
> nor for permitting those characters in the Unicode form of IDNs.
>
> This is not just my usual paranoia about making changes broader
> than we fully understand.  There is actually a case, involving
> "bidirectional" Unicode strings (more or less those containing
> characters from scripts written right to left), in which leading
> or trailing digits can result in label migration such that the
> order in which labels may appear in display format becomes
> different from the order in which they are transmitted "on the
> wire" or appear in native-DNS format.   The problem can occur in
> lower levels of the DNS as well, but, if one permits the "bad"
> cases in the root, it is all over -- no amount of registry (zone
> administration) discipline, even if one could count on it, would
> be sufficient to prevent the label migration problem from
> occurring.   For those interested in a more detailed explanation
> of that problem, see draft-ietf-idnabis-bidi.
>
> To the extent to which we care more about identifier integrity
> than about the "domain names market", we need to hold the line
> and support an absolutely minimal change.
>
> Expressed in ABNF, that minimal change would be to make the
> syntax:
>
>  tldlabel = traditional-tld-label / idn-label
>  traditional-tld-label = 1*63(ALPHA)
>  idn-label = Restricted-A-label
>    ; Restricted-A-label is an A-label as defined in
> draft-ietf-idna-defs
>    ; converted from (and convertible to) a U-label that is
> consistent
>    ; with the definition in draft-ietf-idna-defs _and_ that is
> further restricted
>    ; to contain only Unicode characters of General Category "L".
>
> Note that "L" contains several subcategories.  The list is
>
> gc ; L         ; Letter            # Ll | Lm | Lo | Lt | Lu
> gc ; LC        ; Cased_Letter      # Ll | Lt | Lu
> gc ; Ll        ; Lowercase_Letter
> gc ; Lm        ; Modifier_Letter
> gc ; Lo        ; Other_Letter
> gc ; Lt        ; Titlecase_Letter
> gc ; Lu        ; Uppercase_Letter
>
> although the IDNA restriction eliminates the last two and
> several of characters in the others.
>
> I also note, based on Dave T's comments during the retreat and
> subsequently, that permitting IDN TLDs doesn't make the job of
> keeping APIs that support native-UTF-8 domain names any easier.
> We are far enough down this path that it may be impossible to
> reverse course on that matter, but it is a major step and should
> not be taken lightly, IMO.
>
>    john
>
>

________________________________________________________

Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Thomas Narten <[email-masked]>
Date: Thu, 08 Oct 2009 08:47:36 -0400

> I believe the discussion needs to move away from the directorate to a  

No disagreement in principle, but I (generally) think one is better
off with a revised document that addresses known issues before going
for a round of public comment, and there has been already some comment
on the prvious version. YMMV.

> > Minor: There is really nothing ambiguous about the text in 1123.

Right. My suggested edits move away from that language for that
reason.

> > nor for permitting those characters in the Unicode form of IDNs.

OK. But I don't understand right off why we need to bring the Unicode
form of an IDN into this. Isn't it sufficient to just say only
A-Labels are allowed?

> > of that problem, see draft-ietf-idnabis-bidi.

This is about leading digits, which I don't think we want to propose
changing in this document. And is about U-Labels, not A-Labels, Right? 

> > several of characters in the others.

wfm.

> > not be taken lightly, IMO.

Thomas

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Oct 2009 11:14:00 -0400

--On Thursday, October 08, 2009 08:47 -0400 Thomas Narten
<[email-masked]> wrote:

>...
>> > ASCII-compatible-encoding, using reversible Punycode
>> > conversion from valid IDNs labels, with the "xn--" prefix,
>> > but requiring that the native-character ("Unicode") form
>> > consist of letters only.  No compelling need has been shown
>> > for permitting digits or hyphens (or other characters), in
>> > all-ASCII (non-IDN) labels, nor for permitting those
>> > characters in the Unicode form of IDNs.
> 
> OK. But I don't understand right off why we need to bring the
> Unicode form of an IDN into this. Isn't it sufficient to just
> say only A-Labels are allowed?

Thomas (and others),

There are two possible ways of looking at this.  One is that we
are looking exclusively at the technical requirements for DNS
operation, seen separately from anything else --and really
pretending that nothing else exists.  An extreme version of that
position would suggest that there are really no restrictions
that make any sense -- after all, from a narrow, DNS Operations,
standpoint, the biggest argument against binary string labels in
the root is that it might require updating some of the
maintenance tools.  I can't really recommend that, but it does
have some appeal... perhaps the same appeal that the proverbial
ostrich feels with its head in a secure and dark place.

The other is that these restrictions have always been, at least
in part, driven by human factors considerations.   We don't have
underscores in host names partially because of some early
internationalization issues but mostly because it was pointed
out that they were indistinguishable from hyphens when seen on
the page or written in longhand.  The original "no leading
digits" rule was driven by wanting to make sure that even sloppy
programming or sloppy thinking didn't confuse addresses with
names.  I remember a discussion, long ago and pre-DNS, about
whether it would be rational to permit host names like 1X while
prohibiting 1A (which could be an address in hex).

Similarly, from a policy standpoint --and as you have certainly
learned by now in your ICANN experience-- the fuzzy lines are
much harder to hold than the hard ones.  "Non-Latin-IDNs get to
do this  at the top level in terms of what users see, so it is
unfair that I can't do it in spite of using Latin script or
having only undecorated Latin characters" is lawyer-bait.  "No
non-letter characters, other than as needed for A-labels, in
either the display or internal form of a TLD name" is very
clear, very crisp, and completely non-discriminatory wrt
particular languages or scripts.
 
>> > This is not just my usual paranoia about making changes
>> > broader than we fully understand.  There is actually a
>> > case, involving "bidirectional" Unicode strings (more or
>> > less those containing characters from scripts written right
>> > to left), in which leading or trailing digits can result in
>> > label migration such that the order in which labels may
>> > appear in display format becomes different from the order
>> > in which they are transmitted "on the wire" or appear in
>> > native-DNS format.   The problem can occur in lower levels
>> > of the DNS as well, but, if one permits the "bad" cases in
>> > the root, it is all over -- no amount of registry (zone
>> > administration) discipline, even if one could count on it,
>> > would be sufficient to prevent the label migration problem
>> > from occurring.   For those interested in a more detailed
>> > explanation of that problem, see draft-ietf-idnabis-bidi.
> 
> This is about leading digits, which I don't think we want to
> propose changing in this document. And is about U-Labels, not
> A-Labels, Right? 

Yes, it is about U-labels, for which see above.  It is still a
relevant concern relative to perceived ambiguity in FQDNs -- a
problem that is potentially no less severe than the "visually
similar characters" one.  And, again, in terms of crispness and
clarity of rules, "no digits" is clear.  "Digits anywhere but in
the first position in spite of the fact that we've now got two
decades of experience with leading digits in other labels"
sounds like we are hair-splitting to put some groups at a
disadvantage.  And that, again, is lawyer-bait.

>> > To the extent to which we care more about identifier
>> > integrity than about the "domain names market", we need to
>> > hold the line and support an absolutely minimal change.
>> > 
>> >    ; with the definition in draft-ietf-idna-defs _and_ that
>> >    is further restricted

Encouraging.

   john

---

From: Lars-Johan Liman <[email-masked]>
Date: Mon, 26 Oct 2009 23:28:54 +0900

Friends,

I realize that the chances that you'll see this in time are minimal,
but if you do, and have critical comments before I submit it, let me
know. Else I'll send it in before the deadline later (your) today.

I've incorporated most of Tomas's coments, and I must say that I
follow John's reasoning all the way. We _don't_ want jumping digits in
the TLD label (nor anywhere else, but that's a different problem).

So, I've tried to merge the two sets of comments. Right now the text
is fairly complicated and refers to a couple of internet drafts -
references that need to be cleared up before publication. I'm hesitant
to duplicate text so references is probably the way to go, but I don't
have the respective I-Ds in front of me, so right now I'll have to
trust John that they contain the relevant information.

Thomas, my cell phone number is +46-708-540666, should you need it.
(For the rest of you: Please note that I'm at the ICANN meeting in
Korea, so my current TZ=+0900.)

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# ** WE'VE MOVED **: New address: Franzéngatan 5, SE-112 51 Stockholm
#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.   ! E-mail/SIP/Jabber: [email-masked]
# Senior Systems Specialist ! Tel: +46 8 - 562 860 12
# Autonomica AB, Stockholm  ! http://www.autonomica.se/
#----------------------------------------------------------------------

Individual submission                                         L-J. Liman
Internet-Draft                                                Autonomica
Intended status: Informational                          October 26, 2009
Expires: April 29, 2010

                  Top Level Domain Name Specification
                        draft-liman-tld-names-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 29, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Liman                    Expires April 29, 2010                 [Page 1]

Internet-Draft     Top Level Domain Name Specification      October 2009

Abstract

   The precise syntax allowed in top-level domain name labels has been
   the subject to some debate.  RFC 1123, for example, makes the
   statement that top-level domain names are "alphabetic".  This
   document updates the definition of allowable top-level domain names
   in order to support internationalized domain names (IDNs), as encoded
   by the IDNA protocols.  This document focuses narrowly on the issue
   of IDNs and does not make any other changes or clarifications to
   existing domain name syntax rules.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Other Limitations on Top Level Domain Labels . . . . . . . . .  6
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  To Do . . . . . . . . . . . . . . . . . . . . . . . . 10
   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 11
     B.1.  draft-liman-tld-named-01 . . . . . . . . . . . . . . . . . 11
     B.2.  draft-liman-tld-named-00 . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12

Liman                    Expires April 29, 2010                 [Page 2]

Internet-Draft     Top Level Domain Name Specification      October 2009

1.  Introduction

   The precise syntax allowed in top-level domain (TLD) name labels has
   been the subject to some debate.  RFC 1123 [RFC1123], for example,
   states that TLD names must be "alphabetic", which is interpreted as
   excluding the hyphen (or dash) character.  This document updates the
   definition of allowable top-level domain names to support
   internationalized domain names that consist of Unicode letters, as
   encoded by the IDNA protocols [RFCXXX].  In particular, this document
   clarifies that ASCII TLDs beginning with "xn--", as encoded by IDNA,
   are permissible as DNS TLD names as long as they are made from
   Unicode letters.  This document focuses narrowly on the issue of
   allowable ASCII labels encoded by the IDNA protocols and does not
   (and is not intended to) make any other changes or clarifications to
   existing domain name syntax rules.

1.1.  Terminology

   The terminology used in this document is as defined in RFC 0952
   [RFC0952] and RFC 1035 [RFC1035].

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Liman                    Expires April 29, 2010                 [Page 3]

Internet-Draft     Top Level Domain Name Specification      October 2009

2.  Background

   RFC 0952 [RFC0952] states (among other things) that a host name is;

      ... a text string up to 24 characters drawn from the alphabet
      (A-Z), digits (0-9), minus sign (-), and period (.).  Note that
      periods are only allowed when they serve to delimit components of
      "domain style names".  (See RFC-921, "Domain Name System
      Implementation Schedule", for background).  No blank or space
      characters are permitted as part of a name.  No distinction is
      made between upper and lower case.  The first character must be an
      alpha character.  The last character must not be a minus sign or
      period.

   RFC 1123 [RFC1123] reaffirms this definition, making two additional
   changes to the syntax:

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4].  One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit.  Host software MUST support this more liberal
      syntax.

   and

      However, a valid host name can never have the dotted-decimal form
      #.#.#.#, since at least the highest-level component label will be
      alphabetic.

   The restrictions on host names and specifically TLD names have always
   been, at least in part, driven by human factors considerations.
   Underscores in host names are avoided because they are
   indistinguishable from hyphens when seen on a page or written in
   longhand, and to some extent because of early internationalization
   issues.  The original "no leading digits" rule was driven by wanting
   to make sure that even imprecise programming or human thought errors
   didn't confuse addresses with names.

   The wish to express TLD names in other scripts than Latin makes it
   necessary to relax the the rules for TLD names.  However, the old
   motivations for keeping the TLD names alphabetical still hold, and
   furthermore, certain characteristics of some IDN names with digits in
   them make them unsuitable as DNS labels.  The problem is referred to
   as "jumping digits", and is described in draft-ietf-idnabis-bidi.

   In order to keep changes to existing specifications to a minimum but
   to still allow for IDN TLD names, this document hereby changes the
   existing specification to allow for IDN TLD names in the "A-label

Liman                    Expires April 29, 2010                 [Page 4]

Internet-Draft     Top Level Domain Name Specification      October 2009

   form" as specified by the IDNA-2008 specifications, i.e., an ASCII-
   compatible-encoding, using reversible Punycode conversion from valid
   IDNs labels, with IDN A-label prefix (which, as of this writing, is
   "xn--"), but requiring that the native-character ("Unicode") form
   consist of letters only.

   Hence, the ABNF expression that matches a valid TLD label is as
   follows:

             ALPHA    = %x41-5A / %x61-7A   ; A-Z / a-z

   Restricted-A-label is an A-label as defined in draft-ietf-idna-defs
   converted from (and convertible to) a U-label that is consistent with
   the definition in draft-ietf-idna-defs and that is further restricted
   to contain only Unicode characters of General Category "L".  Note
   that "L" contains several sub-categories.  The list is:

   Foo:

             ; Letter
             L = Ll / Lm / Lo / Lt / Lu

             Ll = Lowercase-Letter

             Lm = Modifier-Letter

             Lo = Other-Letter

             Lt = Titlecase-Letter

             Lu = Uppercase-Letter

   although the IDNA restriction eliminates the last two and several of
   characters in the others.

   This new specification reflects current practice in registration of
   TLD names by the IANA, and allows for IDNs.

Liman                    Expires April 29, 2010                 [Page 5]

Internet-Draft     Top Level Domain Name Specification      October 2009

3.  Other Limitations on Top Level Domain Labels

   It should be noted that there are many issues that must be considered
   in making any changes to current restrictions on DNS labels,
   especially at the top level.  DNS software is widely deployed, and
   some of that software contains embedded assumptions that may not hold
   if DNS names are used at the top level that differ from the older
   rules.  For example, when TLDs longer than 3 characters became
   available (e.g., .info, .museum, etc.), some deployed systems did not
   process such DNS names properly.  This document does not take the
   position that no problems will result when IDN TLDs are created, but
   does recognize that relaxing the syntax of allowed TLDs is necessary
   in order to allow deployment of IDNs to happen.

   It is also carefully noted that the above specification is not the
   only limiting factor on TLD labels.  There may be other entities than
   the IETF that have influence over TLD names, and which may decide to
   restrict the names further.  The above technical specification is
   just one limiting factor.

Liman                    Expires April 29, 2010                 [Page 6]

Internet-Draft     Top Level Domain Name Specification      October 2009

4.  IANA Considerations

   This memo changes the specifications for TLD names registered by the
   IANA, and the IANA is requested to change its registration process to
   use the above specification.

Liman                    Expires April 29, 2010                 [Page 7]

Internet-Draft     Top Level Domain Name Specification      October 2009

5.  Security Considerations

   This document is believed to have limited security consequences.

   It may introduce stability issues where names registered under this
   new specification may inter-operate badly with old software written
   to enforce a strict interpretation of the old specification.  This
   might also open up attack vectors (e.g. form names being truncated).
   However, it is believed that such software is scarce on the Internet,
   and since TLD names that do not adhere to a strict interpretation of
   the old specification are already used (including test IDNs) without
   apparent problems, it is believed that this change of the
   specification will not create major stability or security problems on
   the Internet.

Liman                    Expires April 29, 2010                 [Page 8]

Internet-Draft     Top Level Domain Name Specification      October 2009

6.  References

6.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

6.2.  Informative References

   [RFC0952]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
              host table specification", RFC 952, October 1985.

Liman                    Expires April 29, 2010                 [Page 9]

Internet-Draft     Top Level Domain Name Specification      October 2009

Appendix A.  To Do

   1.  Clean up references.  Check situation with references to Internet
       Drafts.  Are they/will they be published as RFCs before this
       draft?

   2.  Verify quotations.

Liman                    Expires April 29, 2010                [Page 10]

Internet-Draft     Top Level Domain Name Specification      October 2009

Appendix B.  Change History

B.1.  draft-liman-tld-named-01

   Substantial comments and improvements supplied by Thomas Narten and
   John Klensin.  Decided to go for a minimal change approach.  Also
   noted that U-labels have to be letters due to jumping digit problem.
   Rewritten major parts.

B.2.  draft-liman-tld-named-00

   First cut.  Prompted by Olafur Gudmundsson and Tina Dam.

Liman                    Expires April 29, 2010                [Page 11]

Internet-Draft     Top Level Domain Name Specification      October 2009

Author's Address

   Lars-Johan Liman
   Autonomica AB
   Franzengatan 5
   SE-112 51 Stockholm
   Sweden

   Email: [email-masked]
   URI:   http://www.autonomica.se/

Liman                    Expires April 29, 2010                [Page 12]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 26 Oct 2009 11:10:09 -0400

I read this over and I think it is safe for you to post.

         Olafur

At 10:28 26/10/2009, Lars-Johan Liman wrote:
>_______________________________________________
>dns-dir mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dns-dir

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Oct 2009 12:05:19 -0400

--On Monday, October 26, 2009 23:28 +0900 Lars-Johan Liman
<[email-masked]> wrote:

> Friends,
> 
> I realize that the chances that you'll see this in time are
> minimal, but if you do, and have critical comments before I
> submit it, let me know. Else I'll send it in before the
> deadline later (your) today.
>...
> So, I've tried to merge the two sets of comments. Right now
> the text is fairly complicated and refers to a couple of
> internet drafts - references that need to be cleared up before
> publication. I'm hesitant to duplicate text so references is
> probably the way to go, but I don't have the respective I-Ds
> in front of me, so right now I'll have to trust John that they
> contain the relevant information.

Hi.

I've skimmed this -- no time to read it carefully.  A few things
that might be useful to incorporate/patch if you have time.

(1) draft-ietf-idnabis-bidi does not use the term "jumping
digits".   The discussion that you want does occur in Section 5
of  that document.   FWIW, the co-authors of that document are
Harald and Cary Karp, both of whom are in Seoul.  I imagine that
Harald is swamped in Board things, but Cary might possibly have
some time to help you tune that part of the document (I've taken
the liberty of copying him on this note as a heads-up that I've
volunteered him).

There is, incidentally, an additional reason for avoiding
digits, but I don't have time to write it up right now.  Bug me
in Hiroshima and, if I forget, mention Input Method Editors and
localization.

(2) The "A-label form" is specified in draft-ietf-idnabis-defs
(which references the other documents as needed).

(3) Editorial: on the top of page 5, you have 

	"compatible-encoding, using reversible Punycode
	conversion from valid IDNs labels, with IDN A-label
	prefix (which, as of this writing, is..."

s/valid IDNs labels/valid IDN labels/

(4) Editorial (next paragraph on Page 5 and the ABNF for "L"):

    Foo:

             ; Letter

             Ll = Lowercase-Letter

             Lm = Modifier-Letter

s/Foo://

(5) "the IDNA restriction".  The text now reads...

	although the IDNA restriction eliminates the last two
	and several of characters in the others.

try something like:

	although IDNA prohibits (categorizes as DISALLOWED) all
	characters in the last two categories and several of the
	characters that fall into the other categories. 

(6) The IDNA2008 drafts have completed IETF Last Call and new
drafts have been posted to reflect the Last Call comments (the
most recent set a few hours ago).   So, while I don't know
Lisa's plans or schedule, there is reason to hope that the
documents will be under final IESG consideration before or
during Hiroshima.  In other words, there are good odds that they
will, indeed, be published before you can get this draft
approved and published.

I will send you separately a small file containing the XML forms
of the <reference> elements for the IDNA2008 documents in case
it would help you get better refs into the document.

    john

---

From: Thomas Narten <[email-masked]>
Date: Tue, 27 Oct 2009 06:08:16 +0900

Hi Liman.

Thanks for getting to this!  I did a quick read and also think it's
good to go for this round.

Thomas

---

From: Lars-Johan Liman <[email-masked]>
Date: Tue, 27 Oct 2009 08:42:36 +0900

> good to go for this round.

OK. It's out there now.

				Cheers,
				  /Liman