> On 08/18/2022 10:17 PM EDT Ben Schwartz
> wrote:
>
> Perhaps you haven't been following the W3C DID process [1]? The
> "registrable .alt" proposal closely resembles the functionality of the DID
> "method" system, and you can see the registrations that have poured in
> there [2]. I note tha
I could have been clearer. The names can be duplicates, not the rest of the
entry. So someone comes along and registers web.alt with a pointer to her
thing, then someone else comes along with a different thing but also calls it
web.alt, and we another entry in the registry.
What does the r
On Fri, 19 Aug 2022, John R Levine wrote:
I could have been clearer. The names can be duplicates, not the rest of
the entry. So someone comes along and registers web.alt with a pointer
to her thing, then someone else comes along with a different thing but
also calls it web.alt, and we ano
Hiya,
On 19/08/2022 14:35, Paul Wouters wrote:
Okay, so I understood that you want to run a yellow pages for non-DNS
domains at IANA.
FWIW, that doesn't describe where I've so far
landed on this. It omits the requirement that
there be an RFC for each entry. That IMO does
mean such a registry
On Fri, 19 Aug 2022, Stephen Farrell wrote:
domains at IANA.
FWIW, that doesn't describe where I've so far
landed on this. It omits the requirement that
there be an RFC for each entry.
As I've said several times, most recently yesterday, if we make people
jump through hoops to put their name
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : The ALT Special Use Top Level Domain
Authors : Warren Kumari
Paul Hof
Greetings again. The recent traffic on the list shows a strong interest in
reviving draft-ietf-dnsop-alt-tld, hopefully to get it out of the WG and into
the IETF, then publication as an RFC.
In the past, the WG has gotten quite borked on some of the details in the
draft, many of which were not
One tidbit that might have been overlooked, is that draft-schanzen-gns (and
the various documents it references, including stuff in github) has a
technical problem.
The TL;DR: is that nsswitch (and similar systems) depend on individual
resolution mechanisms (whatever those may be) returning NXDOMA
Hi Brian,
thank you for the feedback.
> On 19. Aug 2022, at 16:46, Brian Dickson
> wrote:
>
> One tidbit that might have been overlooked, is that draft-schanzen-gns (and
> the various documents it references, including stuff in github) has a
> technical problem.
>
> The TL;DR: is that nsswi
> On 19. Aug 2022, at 17:06, Schanzenbach, Martin
> wrote:
>
> Signed PGP part
> Hi Brian,
>
> thank you for the feedback.
>
>> On 19. Aug 2022, at 16:46, Brian Dickson
>> wrote:
>>
>> One tidbit that might have been overlooked, is that draft-schanzen-gns (and
>> the various documents it
On Fri, 19 Aug 2022, Paul Hoffman wrote:
Support and opposition are welcome, but suggested text changes are even more
welcome. Once we get this right, Warren and I will ask for another WG Last Call
so that it can move on.
NIT: I think the abstract should mention any IANA registries created.
On Aug 19, 2022, at 11:06 AM, Paul Wouters wrote:
> Section 2:
>
> DNS resolvers that serve the DNS protocol and non-DNS protocols at
> the same time might consider .alt like an entry in the "Transport-
> Independent Locally-Served DNS Zone Registry" that is part of IANA's
> "Locally-Serv
On 8/19/2022 3:30 PM, Paul Hoffman wrote:
DNS resolvers that serve the DNS protocol and non-DNS protocols at
the same time MUST resolve .alt names using the non-DNS protocols.
It was written the current way as a way to alert developers who are using the
Locally-Served DNS Zones registry t
On Fri, Aug 19, 2022 at 2:06 PM, Paul Wouters wrote:
> On Fri, 19 Aug 2022, Paul Hoffman wrote:
>
> Support and opposition are welcome, but suggested text changes are even
> more welcome. Once we get this right, Warren and I will ask for another WG
> Last Call so that it can move on.
>
> NIT: I t
Hiya,
On 19/08/2022 20:43, Warren Kumari wrote:
So, it is perfectly acceptable (in my view) for it to have:
ReferenceName
-
a-cool-document foo.alt
another-documentfoo.alt
yet-another-doc bar.alt
I agree that such duplicate names
The following errata report has been verified for RFC8552,
"Scoped Interpretation of DNS Resource Records through "Underscored" Naming of
Attribute Leaves".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7064
-
On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell
wrote:
> Hiya,
>
> On 19/08/2022 20:43, Warren Kumari wrote:
>
> So, it is perfectly acceptable (in my view) for it to have:
>
> Reference Name
> -
> a-cool-document foo.alt
> another-document foo.alt
> yet-another-d
Hiya,
On 20/08/2022 01:55, Warren Kumari wrote:
On Fri, Aug 19, 2022 at 5:46 PM, Stephen Farrell
wrote:
Hiya,
On 19/08/2022 20:43, Warren Kumari wrote:
So, it is perfectly acceptable (in my view) for it to have:
Reference Name
-
a-cool-document foo.alt
anot
18 matches
Mail list logo
