No it is not a pedantic difference.
If it isn't in a registry it didn't happen.
It is like when someone decided to do an April Fools RFC which used a code
point in PKIX space that wasn't actually registered with IANA. That caused
some real chaos.
Protocol matters. And just because IANA does 'ass
On 6 Oct 2016, at 18:09, Phillip Hallam-Baker wrote:
On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis
wrote:
RFC 3490 does say something about the ACE prefix.
It says it has been registered but not where and there is no IANA
registry that references RFC3490
It does not say it was "register
On 10/6/16 3:58 PM, Stephane Bortzmeyer wrote:
On Thu, Oct 06, 2016 at 01:47:28PM -0400,
John R Levine wrote
a message of 34 lines which said:
It still seems to me that the time to add the wildcards back in
would be less than the time to do two separate documents. Unless
there's some reas
> If someone can just start using a name and thus make it too hard
> to delegate we have a much a bigger problem.
That's been true approximately forever, viz. .onion, .belkin, .corp,
.local, .mail, and probably still .uucp that are too poisoned to allow
reliable delegation and new use. That's why
On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis wrote:
> Robert Edmonds writes:
>
> > Donald Eastlake wrote:
> > > Sure, you can consider the root zone to be the registry for TLDs but
> the
> > > point is the xn-- labels are recommended to be interpreted specially
> at the
> > > user interfac
If you can come up with an efficient, "fair" and trusted process for a
unitary name space on domain principles (domains of scope. trees.)
that doesn't confront collisions over desires for labels at arbitrary
points in the tree, and of essential 'centrality' in decision making
logic over things espe
Robert Edmonds writes:
> Donald Eastlake wrote:
> > Sure, you can consider the root zone to be the registry for TLDs but the
> > point is the xn-- labels are recommended to be interpreted specially at the
> > user interface at all levels...
>
> Nor would this say anything about "CCHH" pref
Donald Eastlake wrote:
> Sure, you can consider the root zone to be the registry for TLDs but the
> point is the xn-- labels are recommended to be interpreted specially at the
> user interface at all levels...
Nor would this say anything about "CCHH" prefixed labels in general.
At the TLD level t
On Thu, Oct 06, 2016 at 01:47:28PM -0400,
John R Levine wrote
a message of 34 lines which said:
> It still seems to me that the time to add the wildcards back in
> would be less than the time to do two separate documents. Unless
> there's some reason that this needs to be published in a hurry
Hi,
On Thu, Oct 6, 2016 at 3:14 PM, Jim Reid wrote:
> > On 6 Oct 2016, at 18:59, Donald Eastlake wrote:
> > I don't believe there is a registry.
>
> Actually there is. Sort of:
% whois -h whois.iana.org テスト
> % IANA WHOIS server
> % for more information on IANA, visit http://www.iana.org
> % T
> On 6 Oct 2016, at 18:59, Donald Eastlake wrote:
>
> I don't believe there is a registry.
Actually there is. Sort of:
% whois -h whois.iana.org テスト
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
domain: テスト
domain-ace: XN-
On 6 Oct 2016, at 10:08, Phillip Hallam-Baker wrote:
I have been looking for the IANA registry in which the IDNA prefix
xn-- is
allocated and have not been able to find it. I can see the following
possibilities
1) There isn't such a registry. The allocation is purely ad hoc
2) There is a regi
I don't believe there is a registry. It would seem reasonable to reserve
labels starting with all other [a-z][a-z]-- besides xn-- and establish a
registry. (To avoid people trying to squat on names in advance, the "xn"
was selected by the same sort of publicly verifiable random process as
nomcom vo
On Thu, Oct 6, 2016 at 1:24 PM, wrote:
>
> >I have been looking for the IANA registry in which the IDNA prefix xn--
> is allocated and have not been able to find it. I can see the following
> possibilities
>
> >1) There isn't such a registry. The allocation is purely ad hoc
>
> >2) There is
I'd rather you keep it [positive answers]
+1
Keep the positive, rather than writing a separate RFC for that later.
Why not but, in that case, this would send back the document for
several weeks, since the text about positive answers in -02 was very
limited and unclear (dropping it, like -03 di
>I have been looking for the IANA registry in which the IDNA prefix xn-- is
>allocated and have not been able to find it. I can see the following
>possibilities
>1) There isn't such a registry. The allocation is purely ad hoc
>2) There is a registry but none of the IDNA RFCs bother to list it
I have been looking for the IANA registry in which the IDNA prefix xn-- is
allocated and have not been able to find it. I can see the following
possibilities
1) There isn't such a registry. The allocation is purely ad hoc
2) There is a registry but none of the IDNA RFCs bother to list it as a
nor
On Wed, Oct 05, 2016 at 03:04:25PM -0400,
Bob Harold wrote
a message of 68 lines which said:
> > I'd rather you keep it [positive answers]
> >
> > +1
> Keep the positive, rather than writing a separate RFC for that later.
Why not but, in that case, this would send back the document for
severa
On Thu, Oct 06, 2016 at 02:53:38AM -0400,
Tim Wicinski wrote
a message of 17 lines which said:
> Just a reminder that the WGLC for
> draft-ietf-dnsop-nsec-aggressiveuse will end later today (barring
> any stuck issues). The authors appear to have addressed all open
> issues
The way I underst
I have read through the draft and sent a pull request with some minor
editorial fixes.
Here are some more substantial suggestions / questions. Sorry for being so
late in the process.
Would it make sense to be more specific about how to match queries to
cached NSEC/NSEC3 records? By cross-referen
On 10/06/2016 09:22 AM, avri doria wrote:
>
> As for the so-called toxic waste names (i really find that terminology
> problematic)
>
I agree it's a problem to use that kind of vocabulary to convey a
technical context.
> the so called waste pile of usurped names
>
Therefore this is also a probl
On 04-Oct-16 09:19, David Conrad wrote:
> As far as I know, neither ICANN (the organization) nor anyone within
> ICANN (the organization) is asking whether they should delegate such
> names. Forward motion of those names is currently "indefinitely
> deferred" pending _somebody_ (not ICANN staff)
Hi,
On 06-10-16 08:53, Tim Wicinski wrote:
>
> Just a reminder that the WGLC for draft-ietf-dnsop-nsec-aggressiveuse
> will end later today (barring any stuck issues). The authors appear to
> have addressed all open issues (except JINMEI's last comments). Please
> read the current version here
The authors for this document have addressed some lingering outstanding
issues, and it appears ready for Working Group Last Call.
This starts a Working Group Last Call for:
draft-ietf-dnsop-edns-key-tag
Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-
24 matches
Mail list logo
