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 relevant
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 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
--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 orders? 20K?
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
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
as a
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 what
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
-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 end are
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
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
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
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:
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
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 of France
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
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 design
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
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 express all
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;
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.
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
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
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
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
--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
presence of dot
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 with
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
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.
--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 was handed
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
like,
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
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
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
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
: 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,
my reaction was specific to IDN single character TLDs. In some
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
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
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
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
--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 both
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
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,
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
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
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
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 your
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
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 to work,
--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 expressed by
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 cease to
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 chaos
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
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 evidence that
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
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
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
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 other
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, [EMAIL
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 by
--===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
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
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
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. :-)
=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
depends apon
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 and their
--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
presence
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
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 any
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
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, the
--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 921 that
--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
--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.
There is
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
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 names
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
--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. Not many
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 done at
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
I
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
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
John C Klensin wrote:
http://[10.0.0.6]/ anyone?
My bastard browser from hell eats http://[208.77.188.166]/
It's certainly no STD 66 URL. But it won't surprise me if
the URL-bis, charset-bis, net_2.0-bis, MIME-bis, XHTML-bis,
(etc. ad nauseam) effort styling itself as HTML5 decrees
that this
On Thu, Jul 03, 2008 at 09:23:58AM +1000,
Mark Andrews [EMAIL PROTECTED] wrote
a message of 32 lines which said:
No sane TLD operator can expect http://tld; or [EMAIL PROTECTED]
to work reliably.
[Mark, you used non-RFC2606 names, the IESG will put a DISCUSS against
you.]
I
Hi Mark,
At 21:48 02-07-2008, Mark Andrews wrote:
The key word word is reliably. http://museum/ can never
be guarenteed to work.
I saw the key word and I agree with you. Someone out there thought
that it was a good idea or else we wouldn't be discussing about
this. Your
On Thu, Jul 03, 2008 at 09:23:58AM +1000,
Mark Andrews [EMAIL PROTECTED] wrote
a message of 32 lines which said:
No sane TLD operator can expect http://tld; or [EMAIL PROTECTED]
to work reliably.
[Mark, you used non-RFC2606 names, the IESG will put a DISCUSS against
you.]
John C Klensin wrote:
http://[10.0.0.6]/ anyone?
My bastard browser from hell eats http://[208.77.188.166]/
It's certainly no STD 66 URL. But it won't surprise me if
the URL-bis, charset-bis, net_2.0-bis, MIME-bis, XHTML-bis,
(etc. ad nauseam) effort styling itself as HTML5 decrees
that this
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.
No sane TLD operator can expect http://tld; or [EMAIL PROTECTED]
to work reliably.
Certainly not
On Thu, Jul 3, 2008 at 7:01 AM, John C Klensin [EMAIL PROTECTED] wrote:
Any proposal for a new gTLD must satisfy a number of string
criteria that will be specified explicitly in the RFP,
including the requirements that the U-label must not:
(a) be identical to an existing TLD;
Is сом
James Seng wrote:
if the character is defined more broadly to cover U-label
character, then I would have strong objections.
+1 And fortunately it's not our job to figure out what a term
like IDN ccTLD actually means, where that might be important.
I remember it is a standing tradition that
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 would object. I will dig through my notes to find
out why the single character
Lyman said:
I'm familiar with draft-klensin-rfc2821bis-10.txt 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
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
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
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 only mode
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 only
In a more sane world, no one rational would want to build a
business or other activity around a TLD named local. But
this is demonstrably not a sane world.
Right. I can see the business case for this. :-(
But at least in the first round, the barrier to entry is so high that
I don't see that
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?
Tony Finch wrote:
Speaking technically, how would you distinguish the top-level domain
127.0.0.1 from the IP address 127.0.0.1?
A word while passing here: is there a document (RFC, Posix standard,
whatever) which says which
blush
Thanks!
Steve
On Jul 1, 2008, at 6:36 PM, John Levine wrote:
This does not mean that ICANN won't listen to the IETF; it means
that there will be voices more familiar to ICANN saying things
different than we are.
One of the few ICANN committees that actually works is the SSAC, the
(It's always a bummer when ietf-general turns into ICANN-general, but
in this case it seems like a useful discussion because the IETF will
probably be asked policy questions for various proposed TLDs.)
At 10:17 AM -0400 7/2/08, Thomas Narten wrote:
In a more sane world, no one rational
1 - 100 of 150 matches
Mail list logo
