On 11/17/10 8:08 AM, James Mitchell wrote:
Do we really want to say to 3com ...
Please see rfc1591. An application by the Comintern, also known as the
Third International, for "3int", could be rfc1591 consistent. An
application by a brand owner could not be rfc1591 consistent.
The interest in stuffing the IANA root with brands is a peculiar
interpretation of a general policy responsibility.
With that said, I'm fairly certain that the ICANN Draft Applicant Guidebook by
tells applicants that...
Please don't fail to differentiate ICANN's draft general liability
limiting language from its specifically meaningful draft language on
strings, resolvability, stability and so on.
As a thought, consider names written in the Arabic script. Being a cursive
script...
The subject has been given considerable thought.
My thoughts are this draft should re-iterate the requirement "The host SHOULD
...
It is a redundant requirement, and there is no shortage of
implementations in the field which "know" what the IANA root may
contain, and are kind enough to enforce their static knowledge, until
updated. Rinse and repeat.
James
-----Original Message-----
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
Andrew Sullivan
Sent: Wednesday, 17 November 2010 11:19 PM
To: dnsop@ietf.org
Subject: Re: [DNSOP] draft-liman-tld-names-04
On Wed, Nov 17, 2010 at 11:20:56AM +0000, Tony Finch wrote:
I believe that no requirement needs to be relaxed to allow A-labels. A
clarification might be helpful.
If no requirement is needed, then no document is needed, because the
policy realm was ceded to ICANN some years ago. We can remain quiet
and wait for someone at ICANN to write a document somewhere that
clarifies that they have changed the policy that used to be expressed
in RFC 1123.
That is blatantly broken. There is no need for any heuristic to tell IP
addresses and host names apart. This kind of code should be mocked, not
accommodated.
To my mind, this is a way of saying that anyone who has to live with
broken implementations by people who half-understand the huge volume
of DNS-related RFCs is just sweet out of luck. Too bad for them. Is
that really what we want to say?
A
--
Andrew Sullivan
a...@shinkuro.com
Shinkuro, Inc.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
