[governance] ICANN declined Bulgarian IDN fast-track

jefsey jefsey at jefsey.com
Tue Jun 29 05:39:36 EDT 2010 

At 07:48 29/06/2010, Avri Doria wrote:
>hi,
>i may be wrong.  the DAG says:


Hi!
What is the "DAG"? Is it published with an RFC number?

Look I used to operate around 1200 all numeric TLDs (French post 
codes) for a few years with national access. This "webs de france" 
test project was also included in the "dot-root" community test-bed I 
ran and reported (in French) a few years ago, along the ICANN ICP-3 
requested testing for the non-unique root possible future of the DNS.

This was part of the various "intertests" (real life testing on the 
public internet) which lead to the IUI architectural IDNA2008 
requirements that IAB is now to deal with, and to the VROOM concept 
of unique Virtual Root Open Matrix, ICANN should consider seriously 
and quickly (still time, dont tell I did not warned them!) before 
giving away TLDs for big money that might sell for free soon enough now.

Building an ISOCANN bulb with its own people, laws, rules, contracts, 
technology, economy is a second life interesting game, but it is only 
second life. Prime life is more fun. You will enjoy ML-DNS.

jfc




>Part I -- Technical Requirements for all Labels (Strings) ­ The
>technical requirements for top-level domain labels follow.
>
>1.1 The ASCII label (i.e., the label as transmitted on the wire) 
>must be valid as specified in technical standards Domain Names: 
>Implementation and Specification (RFC 1035), and Clarifications to 
>the DNS Specification (RFC 2181). This includes the following:
>
>1.1.1 The label must have no more than 63 characters.
>
>1.1.2 Upper and lower case characters are treated as identical.
>
>1.2 The ASCII label must be a valid host name, as specified in the 
>technical standards DOD Internet Host Table Specification (RFC 952), 
>Requirements for Internet Hosts — Application and Support (RFC 
>1123), and Application Techniques for Checking and Transformation of 
>Names (RFC 3696). This includes the following:
>
>1.2.1 The label must consist entirely of letters, digits and hyphens.
>
>1.2.2 The label must not start or end with a hyphen.
>
>1.3 There must be no possibility for confusing an ASCII label for an 
>IP address or other numerical identifier by application software. 
>For example, representations such as "255", "o377" (255 in octal) or 
>"0xff" (255 in hexadecimal) as the top-level domain can be 
>interpreted as IP addresses. As such, labels:
>
>1.3.1 Must not be wholly comprised of digits between "0" and "9."
>
>1.3.2 Must not commence with "0x" or "x," and have the remainder of 
>the label wholly
>comprised of hexadecimal digits, "0" to "9" and "a" through "f."
>
>1.3.3 Must not commence with "0o" or "o," and have the remainder of 
>the label wholly comprised of digits between "0" and "7."
>
>1.4 The ASCII label may only include hyphens in the third and fourth 
>position if it represents a valid internationalized domain name in 
>its A-label form (ASCII encoding as described in Part II).
>
>1.5 The presentation format of the domain (i.e., either the label 
>for ASCII domains, or the U-label for internationalized domain 
>names) must not begin or
>end with a digit.2
>
>so by this it seems ok.  though policy would still forbid giving it 
>to anyone other than a country form who 6r was a meaningful 
>representation, but the rule i getting wrong was that it could not 
>start and end with a digit.  and that is in the DAG and has to do 
>with concern over misinterpretation by various applications in the world.
>
>----
>
>but then again  - rfc 1035
>
>The following syntax will result in fewer problems with many
>
>applications that use domain names (e.g., mail, TELNET).
>
><domain> ::= <subdomain> | " "
>
><subdomain> ::= <label> | <subdomain> "." <label>
>
><label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
>
><ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
>
><let-dig-hyp> ::= <let-dig> | "-"
>
><let-dig> ::= <letter> | <digit>
>
><letter> ::= any one of the 52 alphabetic characters A through Z in
>upper case and a through z in lower case
>
><digit> ::= any one of the ten digits 0 through 9
>
>Note that while upper and lower case letters are allowed in domain
>names, no significance is attached to the case.  That is, two names with
>the same spelling but different case are to be treated as if identical.
>
>The labels must follow the rules for ARPANET host names.  They must
>start with a letter, end with a letter or digit, and have as interior
>characters only letters, digits, and hyphen.  There are also some
>restrictions on the length.  Labels must be 63 characters or less.
>
>
>
>a.
>
>On 29 Jun 2010, at 06:24, Eric Dierker wrote:
>
> > Please reference
> >
> > From: Avri Doria <avri at acm.org>
> > To: IGC <governance at lists.cpsr.org>
> > Sent: Mon, June 28, 2010 12:42:34 PM
> > Subject: Re: [governance] Hi norbert,nance] ICANN declined 
> Bulgarian IDN fast-track
> >
> > hi,
> >
> > leading digits are being considered unsafe.
> >
> > a.
> >
> > On 28 Jun 2010, at 18:15, JFC Morfin wrote:
> >
> > > At 17:25 28/06/2010, Avri Doria wrote:
> > >> what is said was the only thing it could possibly be confused 
> with is <.6r>. and since that can't never be a TLD. then there is 
> no confusing similarity.
> > >
> > > Why "6r" could not be a TLD? I mean, you have an RFC reference?
> > > jfc
> > >
> >
> > ____________________________________________________________
> > You received this message as a subscriber on the list:
> >     governance at lists.cpsr.org
> > To be removed from the list, send any message to:
> >     governance-unsubscribe at lists.cpsr.org
> >
> > For all list information and functions, see:
> >     http://lists.cpsr.org/lists/info/governance
> >
> > Translate this email: http://translate.google.com/translate_t
>
>____________________________________________________________
>You received this message as a subscriber on the list:
>      governance at lists.cpsr.org
>To be removed from the list, send any message to:
>      governance-unsubscribe at lists.cpsr.org
>
>For all list information and functions, see:
>      http://lists.cpsr.org/lists/info/governance
>
>Translate this email: http://translate.google.com/translate_t

____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance

Translate this email: http://translate.google.com/translate_t

More information about the Governance mailing list