John,
Thanks for the comments.
John Levine wrote:
It sure does have a lot of informative info, and still needs lots of
work.
Given your ending comment, below, you might be amused that the approach to the
document has, so far, largely been one of "if in doubt, put it in."
This latest version is the first one to try to do any pruning, albeit
conservatively.
My first question is who the target audience is. The lengthy
discussions in sections 7, 8, and 9 leave me wondering whose questions
they're supposed to answer.
Speaking for myself, I believe the document has multiple targets, all of whom
are technical. (I suppose portions of the text could be useful for management
and even marketing, but it's clear the document is not targeting either of
them.) So, I'd say developers, administrators, operators and technical writers.
Mostly developers .
The -base document does not really contain a "system" description -- ie, DKIM
signing and validating within a context. Hence, sections 5 & 6.
Obviously 7, 8 and 9 target developers, administrators and operators.
If you see the document as being problematic for those target readers, please
elaborate.
The discussion of mailing lists in 9.3 is just wrong. (A
parenthetical comment correctly suggests it may be controversial.)
I'll send in some replacement language to clarify that in the usual
case that list owners take responsibility for managing their lists,
the list should sign the mail that passes through it, and in the
exotic case that the list does not take responsibility and recipients
want to evaluate list mail sender by sender rather than as list mail,
it may in some cases be possible to pass through the incoming
signatures.
"the usual case" is an interesting choice of language, given that there are no
DKIM-aware mailing list packages, yet. (See below, about making predictions.)
Happily, the thrust of your language isn't affected by simply removing the word
'usual'.
Please explain what you think is "just wrong" with the current language. It
will help to understand how your proposed alternative language is an
improvement. (I, too, think the section needs more work, but from your brief
description, above, I am not quite sure what particular problems you see with
the current text.)
In section 10, I do not think the first sentence means what you think
it means.
Again, speaking strictly for myself, I'd prefer to eliminate all discussion
about the future. My experience with IETF documents that attempt to predict the
future is that they are pretty much always wrong. More importantly, I'm never
quite sure what the benefit of the predictions is supposed to be.
On the other hand, explaining what types of extensions the existing system has
provided for (e.g., multiple query services) can be help readers understand the
design better. So my own preference is to have that section discuss something
like "Extensibility".
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html