Subject: [idn] hostname history hell

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 13:34:59 -0600

The earliest definition I know of for hostnames is rfc608 from 1974.

| in which <host-name> will be the official Host Name, a
| string obtained through negotiation between the Host and the
| NIC, governed by these constraints:
| 
|    up to 48 characters drawn from the alphabet (A-Z),
|    digits (0-9), and the minus sign (-) ... specifically,
|    no blank or space characters allowed;
| 
|    no distinction between upper and lower case letters;
| 
|    the first character is a letter;
| 
|    the last character is NOT a minus sign;
| 
|    no other restrictions on content or syntax.

Minimum 1 alpha character, maximum 48 alphanumeric chars, first char alpha
(ergo not hyphen), last char alphanumeric. The exclusion of beginning and
ending hyphens had to do with syntax of multi-part service-specific names
as is more clear later.

One side-note is that hyphen is one of the only punctuation characters
that is common between all implementations of the ECMA-6 charset.

Updated by rfc810

| 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
| to 24 characters drawn from the alphabet (A-Z), digits (0-9), and the
| minus sign (-) and period (.).  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 a letter.  The last
| character must not be a minus sign or period.  A host which serves as
| a GATEWAY should have "-GATEWAY" or "-GW" as part of its name.  A
| host which is a TIP or a TAC should have  "-TIP" or "-TAC" as part of
| its host name, if it is an ARPANET or DoD host.

Minimum 1 alpha character, maximum 24 alphanumeric chars (half the
original length from rfc608), first char alpha (ergo not hyphen), last
char alphanumeric. No explicit FQDN lengths defined.

Updated by rfc952

