On Wed, Jul 09, 2008 at 12:54:24PM +1000, Mark Andrews wrote:
> > I don't "want" anything in this space. I don't care if the root's
> > unchanged or as wide as .com.
>
> There was a clear decision to move from a single label
> hostnames to multiple label hostnames (RFC 921). You are
Mark Andrews wrote:
...
"hk" is not a legal fully qualified host name.
Agreed. "hk.", however, is.
No, it is not a legal hostname.
RFC 952 explicitly excludes trailing periods.
RFC 952 is not a standard.
Joe
signature.asc
Description: OpenPGP digital signature
_
On Tue, Jul 08, 2008 at 02:34:59PM -0700, Ted Faber wrote:
> On Tue, Jul 08, 2008 at 05:11:35PM -0400, Keith Moore wrote:
> > And vanity TLDs are going to be much more attractive if people think
> > they can get single-label host names out of them.
>
> Of your concerns (which I don't have the rel
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --enigB56BE6D16B38F294AC1B9ED5
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: quoted-printable
>
> Mark Andrews wrote:
> It's nonsensical for an application to decide that r
Mark Andrews wrote:
It's nonsensical for an application to decide that relative names are
unacceptable, but to require users to input names as relative.
it's nonsensical for you to unilaterally declare that such names are
relative, when well over two decades of practice indicates otherwise.
>>
>
> --5me2qT3T17SWzdxI
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Jul 09, 2008 at 10:54:45AM +1000, Mark Andrews wrote:
> > > Let me be precise. The resolver treats those names differently because
> > > it
The (some) resolver handles names differently if it contains a dot.
The distinction that I have been unclearly stating is between absolute
and relative names. RFC 1034 (i said 1035 earlier, but it's 1034) lays
out a convention for specifying which one you want by appending the dot.
As
>>> It's nonsensical for an application to decide that relative names are
>>> unacceptable, but to require users to input names as relative.
>>
>> it's nonsensical for you to unilaterally declare that such names are
>> relative, when well over two decades of practice indicates otherwise.
>
> I
On Wed, Jul 09, 2008 at 10:54:45AM +1000, Mark Andrews wrote:
> > Let me be precise. The resolver treats those names differently because
> > it was handed a name that did or did not end in a dot - the resolver's
> > syntax for absolute vs. relative pathname. I understand that may
> > conflict wit
>
> --mvpLiMfbWzRoNl4x
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, Jul 07, 2008 at 11:28:05PM -0400, Keith Moore wrote:
> > >
> > >The site-dependent interpretation of the name is determined not by the
> > >
Ted Faber wrote:
On Tue, Jul 08, 2008 at 05:11:35PM -0400, Keith Moore wrote:
And vanity TLDs are going to be much more attractive if people think
they can get single-label host names out of them.
Of your concerns (which I don't have the relevant experience to comment
on in detail), this see
I don't think 1034 was handed down from a mountain on stone tablets.
It was not. But when other programs started using the DNS, it was *they*
that endorsed what the DNS as per that doc.
...but they also profiled it in various ways for use with that specific
app. Some apps define their own R
On Tue, Jul 08, 2008 at 05:11:35PM -0400, Keith Moore wrote:
> And vanity TLDs are going to be much more attractive if people think
> they can get single-label host names out of them.
Of your concerns (which I don't have the relevant experience to comment
on in detail), this seems to be fairly sm
Ted Faber wrote:
On Tue, Jul 08, 2008 at 02:17:57PM -0400, Keith Moore wrote:
The notion of a single-label fully-qualified DNS name being "valid" is
an odd one. DNS, as far as I can tell, was always intended to be
federated, both in assignment and lookup. The notion of having terminal
(ba
Keith Moore wrote:
It's nonsensical for an application to decide that relative names
are unacceptable, but to require users to input names as relative.
it's nonsensical for you to unilaterally declare that such names are
relative, when well over two decades of practice indicates otherwise.
It's nonsensical for an application to decide that relative names are
unacceptable, but to require users to input names as relative.
it's nonsensical for you to unilaterally declare that such names are
relative, when well over two decades of practice indicates otherwise.
I didn't declare it;
On Tue, Jul 08, 2008 at 02:17:57PM -0400, Keith Moore wrote:
> Ted Faber wrote:
> >On Mon, Jul 07, 2008 at 11:28:05PM -0400, Keith Moore wrote:
> >>there are also protocol specifications that expect DNS names to have
> >>dots in them.
> >
> >One could argue that such protocols are not able to expr
Keith Moore wrote:
Many, many working groups have looked at the problems associated with
relative names and determined that they're not acceptable. It's a
"bug" that relative names are forbidden in these apps, nor that the
final "." is implicit and in many cases disallowed. These are
car
Many, many working groups have looked at the problems associated with
relative names and determined that they're not acceptable. It's a
"bug" that relative names are forbidden in these apps, nor that the
final "." is implicit and in many cases disallowed. These are
carefully considered desi
--On Tuesday, 08 July, 2008 08:51 -0700 Bob Braden
<[EMAIL PROTECTED]> wrote:
> *>
> *> >* was not even examined in the "requirements" review
> *> >that led up to RFC 1123 and is not referenced there.
> *>
> *> RFC 1123 -> RFC 952 -> RFC 921
> *>
>
> Yo
Keith Moore wrote:
...
Many, many working groups have looked at the problems associated with
relative names and determined that they're not acceptable. It's a "bug"
that relative names are forbidden in these apps, nor that the final "."
is implicit and in many cases disallowed. These are ca
So the question of whether TLD MXs work depends on the interactions
between lot of complicated option settings and software versions, and is
likely in practice to work or fail unpredictably.
That sounds utterly reasonable.
To me the bigger question is whether this failure scenario is something
On Mon, 7 Jul 2008, [EMAIL PROTECTED] wrote:
> > So who's going to explain to the Vatican that, sorry,
> > [EMAIL PROTECTED] doesn't work any more? Or will the US take
> > issue when addresses @as, which is part of the US,
> > don't work? Or France about @gp and @mq, which are
> > as much part o
Joe Touch wrote:
I don't think you get to revise a couple of decades of protocol design
and implementation by declaring that RFC 1043's authors and process
trump everything that's been done afterward.
I'll repeat:
some app misbehaviors are just bugs
not all app misbehaviors de
Keith Moore wrote:
Joe Touch wrote:
Keith Moore wrote:
|> RFC1043 defines the dot. The fact that some apps don't recognize it
is a
|> bug.
|
| not when the application explicitly specifies that FQDNs are to be
used.
| in such cases the dot is superfluous.
Superfluous is fine. Prohibited
Joe Touch wrote:
Keith Moore wrote:
|> RFC1043 defines the dot. The fact that some apps don't recognize it is a
|> bug.
|
| not when the application explicitly specifies that FQDNs are to be used.
| in such cases the dot is superfluous.
Superfluous is fine. Prohibited is not. If the app inputs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Moore wrote:
|> RFC1043 defines the dot. The fact that some apps don't recognize it is a
|> bug.
|
| not when the application explicitly specifies that FQDNs are to be used.
| in such cases the dot is superfluous.
Superfluous is fine. Prohibi
RFC1043 defines the dot. The fact that some apps don't recognize it is a
bug.
not when the application explicitly specifies that FQDNs are to be used.
in such cases the dot is superfluous.
Keith
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.or
Ted Faber wrote:
On Mon, Jul 07, 2008 at 11:28:05PM -0400, Keith Moore wrote:
The site-dependent interpretation of the name is determined not by the
presence of dot within the name but its absence from the end.
not so. in many contexts the trailing dot is not valid syntax.
Let me be precise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joe Touch wrote:
|
|
| Keith Moore wrote:
| |
| |
| | Ted Faber wrote:
| |> On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote:
| |>> "hk." is not a syntactically valid hostname (RFC 952).
| |>> "hk." is not a syntactically valid m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Moore wrote:
|
|
| Ted Faber wrote:
|> On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote:
|>> "hk." is not a syntactically valid hostname (RFC 952).
|>> "hk." is not a syntactically valid mail domain.
|>> Periods at the
On Mon, Jul 07, 2008 at 11:28:05PM -0400, Keith Moore wrote:
> >
> >The site-dependent interpretation of the name is determined not by the
> >presence of dot within the name but its absence from the end.
>
> not so. in many contexts the trailing dot is not valid syntax.
Let me be precise. The
Ted Faber wrote:
On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote:
"hk." is not a syntactically valid hostname (RFC 952).
"hk." is not a syntactically valid mail domain.
Periods at the end are not legal.
RFC 1035 has *nothing* to do with defining wh
On Tue, Jul 08, 2008 at 12:54:16PM +1000, Mark Andrews wrote:
> "hk." is not a syntactically valid hostname (RFC 952).
> "hk." is not a syntactically valid mail domain.
> Periods at the end are not legal.
>
> RFC 1035 has *nothing* to do with defining what is legal
>
*>
*> > * was not even examined in the "requirements" review
*> > that led up to RFC 1123 and is not referenced there.
*>
*>RFC 1123 -> RFC 952 -> RFC 921
*>
Your "->" arrows here apparently mean only "contains a reference to".
This is not an explicit dependence relations
On Jul 7, 2008, at 10:55 PM, Joe Abley wrote:
On 7 Jul 2008, at 21:36, James Seng wrote:
And all of the questions I asked 10 years ago said that TLDs on
that latter
scale would be problematic to the root.
Was that pre-Anycast or post-Anycast?
There are plenty of examples of people host
--On Monday, 07 July, 2008 18:14 -0700 Dave Crocker
<[EMAIL PROTECTED]> wrote:
>
>
> John C Klensin wrote:
>> What do
>> you think would happen to that recommendation, and the
>> benefits it affords, if the size of the root zone increased
>> by an order of magnitude or so?
>
>
> 2 ord
>
>
> --On Tuesday, 08 July, 2008 11:47 +1000 Mark Andrews
> <[EMAIL PROTECTED]> wrote:
>
> >
> >> The site-dependent interpretation of the name is determined
> >> not by the presence of dot within the name but its absence
> >> from the end.
> >
> > No. Please go and re-read RFC 921.
>
--On Tuesday, 08 July, 2008 11:47 +1000 Mark Andrews
<[EMAIL PROTECTED]> wrote:
>
>> The site-dependent interpretation of the name is determined
>> not by the presence of dot within the name but its absence
>> from the end.
>
> No. Please go and re-read RFC 921.
This is the same RFC 92
On Jul 7, 2008, at 10:49 AM, John C Klensin wrote:
--On Monday, 07 July, 2008 17:19 + John Levine
<[EMAIL PROTECTED]> wrote:
John,
While I find this interesting, I don't see much logical or
statistical justification for the belief that, if one increased (by
a lot) the number of TLDs, th
Joe,
On 2008-07-08 14:55, Joe Abley wrote:
...
> I'm not suggesting that growth should be allowed to happen without
> considering the technical consequences. However, I believe in practice
> with the headroom in systems and network that root server operators
> generally install anyway, there's con
The site-dependent interpretation of the name is determined not by the
presence of dot within the name but its absence from the end.
not so. in many contexts the trailing dot is not valid syntax.
I don't buy "unreliable" as a diagnosis for that state of affairs. "hk"
operates exactly as an
On 7 Jul 2008, at 21:36, James Seng wrote:
And all of the questions I asked 10 years ago said that TLDs on
that latter
scale would be problematic to the root.
Was that pre-Anycast or post-Anycast?
There are plenty of examples of people hosting large, infrastructure-
type zones using serv
>
> --YD3LsXFS42OYHhNZ
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Jul 08, 2008 at 11:47:15AM +1000, Mark Andrews wrote:
> >=20
> > > The site-dependent interpretation of the name is determined not by the
>
On Tue, Jul 08, 2008 at 11:47:15AM +1000, Mark Andrews wrote:
>
> > The site-dependent interpretation of the name is determined not by the
> > presence of dot within the name but its absence from the end.
>
> No. Please go and re-read RFC 921.
What a charming document.
I don't see anythi
> The site-dependent interpretation of the name is determined not by the
> presence of dot within the name but its absence from the end.
No. Please go and re-read RFC 921.
> "hk." is
> as global as "hk.com." with respect to the search list; "hk" and
> "hk.com" are both relative names a
James Seng wrote:
And all of the questions I asked 10 years ago said that TLDs on that latter
scale would be problematic to the root.
Was that pre-Anycast or post-Anycast?
pre-
(And, by the way, an interesting question. It's probably why it would be good
for someone to formulate a consen
> On Tue, Jul 08, 2008 at 10:18:25AM +1000, Mark Andrews wrote:
> > > That's at least as reliable as my (multi-dotted) home domain. :-)
> > >=20
> > > I'm not sure what's not to like here. But then again, I may be blind.
> >=20
> > The point is that it is NOT reliable. Whether it works
> >
> And all of the questions I asked 10 years ago said that TLDs on that latter
> scale would be problematic to the root.
Was that pre-Anycast or post-Anycast?
-James Seng
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On Tue, Jul 08, 2008 at 10:18:25AM +1000, Mark Andrews wrote:
> > That's at least as reliable as my (multi-dotted) home domain. :-)
> >
> > I'm not sure what's not to like here. But then again, I may be blind.
>
> The point is that it is NOT reliable. Whether it works
> depends apon
John C Klensin wrote:
What do
you think would happen to that recommendation, and the benefits
it affords, if the size of the root zone increased by an order
of magnitude or so?
2 orders? 20K?
No, sorry. Think 3-4 orders of magnitude.
Really.
Let me explain: I'm not against more T
Bill Manning wrote:
> http://www.icann.org/committees/security/sac032.pdf
> is illustrative.
| entrusted agents should provide opt-out mechanisms that
| allows clients to receive the original DNS answers to
| their queries.
[...]
| Organizations that rely on accurate NXDomain reporting
| for op
>
> --===1515233305==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye"
> Content-Disposition: inline
>
>
> --tsOsTdHNUZQcU9Ye
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Cont
On Mon, Jul 07, 2008 at 03:49:53PM -0700, Bill Manning wrote:
> so... the point i was tryig to make was/is:
>
> simple queries only help if you know:
> ) the version of software running on your caching server
> and
> ) the search list defined b
> I understand the objection to MX records in TLDs based on the past
> history of how single label hostnames were (and, as Mark points out,
> undoubtedly still are) handled. If it were possible to put that
> aside, would you have any other objection to single label hostnames?
> I know that
On Mon, Jul 07, 2008 at 02:25:31PM -0700, Ted Faber wrote:
> On Mon, Jul 07, 2008 at 02:04:31PM -0700, Bill Manning wrote:
> > On Mon, Jul 07, 2008 at 01:44:28PM -0700, Ted Faber wrote:
> > > On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote:
> > > > On Mon, Jul 07, 2008 at 01:32:10PM -0700
--On Monday, 07 July, 2008 15:03 -0700 Karl Auerbach
<[EMAIL PROTECTED]> wrote:
>
> I guess you've heard the old joke which asks "How could God
> create the world in only seven days? - Because He had no
> installed base."
yes. But six. He could then rest, rather than dealing with
irate users
On Mon, Jul 07, 2008 at 05:42:14PM -0400, Theodore Tso wrote:
> 5% ping hk
> PING hk.ibm.com (9.190.250.244) 56(84) bytes of data.
> ...
I can do that with hk.com, too, as you know. I think it's a feature.
YMMV.
My point is that from my minimal sample, hk seems to work about the
same as any othe
On Mon, Jul 07, 2008 at 03:56:10PM -0600, Willie Gillespie wrote:
>
> With your hk.ibm.com example, do you have any search lines in your
> /etc/resolv.conf file that would be automatically appending?
Of course! That was my point about why "http://hk"; or "ping hk" is
not going to be terribly re
I guess you've heard the old joke which asks "How could God create the
world in only seven days? - Because He had no installed base."
If we move this thread up one level of abstraction much of the
conversation is asking the question of how strongly we respect the
installed base of software o
Theodore Tso wrote:
On Mon, Jul 07, 2008 at 02:13:47PM -0700, Ted Faber wrote:
On Mon, Jul 07, 2008 at 05:01:30PM -0400, Theodore Tso wrote:
On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote:
On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote:
If you can cite verifiable
On Mon, Jul 07, 2008 at 02:13:47PM -0700, Ted Faber wrote:
> On Mon, Jul 07, 2008 at 05:01:30PM -0400, Theodore Tso wrote:
> > On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote:
> > > On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote:
> > > > If you can cite verifiable evide
Umm, hk. resolves to the same address from both our machines and is
pingable (modulo a single packet loss from yours, depending on how your
ping counts) from both. http://hk pulls up a web page on a machine with
the same address.
interesting. I had actually tried that URL before sending the l
On Mon, Jul 07, 2008 at 02:04:31PM -0700, Bill Manning wrote:
> On Mon, Jul 07, 2008 at 01:44:28PM -0700, Ted Faber wrote:
> > On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote:
> > > On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote:
> also...
> % dig version.bind txt cha
On Mon, Jul 07, 2008 at 05:01:30PM -0400, Theodore Tso wrote:
> On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote:
> > On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote:
> > > If you can cite verifiable evidence that even a single case that works
> > > reliably now, will cea
--On Monday, 07 July, 2008 09:24 -0700 Dave Crocker
<[EMAIL PROTECTED]> wrote:
>
>
> Lyman Chapin wrote:
>>If it were possible to put that aside,
>> would you have any other objection to single label hostnames?
>> I know that at least some of the interest in new gTLDs has
>> been express
On Mon, Jul 07, 2008 at 01:44:28PM -0700, Ted Faber wrote:
> On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote:
> > On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote:
> > > If you can cite verifiable evidence that even a single case that works
> > > reliably now, will cease
On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote:
> On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote:
> > If you can cite verifiable evidence that even a single case that works
> > reliably now, will cease to work, I'll concede that there is at least
> > a hin
On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote:
> On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote:
> > If you can cite verifiable evidence that even a single case that works
> > reliably now, will cease to work, I'll concede that there is at least
> > a hint of merit to
On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote:
> If you can cite verifiable evidence that even a single case that works
> reliably now, will cease to work, I'll concede that there is at least
> a hint of merit to your argument. e.g. an actual email address or
> URL that uses a
> I have to congratulate you on one of the most subtle
> proposals to destroy the Internet that I have seen
> in a long time. More on that in a moment.
Maybe you should read and understand the proposal before commenting on it. I
realize that it's difficult to actually
be sure you understand a
Conversely, if root server traffic is an issue, getting networks to
clean up their DNS traffic would be much more effective than limiting
the number of TLDs.
sounds good. and why wouldn't "cleaning up DNS traffic" include
refusing to refer any single-label query (for any record type other than
John Levine wrote:
What will be the impact of having, perhaps,
1) millions of entries in the root servers, and
Let's start by considering thousands of entries, since I see little
reason to expect even that many from ICANN's current plans.
When making a paradigm change to a core, infrast
the junk. Conversely, if root server traffic is an issue,
getting networks to clean up their DNS traffic would be much
more effective than limiting the number of TLDs.
While I find this interesting, I don't see much logical or statistical
justification for the belief that, if one increased (by
--On Monday, 07 July, 2008 17:19 + John Levine
<[EMAIL PROTECTED]> wrote:
>...
> * The proportion of invalid traffic, i.e., DNS pollution,
> hitting the roots is still high, over 99% of the queries
> should not even be sent to the root servers. We found an
> extremely strong correlation
The latest CAIDA study says:
* The overall query traffic experienced by the roots continues to
grow. The observed 2007 query rate and client rate was 1.5-3X above
their observed values in 2006
* The proportion of invalid traffic, i.e., DNS pollution, hitting the
roots is still high, over 9
>What will be the impact of having, perhaps,
>
> 1) millions of entries in the root servers, and
Let's start by considering thousands of entries, since I see little
reason to expect even that many from ICANN's current plans.
> 2) constant traffic banging on those servers?
The latest CAIDA
Historically, the view has been that bloating the root servers in that
way would be very dangerous.
Counter-claims observe that .com seems to have survived with a similar
storage and traffic pattern, so why should there be a problem moving the
pattern up one level?
because it makes the root
Lyman Chapin wrote:
If it were possible to put that aside,
would you have any other objection to single label hostnames? I know
that at least some of the interest in new gTLDs has been expressed by
companies that like the idea of using a globally-recognized trademark as
a TLD - for exampl
ECTED] On Behalf Of Vint Cerf
> Sent: Saturday, July 05, 2008 3:33 AM
> To: John C Klensin
> Cc: James Seng; [EMAIL PROTECTED]; ietf@ietf.org; Lyman Chapin
> Subject: Re: Single-letter names (was: Re: Update of RFC 2606 based on the
> recent ICANN changes?)
>
> john,
>
&g
john,
my reaction was specific to IDN single character TLDs. In some
languages these are complete words.
vint
On Jul 4, 2008, at 1:50 PM, John C Klensin wrote:
Vint,
In the ASCII space, there have been three explanations offered
historically for the one-character prohibition on top and
s
John,
To add to your point, one should also consider the question of
embedded semantics in a single-character label.
Alphabetic scripts such as Latin mostly represent sounds used to make
up words. While one can certainly find some legitimate
single-character words (such as the article "a" or the
seems odd to me too, James.
vint
On Jul 3, 2008, at 6:14 PM, James Seng wrote:
At the moment, the condition is "no single Unicode code point." To
the extent that a single CJK ideograph can be expressed using a
single Unicode code point, this would represent the situation to
which you say you
I understand the objection to MX records in TLDs based on the past
history of how single label hostnames were (and, as Mark points out,
undoubtedly still are) handled. If it were possible to put that
aside, would you have any other objection to single label hostnames?
I know that at least s
Is "сом" identical to "com"? (the first of these is U+0441
U+043E U+043C)
The current principle is that it should be be a "confusing string",
which is vague enough to cover the case above (but perhaps not able to
cover .co)
"Similarity" can be defined and tested, by setting thresholds and the
I feel that Edmon's report of the ICANN/GNSO point of view and the
positions of James Seng are shared by most of the groups we relate
with (Internet @large, open roots, ISO lobbies, Multilinc, MINC,
Eurolinc, ISOC France, ccTLDs, etc.). If this WG does not think they
are technically adequate th
Bernard,
I'm going to try to respond to both your note and Mark's, using
yours as a base because it better reflects my perspective.
Before I go on, I think the three of us are in agreement about
the situation. The question is what can (or should) be done
about it.
--On Friday, 04 July, 2008 13:
--On Friday, 04 July, 2008 15:01 -0400 William Tan
<[EMAIL PROTECTED]> wrote:
> John,
>
> To add to your point, one should also consider the question of
> embedded semantics in a single-character label.
>
> Alphabetic scripts such as Latin mostly represent sounds used
> to make up words. While
> So the "problem" isn't whether some string not listed in 2606
> can be allocated, it is how it is used after it is allocated.
> And _that_ situation has a lot more to do about "buyer beware"
> and understanding of conflicting expectations about use than it
> does about ownership.
>
> john
> Not really. ICANN isn't "selling" single-label domains. They
> are selling (and I believe "selling" is probably now the correct
> term) plain, ordinary, TLD delegations. If I get one of those
> and populate the TLD zone only with delegation records, there
> are no problems with what ICANN has
--On Friday, 04 July, 2008 10:49 -0700 Bernard Aboba
<[EMAIL PROTECTED]> wrote:
>
>> Single label names are local in scope. Attempting to use
>> them in a global context does not work. As the names in
>> "." get more interesting the probability of collisions with
>> existing names goes up. N
Vint,
In the ASCII space, there have been three explanations offered
historically for the one-character prohibition on top and
second-level domains. I've written variations on this note
several times, so will just try to summarize here. Of the
three, the first of these is at best of only histor
>Single label names are local in scope. Attempting to use
>them in a global context does not work. As the names in
> "." get more interesting the probability of collisions with
>existing names goes up. Not many people choose two letter
> labels for the least significant parts of their host name
There is a difference between allowing protocol to be used
in a "local" only mode (single label) and a "global" mode
(multi-label) and saying you must support single label in
a global context.
If a protocol is used in a global mode, the problem with trying to
--On Friday, 04 July, 2008 09:14 +1000 Mark Andrews
<[EMAIL PROTECTED]> wrote:
>
>> Mark Andrews wrote:
>>
>> > The Internet went to multi-label hostnames ~20 years ago.
>>
>> As noted in RFC 2821 as "one dot required" syntax, also
>> mentioned in RFC 3696. Recently *overruled* by 2821bis.
>
>
> > Mark Andrews wrote:
> >
> > > The Internet went to multi-label hostnames ~20 years ago.
> >
> > As noted in RFC 2821 as "one dot required" syntax, also
> > mentioned in RFC 3696. Recently *overruled* by 2821bis.
>
> There is a difference between allowing protocol to be used
>
> Mark Andrews wrote:
>
> > The Internet went to multi-label hostnames ~20 years ago.
>
> As noted in RFC 2821 as "one dot required" syntax, also
> mentioned in RFC 3696. Recently *overruled* by 2821bis.
There is a difference between allowing protocol to be used
in a "local" on
Oops, ignore my email :P My reading comprehension is bad in the morning.
-James Seng
On Fri, Jul 4, 2008 at 6:31 AM, James Seng <[EMAIL PROTECTED]> wrote:
> RFC 4282 defined
>
> label = let-dig *(ldh-str)
>
> which means a single-label Unicode string would be absolutely fine
> since it t
RFC 4282 defined
label = let-dig *(ldh-str)
which means a single-label Unicode string would be absolutely fine
since it translate to xn--gibberish. A shorter gibberish of cos, but
still longer than a single character.
-James Seng
> Potential problems with global use of single-label na
Lyman said:
> I'm familiar with and understand > the
> importance of using only FQDNs in SMTP exchanges given that "[i]n > the case
> of a top-level domain used by itself in an email address, a > single string
> is used without any dots." What I'm interested in is > any reason to
> proscri
1 - 100 of 171 matches
Mail list logo
