Hi Mark,
On 10 Jul 2020, at 21:21, Mark Andrews wrote:
> Joe is trying to CHANGE the specification of MNAME and I’m pointing out some
> of the potential uses of the existing specification.
I think what I am actually trying to do is propose a value for the MNAME field
in cases where there is
> On 11 Jul 2020, at 02:41, Brian Dickson wrote:
>
> (Apologies for any weird quoting-style/depth issues, mail user agents aren't
> terribly consistent.)
>
> On Thu, Jul 9, 2020 at 8:03 PM Mark Andrews wrote:
>
>
> > On 10 Jul 2020, at 11:53, Joe Abley wrote:
> >
> > On 9 Jul 2020, at
On Thu, 9 Jul 2020 at 23:18, Joe Abley wrote:
> On Jul 9, 2020, at 17:18, Ben Schwartz
> wrote:
>
> This seems like a reasonable idea to me. We should be able to incorporate
> this for the next draft revision.
>
>
> I guess I'll mention that when I suggested MNAME=. to indicate that a zone
>
On 9 Jul 2020, at 23:02, Mark Andrews wrote:
>>> When you change the purpose of a field you have to consider the existing
>>> users of that field.
>>
>> The only purpose of MNAME today that I am aware of is to identify the target
>> for a DNS UPDATE. If you know of another way that the field
(Apologies for any weird quoting-style/depth issues, mail user agents
aren't terribly consistent.)
On Thu, Jul 9, 2020 at 8:03 PM Mark Andrews wrote:
>
>
> > On 10 Jul 2020, at 11:53, Joe Abley wrote:
> >
> > On 9 Jul 2020, at 18:48, Mark Andrews wrote:
> >
>
> > By that logic, DNS UPDATE
> On 10 Jul 2020, at 11:53, Joe Abley wrote:
>
> On 9 Jul 2020, at 18:48, Mark Andrews wrote:
>
>> On 10 Jul 2020, at 08:17, Joe Abley wrote:
>>
>>> On Jul 9, 2020, at 17:18, Ben Schwartz
>>> wrote:
>>>
This seems like a reasonable idea to me. We should be able to incorporate
On Thu, Jul 9, 2020 at 3:49 PM Mark Andrews wrote:
>
>
> > On 10 Jul 2020, at 08:17, Joe Abley wrote:
> >
> > On Jul 9, 2020, at 17:18, Ben Schwartz 40google@dmarc.ietf.org> wrote:
> >
> >> This seems like a reasonable idea to me. We should be able to
> incorporate this for the next draft
On 9 Jul 2020, at 18:48, Mark Andrews wrote:
> On 10 Jul 2020, at 08:17, Joe Abley wrote:
>
>> On Jul 9, 2020, at 17:18, Ben Schwartz
>> wrote:
>>
>>> This seems like a reasonable idea to me. We should be able to incorporate
>>> this for the next draft revision.
>>
>> I guess I'll
> On 10 Jul 2020, at 08:17, Joe Abley wrote:
>
> On Jul 9, 2020, at 17:18, Ben Schwartz
> wrote:
>
>> This seems like a reasonable idea to me. We should be able to incorporate
>> this for the next draft revision.
>
> I guess I'll mention that when I suggested MNAME=. to indicate that a
+1
When implementing the client, this case needs to be caught anyhow (the error of
aliasing to your own domain), so it has the effect of indicating that no
service is valid. This suggestion turns this case from an error (which still
had the desired effect), to a proper signal.
Tommy
> On Jul
On Jul 9, 2020, at 17:18, Ben Schwartz
wrote:
This seems like a reasonable idea to me. We should be able to incorporate
this for the next draft revision.
I guess I'll mention that when I suggested MNAME=. to indicate that a zone
did not accept dynamic updates, the proposal was roundly shot
We should use “HTTPS 0 .” to signal that there is no service offered. Similarly
for SVCB.
Currently “.” has no useful purpose in the alias form.
--
Mark Andrews
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
12 matches
Mail list logo
