There is a big difference between introducing a new RR to assist the discovery
process and introducing a new RR for the policy.
The problem is that publishing the same information in multiple records
inevitably leads to a risk of inconsistency. This is particularly problematic
when using the DNS as the records are cached and there are long timeouts by
network administration standards.
I really really dislike protocols that lead to admin situations where the admin
makes a change and the problems it causes only become apparent several hours
after they make the change.
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Arvel Hathcock
Sent: Friday, June 01, 2007 10:30 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] SSP issues
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying "if you support TXT, don't bother with
anything else." Again, no clear consensus.
If a new RR can solve the wildcard issue and we feel that
this is a significant issue worth solving (or at least
addressing) then perhaps we should create a system that looks
for a new RR first and failing that, falls back to TXT.
I don't think the "if you support TXT, don't bother with
anything else" position is correct. If we come out with a
spec that states "SSP clients must query for new RR first,
then TXT" senders would be right to expect compliance. This
frees senders to deploy the new RR when they need and are
able to do so. Until then, TXT.
Arvel
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html