Steve Atkins wrote:
On Jan 28, 2009, at 8:49 PM, Dave CROCKER wrote:
So I'd be interested in seeing your basis for believing that it is
an order of magnitude more complex that it needs to be...
Look at the current thread. Removing just i= and it's friends would
reduce the confusion *of people who are deeply involved in the spec*
by a large factor.
As a measure of energy, that makes sense. I was thinking you meant technical
details; by that measure, i= doesn't take much. On the other hand, I suspect
that the amount of code affected by the d=/i= confusion probably is
disproportionately high.
Going through the spec point by point, and painting big red circles
around each element that adds more complexity than value isn't really
the point[1], but look and see that many of the fields are OPTIONAL or
RECOMMENDED and have reasonable defaults. What would the spec look
like if they all went away and were replaced by the defaults? For the
signer it would look much the same, as they can ignore all those
fields anyway. For the verifier it would be much, much less complex.
So it turns out that an exercise like this is often part of the work done in
moving an IETF specification from Proposed Standard to Draft Standard: Look
for
the features that have not gained traction and remove them from the spec.
I don't know whether DKIM is too young for such an exercise, but it might be
worth considering.
There's also ill-defined implementation/semantics of multiple
signatures, though I suspect local policy will likely make the
vagueness in spec less of an issue, and it'll probably be cleaned up
by a best practices document eventually (if it hasn't already).
In effect, that's an additional specification. That is, the base spec says how
to create and process one signature. That's the core capability. One can
treat
multiple signatures as an additional, follow-on concern. I don't mean it's not
important; merely that it's factorable.
I also note that there are others who have raised the topic. After the current
brouhaha settles down, it might be worth considering an additional document to
deal with the topic.
[1] At least not in the body of the email. Please don't consider any
of the following as picking a fight, or even demanding a response,
it's mostly just for completeness.
Very nice list and discussion of each item.
I suspect it would be worth having the 4871bis effort carefully consider each
of
your points. On the other hand, that would guarantee that the bis effort is a
substantial probject.
On the other hand, it could produce a substantially cleaner and simpler bit of
technology. As you note, that could dramatically reduce implementation and
testing effort (and thereby dramatically increase interoperability.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html