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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Arvel Hathcock > Sent: Friday, June 01, 2007 10:30 PM > To: [email protected] > 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
