On Wed, Aug 24, 2022 at 6:19 PM Paul Hoffman wrote:
> On Aug 24, 2022, at 5:14 PM, Brian Dickson
> wrote:
> > "at this stage" is only the case due to the draft not being explicit in
> the flow.
>
> Are you saying that it was explicit after WG Last Call but changed? Or
> during IETF Last Call and
On Aug 24, 2022, at 5:14 PM, Brian Dickson
wrote:
> "at this stage" is only the case due to the draft not being explicit in the
> flow.
Are you saying that it was explicit after WG Last Call but changed? Or during
IETF Last Call and was changed?
> Yes, this is a non-editorial change.
Also ca
On Wed, Aug 24, 2022 at 4:11 PM Eric Orth wrote:
>
>
> On Wed, Aug 24, 2022 at 4:58 PM Viktor Dukhovni
> wrote:
>
>> * When the initial SVCB (also HTTPS, ...) query returns an AliasMode
>> result, lookup failures in all subsequent SVCB/HTTPS queries are
>> "fatal"
>> even for SVC
On Wed, Aug 24, 2022 at 07:11:16PM -0400, Eric Orth wrote:
> > Regarless, once AliasMode records are found, these MUST be used and
> > partial lookup failure along a non-empty (so far) alias chain needs
> > to be fatal.
>
> This would be a big non-editorial change from the current draft, and I
>
On Tue, Aug 23, 2022 at 02:51:33PM -0700, Brian Dickson wrote:
>- The problem is whether/when/how the DNS queries are considered
>failures, and whether/when/how some sort of fall-back procedure is followed
>in those cases.
Indeed "failure" may not be consistently defined.
- On the
> On 24. Aug 2022, at 22:13, Schanzenbach, Martin
> wrote:
>
> Signed PGP part
>
>
>> On 24. Aug 2022, at 20:22, Joe Abley wrote:
>>
>> On Aug 24, 2022, at 11:27, Schanzenbach, Martin
>> wrote:
>>
>>> We (I) learned that this is a good approach after conversations with our
>>> reviewer
> On 24. Aug 2022, at 20:22, Joe Abley wrote:
>
> On Aug 24, 2022, at 11:27, Schanzenbach, Martin
> wrote:
>
>> We (I) learned that this is a good approach after conversations with our
>> reviewers in particular since it is very difficult to distinguish what
>> "case" actually is with resp
It appears that Paul Wouters said:
>On Wed, 24 Aug 2022, John Levine wrote:
>
>> Many people believe that but it's not entirely true.
>>
>> While most mail systems treat upper and lower case in local parts the same,
>> I have occasionally seen setups where you can send mail to sek...@example.com
On Wed, 24 Aug 2022, John Levine wrote:
Many people believe that but it's not entirely true.
While most mail systems treat upper and lower case in local parts the same,
I have occasionally seen setups where you can send mail to sek...@example.com
and other capitalizations bounce.
In my 30 yea
On Aug 24, 2022, at 11:27, Schanzenbach, Martin wrote:
> We (I) learned that this is a good approach after conversations with our
> reviewers in particular since it is very difficult to distinguish what "case"
> actually is with respect to i18n.
Fortunately (at least as far as understanding do
It appears that Paul Wouters said:
>On Aug 24, 2022, at 11:27, Schanzenbach, Martin
>wrote:
>>
>> GNS, as in the protocol, does *not* consider "Example.gns.Alt" and
>> "Example.gns.alt" to be the same name.
>
>FYI, on many mobile phones, words at the start are automatically capitalized,
>so
> On 24. Aug 2022, at 18:46, Paul Wouters wrote:
>
> On Aug 24, 2022, at 11:27, Schanzenbach, Martin
> wrote:
>>
>> GNS, as in the protocol, does *not* consider "Example.gns.Alt" and
>> "Example.gns.alt" to be the same name.
>
> FYI, on many mobile phones, words at the start are automatic
On Aug 24, 2022, at 11:27, Schanzenbach, Martin wrote:
>
> GNS, as in the protocol, does *not* consider "Example.gns.Alt" and
> "Example.gns.alt" to be the same name.
FYI, on many mobile phones, words at the start are automatically capitalized,
so you are going to experience many user problem
> On 08/24/2022 11:27 AM EDT Schanzenbach, Martin
> wrote:
> If the application decides that the user expectation is that "example.ch.Alt"
> IS "example.ch.alt", then the application is invited to make the user happy
> accordingly.
I see. I understand now. You don't need the IETF for this
Hi,
> On 24. Aug 2022, at 16:28, Peter Thomassen wrote:
>
> Hi Joe,
>
> On 8/24/22 10:13, Joe Abley wrote:
>> So the question is not whether to allow mixed capitalisation; the question
>> is why we would intentionally change a fundamental expectation of domain
>> names to accommodate names an
Hi Joe,
On 8/24/22 10:13, Joe Abley wrote:
So the question is not whether to allow mixed capitalisation; the question is
why we would intentionally change a fundamental expectation of domain names to
accommodate names and resolution protocols that we largely don't have any
requirements for be
On 24.08.22 16:13, Joe Abley wrote:
Hi Peter,
So the question is not whether to allow mixed capitalisation; the question is
why we would intentionally change a fundamental expectation of domain names to
accommodate names and resolution protocols that we largely don't have any
requirements f
On Aug 24, 2022, at 10:13, Joe Abley wrote:
> That's a large installed base of assumptions; to a close approximately it's
> all users of the internet and all software that makes use of it.
Approximation, not approximately. My phone and I have different ideas about
language, soapy about thatch.
Hi Peter,
On Aug 24, 2022, at 09:40, Peter Thomassen wrote:
> On 8/23/22 18:37, Joe Abley wrote:
>> So your suggestion is that this document should specify behaviour for QNAMEs
>> whose final label is exactly "alt" but that names with different
>> capitalisation should be leaked to the DNS?
>
On 8/23/22 18:37, Joe Abley wrote:
On Aug 23, 2022, at 18:07, Peter Thomassen wrote:
Unaware applications: yes, perhaps mixed; but as they're unaware, they'll
ignore the carve-out regardless of case
Aware applications: ... will produce only what's compliant. And the question
here is what
Hi Ted,
sorry for the late reply!
re scenarios: during bootstrappign, a constrained requires CoAP and
DNS client capablities. for example, when an LwM2M client registers at a
LwM2M server, which acts as a partial CoAP Resource Directory.
re: your statement "The privacy benefit of DoH wou
21 matches
Mail list logo
