On Sunday 15 October 2006 22:31, Jim Fenton wrote: > 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). > OK. That makes sense.
It takes a long time to get deployment on a new RR. IMO, going to a new RR is closely equivalent to cancelling SSP. By the time a new RR is widely useable, things will have moved on. My vote is use TXT with "_". If a new RR type is going to be used, we may as well quit and go home now. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
