Wayne,
The timing for the May, Sept. & Dec deliverables is designed
to let us have a f2f meeting before each, then give the editors
time to react to produce a new I-D for WG last call.
Some of us who chatted in Vancouver discussed whether or not
there should be any reference from the base spec to ssp and
seemed to agree that removing such references is better for
a bunch of reasons (to be confirmed on the list of course),
so there really oughtn't be an ssp affects base problem. If
there were, then the WG could always take the base spec back
from the AD were a major change warranted and then re-do the
last call. Personally, I wouldn't envisage that though.
Regards,
Stephen.
wayne wrote:
In <43761343(_dot_)1000700(_at_)watson(_dot_)ibm(_dot_)com> Barry Leiba
<leiba(_at_)watson(_dot_)ibm(_dot_)com> writes:
---------------------------------------------------------------------
DRAFT IETF WORKING GROUP CHARTER
8 Nov 2005
[snip]
I have read the charter (that I snipped), and I like it. I didn't see
anything that I really objected to, with the exception of the
following stuff:
GOALS AND MILESTONES:
02/06 WG last call on DKIM threats and security requirements
05/06 WG last call on DKIM signature specification
09/06 WG last call on DKIM policy specification
I'm somewhat concerned about the 4 month lag between these two
documents. I'm afraid that stuff we will learn by finishing the SSP
will require changes to the base DKIM spec.
12/06 WG last call on DKIM DNS Resource Record
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?
It makes the transition much easier (just query a new RR number, very
few other changes in the code). I once created a binary encoding for
SPF records. I worked hard to make it compact, yet expandable. In
practice, you did well to get a factor of 2 size reduction. Most of
the size reduction was due to IPv4 addresses in text being very large
(4 bytes vs up to 15 bytes), something that DKIM doesn't have.
Text works well. It is flexible. It can be reasonable compact. It
is what we have today. Yes, it has to be parsed, but for security
reasons, you end up having to do a lot of work to validate that a
binary structure is correct.
12/06 WG last call on overview document
-wayne
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org