On Tue, Nov 15, 2005 at 12:05:15PM -0600, wayne allegedly wrote:
In <437A1D33(_dot_)3090605(_at_)mtcc(_dot_)com> Michael Thomas
<mike(_at_)mtcc(_dot_)com> writes:
wayne wrote:
Why the three months between the SSP I-D and the DNS recourse record?
Can't we just use a TXT RR clone the way SPF did?
The main reason is so that we don't have to b64 encode the public
key. Beyond that, it may well be just a drop in TXT clone of the
rest.
Won't people have to b64 encode the public key anyway to put it into
their zone file?
Are you talking about the representation as input to a DNS content
server or are you talking about the binary representation of the RR?
The former may well be b64, but that doesn't imply the latter.
I think there are strong reasons to just keep it simple. Just use a
clone of the TXT record for the DKK and DKP records. Define this in
the -base and -ssp documents and be done with it. The SPF spec does
it this way and it is really very trivial.
All the implementations are going to have to support the parsing of
TXT records anyway, so adding support for TXT record clones saves a
lot of extra work. That, and we can cut out an entire I-D and 3
months out of the development process.
These are reasonable arguments. The complexity of a Selector when
converted to a binary representation is significant. There are at many
types that need to be encoded: Flags, timestamps, email addresses,
key-data, key-type and some are variable length.
None of the encoding is rocket-science, but above and beyond the
cost-benefit issue is the very real risk of loss of flexibility.
Mark.
_______________________________________________
ietf-dkim mailing list
http://dkim.org