On Nov 15, 2005, at 1:21 PM, Mark Delany wrote:
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.
There are a few benefits for not cloning TXT:
1) You can avoid the errors that may come with having to break the
record up into multiple character strings.
2) If it doesn't look like a TXT, there is less likelihood for
certain vendors to do the non-standard escaping that they currently
do with TXT (this can really mess up people doing cut-and-paste).
3) There is a possibility to define a less cumbersome master file
format for the record.
-andy
_______________________________________________
ietf-dkim mailing list
http://dkim.org