On Tue, Aug 23, 2022 at 9:15 AM Paul Hoffman wrote:
> On Aug 23, 2022, at 8:50 AM, Warren Kumari wrote:
> > I think that is helpful to communicate expectations,
>
> Is the suggestion that the non-DNS protocol follow the DNS wire format
> and/or presentation format now an expectation? This seems
On 23/08/2022 16:45, Peter Thomassen wrote:
I think their point is that the application (e.g. browser) may be
agnostic of the resolution system (= accept the name), but resolution
may fail because something switching layer like nsswitch would choke
on a non-DNS-style name, *even when* the
On 23/08/2022 17:14, Paul Hoffman wrote:
Is the suggestion that the non-DNS protocol follow the DNS wire
format and/or presentation format now an expectation? This seems like
a long jump.
The dot-separated form of a domain name _is_ a "presentation format",
even if it's not precisely that
On 8/23/22 12:31, Warren Kumari wrote:
But my question would still be: Should the registry pose limitations, then,
on the 2LD? Because you cannot really have the one without the other?
I don't think that it can (or should). This is just a suggestion… I had considered wording it as
"it
On Tue, Aug 23, 2022 at 12:09 PM, Martin Schanzenbach <
mschanzenb...@posteo.de> wrote:
> On 23. Aug 2022, at 16:47, Warren Kumari wrote:
>
> On Tue, Aug 23, 2022 at 10:29 AM, Peter Thomassen wrote:
> On 8/23/22 07:02, Ray Bellis wrote:
>
> There will be a very long tail of systems out there
On Aug 23, 2022, at 8:50 AM, Warren Kumari wrote:
> I think that is helpful to communicate expectations,
Is the suggestion that the non-DNS protocol follow the DNS wire format and/or
presentation format now an expectation? This seems like a long jump.
The purpose of .alt is to let anyone do
> On 23. Aug 2022, at 16:47, Warren Kumari wrote:
>
>
>
>
>
> On Tue, Aug 23, 2022 at 10:29 AM, Peter Thomassen wrote:
> On 8/23/22 07:02, Ray Bellis wrote:
>
> There will be a very long tail of systems out there that do not know about
> ".alt".
>
> How would those systems respond when
On Tue, Aug 23, 2022 at 11:45 AM, Peter Thomassen wrote:
> On 8/23/22 11:38, Paul Hoffman wrote:
>
> On Aug 23, 2022, at 7:47 AM, Warren Kumari wrote:
>
> So, I'd think something like: "For compatibility with existing
> applications and to maximize interoperability, it is recommended that names
On 8/23/22 11:38, Paul Hoffman wrote:
On Aug 23, 2022, at 7:47 AM, Warren Kumari wrote:
So, I'd think something like: "For compatibility with existing applications and to
maximize interoperability, it is recommended that names that end in .alt follow DNS name
syntax." (or something similar
On Aug 23, 2022, at 7:47 AM, Warren Kumari wrote:
> So, I'd think something like: "For compatibility with existing applications
> and to maximize interoperability, it is recommended that names that end in
> .alt follow DNS name syntax." (or something similar but better worded).
An application
On Tue, Aug 23, 2022 at 10:29 AM, Peter Thomassen wrote:
> On 8/23/22 07:02, Ray Bellis wrote:
>
> There will be a very long tail of systems out there that do not know about
> ".alt".
>
> How would those systems respond when passed a domain-style name that does
> not meet domain-style syntax
Hi,
On Aug 23, 2022, at 4:18 AM, Schanzenbach, Martin
wrote:
>> IMHO, if you want to be in a carve-out of the domain name space, you still
>> need to play by the domain name space's technical rules, in a way that's
>> backwards compatible with systems that don't know about the carve-out and
On 8/23/22 07:02, Ray Bellis wrote:
There will be a very long tail of systems out there that do not know about
".alt".
How would those systems respond when passed a domain-style name that does not
meet domain-style syntax rules (specifically those for total length and label
lengths) ?
On 23/08/2022 12:18, Schanzenbach, Martin wrote:
I think the notion that there is strict "format" of a name and that
if it is not in that format is not actually part of the same
namespace is already behind us.
If that were the case then we do not need .alt at all.
Arguably you do not, but
> On 23. Aug 2022, at 13:02, Ray Bellis wrote:
>
>
>
> On 23/08/2022 10:22, Andrew McConachie wrote:
>
>> The only restriction that seems reasonable to me is prohibiting zero length
>> strings. This list convinced me other restrictions would be a bad idea.
>
> There will be a very long
On 23/08/2022 10:22, Andrew McConachie wrote:
The only restriction that seems reasonable to me is prohibiting zero
length strings. This list convinced me other restrictions would be a bad
idea.
There will be a very long tail of systems out there that do not know
about ".alt".
How
On 22 Aug 2022, at 16:05, Paul Hoffman wrote:
On Aug 22, 2022, at 2:41 AM, Andrew McConachie
wrote:
Why not allow unicode or at least some subset of it?
It already does. The DNS is a binary format with a common assumption
(but not requirement!) of LDH characters.
This is the bit that
> On 22. Aug 2022, at 20:33, Paul Hoffman wrote:
>
> On Aug 22, 2022, at 11:24 AM, Schanzenbach, Martin
> wrote:
>> But I also think that if it is expected that name systems may "go rogue"
>> e.g. use a new innovative new string encoding, then the registry might have
>> trouble
Schanzenbach, Martin wrote on 2022-08-22 12:17:
So maybe Unicode provides sensible guide lines for acceptable strings under
.alt _for the registry_?
just... no. if somebody wants to put binary gibberish "under" .ALT, in a way
that browser plugins never get to see because it's not valid
> On 08/22/2022 3:46 PM EDT Timothy Mcsweeney wrote:
>
> Martin,
> You should talk to Eliot about using the Drop# URI. I think he is getting
> ready to push it upstream anyways and you could potentially just add it to
> your draft. Then you would have a URI for your GNS that is and is
Martin,
> On 08/22/2022 3:17 PM EDT Schanzenbach, Martin
> wrote:
> I mean, https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
> looks ok because "URN Namespace" is well-defined as a readable string with a
> specific encoding.
You should talk to Eliot about using the Drop#
> On 22. Aug 2022, at 20:47, Paul Vixie wrote:
>
>
>
> Schanzenbach, Martin wrote on 2022-08-22 11:24:
>>> On 22. Aug 2022, at 20:15, Paul Vixie
>>> wrote:
>>> ...
>>> noting: by describing this as a reserved name subspace, we implicitly
>>> expect that the presentation form of any
Schanzenbach, Martin wrote on 2022-08-22 11:24:
On 22. Aug 2022, at 20:15, Paul Vixie wrote:
...
noting: by describing this as a reserved name subspace, we implicitly expect that the
presentation form of any namespace thus enabled will be "compatible enough"
with DNS presentation form
On Aug 22, 2022, at 11:24 AM, Schanzenbach, Martin
wrote:
> But I also think that if it is expected that name systems may "go rogue" e.g.
> use a new innovative new string encoding, then the registry might have
> trouble listing/registering the 2LD "byte string" chosen by the name system?
> On 22. Aug 2022, at 20:15, Paul Vixie
> wrote:
>
>
>
> Schanzenbach, Martin wrote on 2022-08-22 11:02:
>> ...
>>> On 22. Aug 2022, at 19:07, Ray Bellis wrote:
>>> ...
>>> On 22/08/2022 15:05, Paul Hoffman wrote:
...
>> I do not see why names under .alt must be compliant standard DNS
Schanzenbach, Martin wrote on 2022-08-22 11:02:
...
On 22. Aug 2022, at 19:07, Ray Bellis wrote:
...
On 22/08/2022 15:05, Paul Hoffman wrote:
...
I do not see why names under .alt must be compliant standard DNS names for any
reason.
+1.
noting: by describing this as a reserved name
> On 08/22/2022 2:01 PM EDT Ray Bellis wrote:
>
> You can't have a "root" label in the middle of a domain-style name,
> because the presence of the length == 0 byte for the root label is what
> marks the _end_ of the name parsing sequence.
Sorry, I guess I meant authoritative name server for
> On 22. Aug 2022, at 19:07, Ray Bellis wrote:
>
>
>
> On 22/08/2022 15:05, Paul Hoffman wrote:
>
>> I would prefer that they choose whatever is best for their own
>> non-DNS user community, which might still be ASCII.
>
> Since this came up earlier in the thread(s), I would also strongly
On 22/08/2022 18:42, Timothy Mcsweeney wrote:
Why would they do that? And why wouldn't they just serve up their
own root from within a subdomain they already have. Maybe everyone
should have their own root, I mean isn't that what this .Alt
registry is??
You can't have a "root" label in
Inline
> On 08/22/2022 1:07 PM EDT Ray Bellis wrote:
> Since this came up earlier in the thread(s), I would also strongly
> advise that users of .alt do not stray from the DNS standard
Why would they do that?
And why wouldn't they just serve up their own root from within a subdomain they
On 22/08/2022 15:05, Paul Hoffman wrote:
I would prefer that they choose whatever is best for their own
non-DNS user community, which might still be ASCII.
Since this came up earlier in the thread(s), I would also strongly
advise that users of .alt do not stray from the DNS standard of
On Aug 22, 2022, at 2:41 AM, Andrew McConachie wrote:
> The draft doesn’t specify if this registry is restricted to ASCII LDH or not.
Correct. Do you feel that it should specify that level of detail? Other
registries for domain names do not have this level of detail attached to them,
but this
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
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
>
34 matches
Mail list logo
