On Feb 23, 2006, at 7:09 PM, Mark Delany wrote:
On Thu, Feb 23, 2006 at 06:53:29PM -0800, Douglas Otis allegedly
wrote:
By the time this size key is needed, hopefully DNSsec is also
available.
Or more realistically RFC2671 published 1999 and on standards track.
This becomes required with DNSsec which lacks name compression and
adds additional overhead. Until DNSsec blazes that trail, everyone
will continue to bump their head on the low branches.
There was not a suggestion to use a new binary record. The
proposal was to employ an existing record in a binary fashion.
I presume you mean to *change* an existing one to support the extra
Selector goop invent here (and yet to be invented in the coming
months).
This could be the TLV structure replacing the 't=value;' approach.
There is not much need for creativity. This structure could be
placed upon an even boundary by having a byte value defined following
the algorithm field such as "group". : )
0 5 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tag | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ value \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
tag
---
0 = reserved
1 = key data
2 = granularity
3 = services
4 = notes
5 = test
6 - 15 reserved
If this looks okay, a draft and sample code populating and reading
this resource record can be provided. It seems like a good investment.
I also presume you have the support of the original authors and
consumers of your favoured alternative RR to make such changes and
extensions? Barging in on someone's favour RR and wanting to change
it without their support would prove to be a very painful, yes?
Use of this RR as suggested does not impact RFC2538 or the pending
revision. The DKIM Key and signature header provides the same
function as a CERT RR. DKIM also takes the step of using a unique
label to access this RR. Only an IANA assignment should be needed
based upon consensus of the DKIM wg. In every case, a separate
document describes the structure of the data following the CERT
header. An overview of DKIM would not be missed. If this wg is
interested in pursing this, I'll be happy to follow up with those
involved and report back.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html