Eliot Lear wrote: > Scott Kitterman wrote: > >> This draft mentions the posibility of requiring a new resource record type. >> It isn't clear from the draft if the mention is in reference to the idea of >> using a new RR type in parallel with TXT for some period or if the idea is >> possibly deployment exclusively in the new RR type. >> >> If it's the latter, I think that this would be an extraordinarily bad idea. >> In my opinion, if this protocol is going to require a new RR type to go >> forward, it will never get deployed. >> >> Recommend a new requirement that the protocol MUST NOT depend solely on a >> new >> DNS RR type just so there won't be any confusion on this. >> >> > > I would suggest that whatever approach SSP uses be consistent with what > has been done with the base protocol. > The considerations aren't quite the same. In the case of the base protocol, the signature can tell (via the q= tag value) what method to use, including which record type, to retrieve the key.
In the case of SSP, there's nothing to tell the verifier how to retrieve the SSP record. If there is more than one way to publish SSP, then the verifier has to try each one until they find a record or run out of methods. This makes it a much bigger burden, both on the verifier and the infrastructure, to have more than one lookup method. The question then becomes whether that method should be a TXT record (presumably with some prefix) or some other RR (not necessarily with a prefix). -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
