On Nov 15, 2005, at 11:15 AM, Mark Delany wrote:
On Tue, Nov 15, 2005 at 01:43:59PM -0500, Andrew Newton allegedly
wrote:
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).
Right. If that is the path to take, let's make it similar to a TXT but
withut the problems. Say,
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
| Length | value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+
A 16bit unsigned length followed by txt.
That eliminates 1) and 2).
Extensibility is generally handled by adopting a Tag/Length/Value
(TLV) format which allows extensibility while retaining binary
representation.
3) There is a possibility to define a less cumbersome master file
format for the record.
It will be interesting to see that in practice given that most master
files I've seen are positional and DKIM has numerous optional
tags. Would it end up looking something like this?
IN DKIMSEL 1 rsa sha256 - - - 34E7BC... - "marketing"
Note I'm not advocating a surrogate TXT at this time, just discussing
the options and implications.
There is also RFC2538 and RFC2538bis that already define inclusion of
keys within DNS. Is there something remarkable about DKIM that
requires a unique RR? Also note that the OpenPGP format uses a
binary key. Of course, this starts with a binary RR.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org