Historical note...
To confirm this:
The introduction of cs caused more general problems, unrelated
to name ordering, because there were systems all over the
network in computer science departments with FQDNs like
host.cs.someuniversity.edu. It was common in many of
surely we in the IETF should be able to do better than to have our mail
servers filter incoming mail based on completely irrelevant criteria
like whether a PTR lookup succeeds!
Spam filtering is sort of like chemotherapy, the difference between
the good and the bad is pretty small, and the
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
Regarding single Unicode code-point labels at the TLD level, there was quite
some discussion on this topic at the GNSO Reserved Names working group and
then at the new gTLD discussion. The final recommendation from the GNSO
was:
Single and two-character U-labels on the top level and second level
Ned Freed wrote:
Spam filtering is sort of like chemotherapy, the difference between
the good and the bad is pretty small, and the trick is to find
measures that will kill the disease without killing the patient. It's
entirely a matter of statistics, not fundamental design.
And sort of
On 3 jul 2008, at 15:57, Jeroen Massar wrote:
Which (autoconfig) you should either not be using on servers, or you
should be configuring your software properly to select the correct
outbound address.
Is it the IETF's job to tell people how to run their networks?
In my opinion, stateless
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
--On Monday, 07 July, 2008 10:30 +1000 Mark Andrews
[EMAIL PROTECTED] wrote:
...
If / when MIT stop using ai.mit.edu, [EMAIL PROTECTED] will not longer
mean [EMAIL PROTECTED] This will mean that any configuration
file that has [EMAIL PROTECTED] will now, suddenly, get a
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 personal pronoun i)
And lest someone might think that this curiosity of single
character words only applies to
In your previous mail you wrote:
Specifically, the problem Dave encountered earlier was that the ietf mail
server was rejecting mail without reverse dns, and since the ietf mail
server and the mipassoc.org/dkim.org/bbiw.net mail servers all had ip6
addresses, and ip6 is used
At 9:25 AM -0700 7/7/08, [EMAIL PROTECTED] wrote:
However, many concepts in modern Chinese
dialects require multiple syllables to express them and
therefore multiple characters to write them. So there isn't
really a one to one mapping of word, syllable, concept as
many people suppose.
While
In an earlier message, John C Klensin [EMAIL PROTECTED] wrote:
Part of the problem in that case was that, because JANET used
little-endian names internally, the big-endian foo.ucl.ac.uk (in
DNS order) had to be be mapped into uk.ac.uck.foo (in JANET
order) and vice versa. That mapping was
= according to Glen via RT (RT is a well known bug ticket system):
This check is in place at the direction of the IETF community, and has
been discussed and debated at length.
I don't recall the Last Call on that question, nor even the I-D.
seems like this calls into question the
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,
At 09:28 07-07-2008, Francis Dupont wrote:
= according to Glen via RT (RT is a well known bug ticket system):
This check is in place at the direction of the IETF community, and has
been discussed and debated at length.
I don't recall seeing any community debate before this check was
On Mon, Jul 07, 2008 at 12:25:09PM -0400, John C Klensin wrote:
--On Monday, 07 July, 2008 10:30 +1000 Mark Andrews
[EMAIL PROTECTED] wrote:
...
If / when MIT stop using ai.mit.edu, [EMAIL PROTECTED] will not longer
mean [EMAIL PROTECTED] This will mean that any configuration
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
IESG Secretary wrote:
This is a response to that appeal.
[...]
The IESG came to consensus that the use of non-example domain
names should not prevent publication of RFC2821bis, even though
the IESG finds this practice can cause harm.
Good enough, hopefully the discussed examples are updated
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 Monday, 07 July, 2008 12:08 -0700 Bill Manning
[EMAIL PROTECTED] wrote:
John, do you beleive that DNS host semantics/encoding that
form the bulk of the IDN work (stringprep, puny-code, et.al.)
are applicable -only- in the context of zone file generation
or are they
The IESG has approved the following document:
- 'Sieve Email Filtering: Editheader Extension '
draft-ietf-sieve-editheader-11.txt as a Proposed Standard
This document is the product of the Sieve Mail Filtering Language Working
Group.
The IESG contact persons are Lisa Dusseault and Chris
The IESG received an appeal from John Klensin dated June 13, 2008.
This is a response to that appeal.
1. The appeal asked for the IESG to approve RFC2821bis. (The
wording was that the blocking DISCUSS must be removed but that's a
detail of determining IESG consensus to approve a document.) The
The IESG has approved the following document:
- 'Internationalized Delivery Status and Disposition Notifications '
draft-ietf-eai-dsn-06.txt as an Experimental RFC
This document is the product of the Email Address Internationalization
Working Group.
The IESG contact persons are Lisa
60 matches
Mail list logo
