On Thu, Feb 01, 2018 at 08:46:01PM -0500, Joe Abley wrote:
>
> Can we take a brief pause to acknowledge that "the DNS" as a phrase is highly
> ambiguous
Yes.
> and think about whether we mean the protocol,
I mean this and
> any particular installation or the namespace (and if so, which one,
On Fri, Feb 2, 2018 at 4:41 AM, Petr Špaček wrote:
> On 2.2.2018 09:32, Mark Andrews wrote:
>> This isn’t about whether name servers load A records with non LDH names
>> as they all can.
>>
>> The real question is do the name lookup api’s in the web browsers barf
>> on non
(Due to weirdness with email, the WGLC announcement for me came on DNSSD and
not DNSOP. Shoulder shrug - something to debug for later.)
I was told of this last call:
referring to the document at
https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-05
Overall - the approach looks
On Thu, Feb 1, 2018 at 4:26 PM, Ted Lemon wrote:
> On Feb 1, 2018, at 2:48 PM, Andrew Sullivan
> wrote:
>
> As a general principle, when what the RFC says to do is not the right
> thing to do, the solution is to update the RFC, not to ignore the
The current draft is hand-wavy when it comes to which transports DSO can
run on.
Section 2 says "such as":
The term "connection" means a bidirectional byte stream of reliable,
in-order messages, such as provided by using DNS over TCP
[RFC1035][RFC7766] or DNS over TLS [RFC7858].
The problem is that search lists are being applied when “localhost” is being
entered into name lookup APIs and is being matched against localhost.example
which isn’t expected to to a address on the current machine and that the
search list may be auto constructed or come from a untrusted
On Thu, Feb 1, 2018 at 4:37 PM, Paul Hoffman wrote:
> On 1 Feb 2018, at 13:20, Andrew Sullivan wrote:
>
> It seems plain therefore that a registry of in-band in-label prefixes
>> ought to be created, so that instead of heuristics in IDNA2008 we
>> could tell people to use
This isn’t about whether name servers load A records with non LDH names
as they all can.
The real question is do the name lookup api’s in the web browsers barf
on non IDN, non LDH names since that is the mechanism being proposed
for people to test this.
Mark
> On 2 Feb 2018, at 6:50 pm, Petr
On 02/02/2018 08:32, Mark Andrews wrote:
> The real question is do the name lookup api’s in the web browsers barf
> on non IDN, non LDH names since that is the mechanism being proposed
> for people to test this.
+1 - that's my concern too.
The browsers that refuse to accept an underscore
On 2.2.2018 09:32, Mark Andrews wrote:
> This isn’t about whether name servers load A records with non LDH names
> as they all can.
>
> The real question is do the name lookup api’s in the web browsers barf
> on non IDN, non LDH names since that is the mechanism being proposed
> for people to
10 matches
Mail list logo