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