| 1. A "name" (Net, Host, Gateway, or Domain 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.  A host which serves as a GATEWAY should have
| "-GATEWAY" or "-GW" as part of its name.  Hosts which do not serve as
| Internet gateways should not use "-GATEWAY" and "-GW" as part of
| their names. A host which is a TAC should have "-TAC" as the last
| part of its host name, if it is a DoD host.  Single character names
| or nicknames are not allowed.

Minimum 2 alphanumeric characters (double the original minimum), maximum
24 alphanumeric chars, first char alpha (ergo not hyphen), last char
alphanumeric. No explicit FQDN lengths defined.

All of the above specifies host names as they appear in hosts databases.
These rules were often enforced by /etc/hosts implementations as well (eg,
some unix systems have maximum entry lengths of 24 chars in the local
/etc/hosts database).

rfc1035 expanded the hostname rules implicitly

| However, when assigning a domain name for an object, the prudent user
| will select a name which satisfies both the rules of the domain system
| and any existing rules for the object, whether these rules are published
| or implied by existing programs.

| 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.

Note that rfc1035 allows labels (and thus hostnames) to have minimum
length of 1 character, with a maximum of 63 characters for each label, and
with a fully-qualified domain name (and thus hostnames) to be 255
characters including the separators.

Minimum 2 alphanumeric character (inherited from rfc952), maximum 63
alphanumeric chars, first char alpha (ergo not hyphen), last char
alphanumeric. Maximum 255 for FQDN.

Some unification and clarification by rfc1123

| 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.

[first char alphanumeric, but not hyphen]

| Host software MUST handle host names of up to 63 characters and
| SHOULD handle host names of up to 255 characters.

[unified label length of 63 max, unified FQDN of 255, no unified minimum
length so minimum of 2 inherited from rfc952 prevails]

| Whenever a user inputs the identity of an Internet host, it SHOULD
| be possible to enter either (1) a host domain name or (2) an IP
| address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
| the string syntactically for a dotted-decimal number before
| looking it up in the Domain Name System.
| 
| DISCUSSION:
|      This last requirement is not intended to specify the complete
|      syntactic form for entering a dotted-decimal host number;
|      that is considered to be a user-interface issue.  For
|      example, a dotted-decimal number must be enclosed within
|      "[ ]" brackets for SMTP mail (see Section 5.2.17).  This
|      notation could be made universal within a host system,
|      simplifying the syntactic checking for a dotted-decimal
|      number.
|      
|      If a dotted-decimal number can be entered without such
|      identifying delimiters, then a full syntactic check must be
|      made, because a segment of a host domain name is now allowed
|      to begin with a digit and could legally be entirely numeric
|      (see Section 6.1.2.4).  However, a valid host name can never
|      have the dotted-decimal form #.#.#.#, since at least the
|      highest-level component label will be alphabetic.

Note that the last sentence says that the trailing label must contain
alpha chars, probably under the assumption that TLDs will be used. The
rule is not explicity stated but it is implied strongly.

Minimum 2 alphanumeric characters, maximum 63 alphanumeric chars, first
char alphanumeric, last char alphanumeric. Maximum 255 for FQDN. FQDN must
contain at least one alpha.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 13:43:25 -0600

"Eric A. Hall" wrote:

> char alphanumeric, last char alphanumeric. Maximum 255 for FQDN. FQDN
> must contain at least one alpha.

Also note that RFC 1912 (Common DNS Errors) stated that “labels may not be
all numbers” and even cites 411.org. and 1776.com. as domain names that
break this rule. However, RFC 1912 is classified as informational, and
there is no support for this tighter naming restriction in any
standards-track documents. This is the source of some confusion.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 20 Nov 2001 15:16:32 -0500

eric,

as i thought, "3.*." was both valid, post-1123, and worked too.

when bill, donald, and i were working on what became 2929 we discussed 2-octet
lables (first left of ".") that were outside of the current 3166 set, both as
7-bit and as 8-bit labels. there was no reason other than convention, and now
icann, to not use ".3." as the first label after dot, at least in theory.

thanks for the 2nd good read of the day (erik n's being the first).

eric

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 14:23:05 -0600

> as i thought, "3.*." was both valid, post-1123, and worked too.

Urgh. IMO "3.domain.dom" would be an illegal hostname since the relative
label would only contain a single character, which would violate RFC952.
"30.domain.dom" would be legal IMO.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 20 Nov 2001 15:38:33 -0500

1123, at 2.1
      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.

and

	a.isi.edu

isn't archaeology fun?

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Nov 2001 15:44:52 -0500

--On Tuesday, 20 November, 2001 15:16 -0500 Eric

> as i thought, "3.*." was both valid, post-1123, and worked too.

There is a RFC 1591 rule/ comment that notes that no TLD has an
all-numeric name and implies that one would never be approved.
1591 is also, if I recall, where the "one character" prohibition
originates.  The reason for the latter was mostly human factors
-- the small amount of redundancy in AA.*.* over A.*.* is
actually fairly significant -- plus an element of
nonsense-avoidance.

The reason for this should be fairly obvious, although again
more from a human interface standpoint than a DNS-technical one.
While the DNS will resolve (or not) whatever it is called with,
people and applications might have trouble figuring out whether
10.250.250.1 is a DNS name or an [IPv4] address.

> when bill, donald, and i were working on what became 2929 we
> discussed 2-octet lables (first left of ".") that were outside
> of the current 3166 set, both as 7-bit and as 8-bit labels.
> there was no reason other than convention, and now icann, to
> not use ".3." as the first label after dot, at least in theory.

As long as 1591 is considered "convention", this is certainly
correct.

     john

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 15:16:53 -0600

>       restriction on the first character is relaxed to allow either a

That does not say the label may consist of "a single" character, but only
discusses the content of the leading character.

>         a.isi.edu

1035:

|The labels must follow the rules for ARPANET host names.

|For example, the following strings identify hosts in the Internet:
|
|A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA

Does the example override the rule?

Until the 2-char rule inherited from 952 by 1035 is overthrown (which I
wish somebody would state one way or the other), it is implicitly upheld.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 20 Nov 2001 16:25:20 -0500

>Does the example override the rule?

Of course not! All dns implementations that resolve a.isi.edu are broken!!!

The RFC will appear in about 4 months and 10 days.

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Nov 2001 16:28:39 -0500

--On Tuesday, 20 November, 2001 13:34 -0600 "Eric A. Hall"
<[email-masked]> wrote:

> Minimum 1 alpha character, maximum 48 alphanumeric chars,
> first char alpha (ergo not hyphen), last char alphanumeric.
> The exclusion of beginning and ending hyphens had to do with
> syntax of multi-part service-specific names as is more clear
> later.

It was also noted at the time that hyphen was a common argument
("qualifier") introducer in some command languages and a common
introducer for negative numbers in input strings in others, and
hence better avoided.

   john

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 15:34:47 -0600

> Of course not! All dns implementations that resolve a.isi.edu are

Well, resolving it is something else. It is a valid domain name and is
certainly valid for lookups.

Being conservative in what gets generated: it is not valid for assignment
even if applications allow it to be used as a host identifier. Being
liberal in what gets accepted: it is not valid but it resolves so we will
use it. Applied globally: it is not valid and should not be used, and apps
that choose to ignore the rules do so at some risk (maybe not in this
particular case but certainly when it comes to IDNs there will be a large
amount of risk from ignoring the rules).

We do not have to stick with the two-char rule for i18n hostnames. We do
not have to stick with the no-leading/trailing-hyphen rule either.

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 15:52:03 -0600

> introducer for negative numbers in input strings in others, and

The argument-introducer aspect is probably still applicable. Should we
keep the no-leading-hyphen rule for i18n host identifiers? We're not
explicitly tagging -GW or -TAC postfixes so that is not required (but may
be desirable for compatibility).

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 20 Nov 2001 17:13:01 -0500

you'll  want to look at this:
http://standards.ieee.org/reading/ieee/interp/1003-2-92_int/pasc-1003.2-150.html
there's probably more recent stuff, or (shades of Unicode) more _universal_
stuff, over at Redmond.

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Nov 2001 17:38:39 -0500

--On Tuesday, 20 November, 2001 15:52 -0600 "Eric A. Hall"
<[email-masked]> wrote:

> John C Klensin wrote:
> 
>> It was also noted at the time that hyphen was a common
>> argument ("qualifier") introducer in some command languages
>> and a common introducer for negative numbers in input strings
>> in others, and hence better avoided.
> 
> The argument-introducer aspect is probably still applicable.
> Should we keep the no-leading-hyphen rule for i18n host
> identifiers? We're not explicitly tagging -GW or -TAC
> postfixes so that is not required (but may be desirable for
> compatibility).

My own personal position/ bias is that we should be as
conservative about what is permitted in an IDN as possible
consistent with meeting the requirement for identifiers drawn
from any of the world's languages or combinations of them.  Put
differently, I think the general model of the old "hostname"
rules has served us well.  I would like to think of the IDN work
as expanding that model to include additional alphabetic and
ideographic characters, rather than discarding the model and
seeing how much "stuff" we can put in.

If a too-restrictive model turns out to be a mistake, it is
possible to expand it later (just as "leading digit" was
unblocked); if we adopt a model that turns out to be too broad,
there is probably no way back.

On that basis, my inclination would be to:

	* continue to prohibit leading (or trailing) hyphens
	
	* continue to prohibit all spacing characters
	
	* continue to prohibit all punctuation characters except
	for that hyphen and the label-separating period (full
	stop, ".")
	
	* prohibit, in the spirit of the hostname rules, all
	symbol and drawing characters

We don't _need_ them for identifiers.  Some of them will, sooner
or later, run up against a legitimate command language or cause
"interesting" lexical parsing problems (even if they don't cause
problems in today's URI syntax definition).  High risks,
marginal benefit.

Just my opinion, of course, but I have these scars...

    john

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 17:06:45 -0600

>         * continue to prohibit leading (or trailing) hyphens

agree

>         for that hyphen and the label-separating period (full

ASCII versions of these are already prohibited by nameprep. Look-alikes
from other ranges should be prohibited to eliminate security problems
which would arise from purposefully misleading domain names.

>         symbol and drawing characters

I'm completely neutral on this range but your arguments make sense.

---

From: David Hopwood <[email-masked]>
Date: Tue, 20 Nov 2001 20:45:32 +0000

-----BEGIN PGP SIGNED MESSAGE-----

> wish somebody would state one way or the other), it is implicitly upheld.

What 2-character rule? There is nothing in either the 952, 1035, or
1123 syntaxes to prohibit single-character labels.

Extend ABNF with an operator \, so that a string matches A \ B iff it
matches A but not B.
Then the syntax implied by RFC 1123, ignoring the 255-character limit
on hostnames, is:

  RFC1123HostName = *(HostLabel ".") TopLevelHostLabel
  HostLabel = (LETTER / DIGIT) [61*(LETTER / DIGIT / "-") (LETTER / DIGIT)]
  TopLevelHostLabel = HostLabel \ *DIGIT

Does anyone disagree?

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "Tim Langdell" <[email-masked]>
Date: Tue, 20 Nov 2001 15:48:46 -0800

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "Eric A. Hall" <[email-masked]>
Cc: "IDN" <[email-masked]>
Sent: Tuesday, November 20, 2001 2:38 PM
Subject: Re: [idn] hostname history hell

> --On Tuesday, 20 November, 2001 15:52 -0600 "Eric A. Hall"
<snip>
> Just my opinion, of course, but I have these scars...

I am in substantial agreement with you John except I think on this issue of
symbols and drawing characters. Our market research shows that there is
going to be a high degree of demand for such characters. Further, with the
wide range of scripts and characters supported by Unicode, for many it will
be a rather academic hair-splitting which is a language script/character and
which is technically a symbol or drawing character.

Tim

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 18:01:34 -0600

> > Until the 2-char rule inherited from 952 by 1035 is overthrown

> | or nicknames are not allowed.

"Single character names or nicknames are not allowed."

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Nov 2001 15:48:17 -0800

At 05:38 PM 11/20/2001 -0500, John C Klensin wrote:
>I would like to think of the IDN work

The main reason I am responding is because I believe the above text states 
the fundamental issue and conclusion (in opposite order) and want to 
suggest that people consider John's text very carefully.

In general, we need a BASIC capability now and can consider enhancements 
later.  We cannot, as John observes, take back things that should not have 
been added.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: David Hopwood <[email-masked]>
Date: Tue, 20 Nov 2001 21:03:13 +0000

-----BEGIN PGP SIGNED MESSAGE-----

"Eric A. Hall" wrote:
> Updated by rfc952
> | [...] Single character names or nicknames are not allowed.

This is contradicted by the BNF syntax in the same document:

      <hname> ::= <name>*["."<name>]
      <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]

The best thing to do at this point about the above sentence in 952
appears to be simply to ignore it, AFAICS.

- --

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Nov 2001 19:15:44 -0500

--On Tuesday, 20 November, 2001 15:48 -0800 Tim Langdell
<[email-masked]> wrote:

>> or later, run up against a legitimate command language or
>> cause "interesting" lexical parsing problems (even if they
>> don't cause problems in today's URI syntax definition).  High
>> risks, marginal benefit.
>>...
> I am in substantial agreement with you John except I think on
> this issue of symbols and drawing characters. Our market
> research shows that there is going to be a high degree of
> demand for such characters. Further, with the wide range of
> scripts and characters supported by Unicode, for many it will
> be a rather academic hair-splitting which is a language
> script/character and which is technically a symbol or drawing
> character.

Since you introduced the term "market research" into this
previously high-minded discussion ( :-( ), have you thought
about what you would put into a whois-like table with these
things?  How you would feel about being put into the middle of a
discussion of whether a name starting in a left-wizzlepop was
too similar to one starting in a left-popplewiz? I may have
missed something, but my impression is that the UTC TRs that
describe canonicalization don't do much for drawing characters:
do you propose that the IETF do that work?  Or do you think it
is unnecessary?   

And so on.  The point here is to make a case for "more trouble
than they are worth" -- people would _like_ lots of things from
the DNS, including things we don't know how to do (which is why
many of us are working on "search layer" models); I'm suggesting
that a little drawing of the lines short of the conceivable
technical limits might be to almost everyone's advantage.

     john

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 20 Nov 2001 18:31:12 -0600

> appears to be simply to ignore it, AFAICS.

That would resolve the conflict in rfc1035, and a.isi.edu would be legal
under the rfc952 inheritance rule.

There is a lot of, umm, infrastructure history with single-character
delegations which would also need to be revised and fixed, so the question
at this point goes to those parties who control those rules.

This does need to be resolved before we can define absolute parameters for
i18n host identifiers.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 20 Nov 2001 19:53:07 -0500

John,

Think of all the fun everyone will have doing wiggly-line-compare. Is line
drawing l2r, or r2l, bidi, ... There's real 1 April Gold in this. My market
research shows there is a pent-up demand for ...

	fallen totem poles (sectionally re-rendered vertically),
	linearized winter-counts (ledger-art normalized form)
	concatenated mayan glyphs (warning: digit one resembles "dot")
	...

Fortunately, these are not present in the available UCS candidates.

I admire the gall of someone who talks about the market for symbols and
drawing characters, when Asians have to write in Roman, its so ... daft.

Eric

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 21 Nov 2001 01:02:34 +0000

"Eric A. Hall" <[email-masked]> wrote:

> | 1. A "name" (Net, Host, Gateway, or Domain 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.  A host which serves as a GATEWAY
> | should have "-GATEWAY" or "-GW" as part of its name.  Hosts which do
> | not serve as Internet gateways should not use "-GATEWAY" and "-GW"
> | as part of their names.  A host which is a TAC should have "-TAC"
> | as the last part of its host name, if it is a DoD host.  Single
> | character names or nicknames are not allowed.

It clearly says that a "name" may contain periods, which delimit
"components", and it disallows "single character names", not "single
character components".

Curiously, it forbids hostnames that end in a dot, and RFC 1034 says
that domain names that name hosts should follow the rules for HOSTS.TXT
(RFC 952), but also says that full (absolute) domain names end in a dot.

AMC

---

From: "Tim Langdell" <[email-masked]>
Date: Tue, 20 Nov 2001 17:01:24 -0800

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "Tim Langdell" <[email-masked]>
Cc: "IDN" <[email-masked]>
Sent: Tuesday, November 20, 2001 4:15 PM
Subject: Re: [idn] hostname history hell

> do you propose that the IETF do that work?  Or do you think it

It is of course that highly frowned upon concept of seeking what it is
people want (aka market research) that led us to realize people want IDNs
not just merely ASCII DNs. And led us to realize (like you I think John)
that people will need a layer on top of DNS in which feature rich
enhancements can be offered such as search (all of which are things we have
been actively engaged in on our end for about 7 months now - the building of
such a layer). But as you may have seen, many registrars are already
offering quite proudly that they will have available symbol based DNs and
IDNs (Tucows just added to the long list). So I fear if this issue is
relegated for simplicity's sake that the request will come back to the IEFT
to consider these issues anyway ...

That all said, I heartily concur with you as to the problems of
left-wizzlepop similarities and so forth. And I suspect we'll have similar
issues surrounding odd characters in obscure dead-language scripts and
symbol based systems (they are adding Tolkein's middle earth language to
Unicode aren't they?) ... so we may just be putting off what we will
naturally have to tackle pretty soon anyway. If we are canny about this I
suspect we can come up with suggestions for whois-like table handling that
will encompass virtually any ideographic, symbol or pictoral (drawing)
characters. But that's just my opinion ...

> technical limits might be to almost everyone's advantage.

Heartily concur on the DNS layer issue, hence our work on a search layer
doer DNs and IDNs,  and on IDN resolution (assistance/enhancement) via such
a layer for some 7 months or so now.

Tim

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 21 Nov 2001 16:53:58 +0800

The problem is we cannot determine what is useful and what is not.

For example, SGNIC may decide that it only allows Han Ideograph, Tamil
scripts and US-ASCII only. JPNIC may decide otherwise. Perhaps some
registery in future things 'symbol-drawing' is useful (e.g. a registry
for trademark).

I suggest we follow the simple-and-dumb rule for IDN.

idn -> any ucs characters subjected to nameprep prohibition (section 5)
ihn -> ...registry define themselves...

application can use nameprep to "check" idn.

-James Seng

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Nov 2001 04:16:23 -0500

James,

Neither Dave nor I used the word "useful".  I carefully avoided
it and he probably did to.

It is a reality of human nature that, for almost any idea, if
you go around and ask enough people "would this be useful" or
"might you find this attractive to have", without any sense of
the tradeoffs or costs, someone will say "yes".  Probably even a
lot of them will say "yes", possibly accompanied by "why not".  

_I_ can think of a number of reasons why it would be really neat
to have arbitrary symbol combinations in domain names. I'm not
very imaginative about these things, and certainly am not
formulating marketing plans about how I can make more money
"selling" more names, which might motivate me to get more
imaginative.  But, for example, I can think of all sorts of nice
uses for a domain named @#$%^.org, URIs notwithstanding.

But...

The primary job of the WG is not to figure out a way to include
anything that someone might think is useful.   The job is to
incorporate international character identifiers into the DNS (I
hope we all understand by now that "names" is as much a misnomer
as "multilingual") while being carefulto not wreck the Internet
or the DNS.  That "while" inherently implies tradeoffs and I
believe that we should confine ourselves to the clearly-needed
(and ideally lowest-risk) cases.  That is a much higher standard
than "someone thinks this would be useful" or "there is market
demand".

Remember, as a corollary to Milo's principle (*), we know how to
make pigs fly.  The fact that we don't do it often is the result
of an engineering tradeoff: it is too expensive and the
mechanism is unacceptably hard on the pig.

     john

* Milo Medin, while at NASA, pointed out that anything could be
made to fly given sufficient thrust.

--On Wednesday, 21 November, 2001 16:53 +0800 "James
Seng/Personal" <[email-masked]> wrote:

> For example, SGNIC may decide that it only allows Han
> Ideograph, Tamil scripts and US-ASCII only. JPNIC may decide
> otherwise. Perhaps some registery in future things
> 'symbol-drawing' is useful (e.g. a registry for trademark).
> 
> idn -> any ucs characters subjected to nameprep prohibition
> (section 5) ihn -> ...registry define themselves...
>

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 21 Nov 2001 17:29:59 +0800

John,

> it and he probably did to.

Apologises. Not my intention too.

> than "someone thinks this would be useful" or "there is market

I agree with you above...But we seem to arrived in different conclusion:

I arrived to the conclusion because our job is to confirmed itself to
"incorporate international characters", then "picture-drawing" or
"symbol" been part of "international characters" should be allow in IDN.

Whether it is allowed in IHN is another question, one that have wordings
like "users requirements", "usefulness", "market research", "policies"
and something this wg may or may not be able to handle.

OTOH, you concluded that "picture-drawing", "symbol" etc should not be
allowed in IDN because it is not "clearly-needed (and ideally
lowest-risk)".

Both views are correct. We are drawing very very fine lines here.

-James Seng

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Nov 2001 09:38:48 -0500

--On Wednesday, 21 November, 2001 17:29 +0800 "James
Seng/Personal" <[email-masked]> wrote:

>> The primary job of the WG is not to figure out a way to
>> include anything that someone might think is useful.   The
>> job is to incorporate international character identifiers
>> into the DNS (I hope we all understand by now that "names" is
>>...
> I arrived to the conclusion because our job is to confirmed
> itself to "incorporate international characters", then
> "picture-drawing" or "symbol" been part of "international
> characters" should be allow in IDN.

We clearly disagree.  I suggest that the goal was international
alphabetic/ ideographic characters, e.g., the things that are
used to write "words" as a surrogate for identifiers.  The WG
_selected_ Unicode as the best available coding base for, and
list of, such characters (a rational decision, IMO).   Unicode
drags some baggage along with it in terms of "picture-drawing",
"symbols", etc.  Our decision to select Unicode does not, and
should not, implies that those blocks of code points are
"international characters".

> Whether it is allowed in IHN is another question, one that
> have wordings like "users requirements", "usefulness", "market
> research", "policies" and something this wg may or may not be
> able to handle.
> 
> OTOH, you concluded that "picture-drawing", "symbol" etc
> should not be allowed in IDN because it is not "clearly-needed
> (and ideally lowest-risk)".
> 

Absolutely.  And, if we get it seriously wrong, the DNS becomes
ambiguous and unmanageable, and we have no way back.  Hence,
conservatism is in order, IMO.

    john

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 21 Nov 2001 10:15:26 -0500

> "symbol" been part of "international characters" should be allow in IDN.

Is this (a) a co-chair "improving" the charter, or (b) a random contributor
lacking clue?

If (a), then stop.
If (b), then stop, "please".

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 21 Nov 2001 09:50:22 -0600

How about this as a believable compromise: We start with a "safe set" of
alphanumeric characters and specifically exclude punctuation, spacing,
symbols, and combining characters. Meanwhile, {some group} is going to
investigate the use of additional characters in the DNS and the allowable
set may be expanded at some point.

The obvious problem with this approach is that it will be difficult to
coordinate the two lists between the implementations.

---

From: "Kent Karlsson" <[email-masked]>
Date: Wed, 21 Nov 2001 17:24:36 +0100

> symbols, and combining characters. 

No, combining characters should not be excluded, at least not those used
for letters (as opposed to symbols).  Even after NFKC some will remain.

> Meanwhile, {some group} is going to

Isn't this being done by the nameprep subgroup (and whatever group that
may eventually replace that subgroup)?

        /kent k

---

From: "Tim Langdell" <[email-masked]>
Date: Wed, 21 Nov 2001 08:35:54 -0800

I think Eric's proposal may have legs. Or at least something along these
lines. I agree with John's point that we need to start conservative and
expand from that base-line. To be too inclusive at first means it would be
nearly impossible to go back.

We must though be very careful not to inadvertently exclude
scripts/characters that are used by some languages even though we thought
they were merely symbols.

Tim

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 Nov 2001 18:05:02 +0100

Excuse me for a second, but I might have missed what this discussion is
about.

The nameprep draft which was a result of the nameprep group did come up
with a list of excluded codepoints, and those are very delicately divided
into "Mapped out" (Section 3.1) and "Prohibited Output" (Section 5).

Is the intention to update / change these lists?

I.e. is this discussion a comment on the nameprep draft?

Basically, I feel we have already done this once, and need arguments for
starting all over again.

     paf

---

From: "Soobok Lee" <[email-masked]>
Date: Thu, 22 Nov 2001 02:17:11 +0900

----- Original Message -----
From: "Eric A. Hall"
To: "John C Klensin"
Cc: "James Seng/Personal" ; "IDN"
Sent: Thursday, November 22, 2001 12:50 AM
Subject: Re: [idn] hostname history hell

> coordinate the two lists between the implementations.

If we want to prohibit assigned symbol characters
in the current version of nameprep consistently,
we should also necessarily prohibit all currently *unassigned code points* (UCP),
because current UCPs may become assigned to future symbol characters.
Then,this thread may fall again onto nameprep UCP handling and revision tagging
problems.

To avoid this, we should devise some new prohibiting mechanism other than
just blindly putting them in prohibition lists in a version of nameprep.

Soobok Lee

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 21 Nov 2001 11:26:00 -0600

Patrik Fältström wrote:

> with a list of excluded codepoints, and those are very delicately
> divided into "Mapped out" (Section 3.1) and "Prohibited Output"
> (Section 5).
> 

I think it is fair to say that the current discussion is about i18n domain
names and host identifiers, and what is legal vs illegal for those names.
It is starting to bump into nameprep but I wouldn't call it a
repeat/update to nameprep at this point.

For example, nameprep doesn't prohibit leading/trailing hyphens, although
there seems to be consensus that they should be prohibited in i18n host
identifiers.

If the thread keeps moving in its current direction, there may be a need
to update nameprep. I also think nameprep is providing valuable input to
the hostname restrictions (control exclusions are good). I would hope that
this is being seen as refinement of consensus rather than competition.

---

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 22 Nov 2001 01:59:27 +0800

For those who dont couldnt be bother with all these: the short of this
is "please bring personal attack offline", then skip the rest of the
mail.

While I dont usually demonstrate my "clues" as often as you did with
years of experience and association with this or that companies, and you
probably earn the bragging right I grant you, perhaps respectable
"political correct politiness" enviorment, your statement to label me as
"random contributor lacking clue" would need more technical
justification then "I am right, you are wrong so you are clueless"
conclusion, especially when you have no said anything about what your
opinion, erm sorry, the technical answer, is.

If you are only writing to express your opinion of me to the wg group,
rest assure that the wg members here are quite well-aware of how you
feel about me, and repeating it again while it does great for your ego,
does make sound kind of like a "break down disc player that just wont
stop playing that song!"

I have a feeling you are just using me me as a living-demonstration of
how interesting one can live his life should one offend you, and that
include those who disagree with you often enough with clue or without
clue, and I may be wrong, but if that is the case, you certainly made
your point too.

There is a chinese saying: "另可得罪君子, 也不可得罪小人". Unfortunately, translation
is not that easy.

So unless you have any specific technical contribution to make the
working group, which I believe everyone would be happier if you doing
that, personal attacks as this are best deal away the working group,
offline whereby my lovely filter would do the job of putting it to
/dev/null and conclude the arguments.

Once again, I hereby declare from now on that "lack of clarification on
my part to your flamebait does not indicate any agreement on my part
with your flamebait". I hope others will do so likewise so we can save
bandwidth to do more useful work.

-James Seng

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; "IDN" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, November 21, 2001 11:15 PM
Subject: Re: [idn] hostname history hell

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 Nov 2001 19:01:02 +0100

> this is being seen as refinement of consensus rather than competition.

Ok. I get it. Thanks!

I have understood that there is a discussion about "what is the difference
between host name and domain name", and, yes, I have seen that before. I am
happy being in the peanut gallery while that goes on :-)

   paf

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 21 Nov 2001 19:30:15 +0100

--On 01-11-21 19.01 +0100 Patrik Fältström <[email-masked]> wrote:

> between host name and domain name", and, yes, I have seen that before. I
> am happy being in the peanut gallery while that goes on :-)

People asked me to send some thoughts I have _anyways_ to this mailing
list....

Here we go:

[I know this _might_ be contrary to what I have said before, and what I
have written in IDNA, but this is why we have this nice discussion...]

My take is that nameprep is defining the largest possible set of codepoints
possible in a _domain_name_. Because of that, maybe nameprep is prohibiting
too many codepoints and more codepoints should be allowed.

Then, a smaller set is a _host_name_.

I don't see any need what so ever to define what the difference is between
a host name or domain name.

It is ok for me to know "the same as always". :-)

This is why I want to sit beside the discussion and watch. :-)

   paf

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Nov 2001 06:40:07 -0000

> conservatism is in order, IMO.

This is one of the reasons that programs shouldn't do nameprep.

Suppose we teach applications these horribly complicated rules---rules
in which we're still finding major errors---for converting bad strings
to good strings. Suppose it turns out that this was a huge mistake: for
example, users are constantly confusing uppercase Beta with uppercase B.

We'll never be able to get rid of the conversion. We'll be stuck with it
for compatibility, just as we're stuck with treating uppercase ASCII as
equivalent to lowercase ASCII today.

If, on the other hand, applications don't do any conversion, and
registrars prohibit the bad characters, then the bad characters simply
won't work. There will be only one way to type a domain name. If this
turns out to be a mistake, we can change it later, without breaking
anything. This is the simple, clean, conservative approach.

---Dan