On Friday 01 June 2007 22:30, Arvel Hathcock wrote:
(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.
I think this is sensible. "If you support TXT, don't bother with anything
else" approach is appropriate if the new RR functions identically to TXT.
There is no incentive to migrate. In this case, where the new RR provides
additional functionality, the incentive to migrate is built in.
Since initially there will be little to no support for the new RR, the RFC
language should be something long the lines of SHOULD query new RR first,
MUST query new RR or TXT so that DNS queries for the initially non-existant
new RR types are not required for compliance.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html