Jim, thanks for the comments.
Section 1.1 paragraph 1 is now different from the overview in
-threats. We were trying to keep the top-level description
consistent between the drafts; was this a conscious change?
I don't remember exactly how this came about. I'm happy with
changing it back for consistency, having threats change to be the
same as base, or agreeing to let them drift.
Section 1.1 bullet 1 suggest "written to the message header fields"
-> "written as a message header field"
Done.
Section 1.1 bullet 7 and bullet 9 seem redundant
I think they are slightly different. Bullet 7 says that you can get
results without updating the clients. Bullet 9 says you don't have
to update all your MTAs at once.
Section 1.3 seems like it should say something about DKIM's
scalability characteristics, not just that of email, since the
other 1.x sections are describing DKIM in various ways.
Hmm.... It also says that the any-to-any characteristic is
important, which might not be true for other services. Any suggested
wording?
Section 3.1 The INFORMATIVE IMPLEMENTERS' NOTE seems like it would
fit better later in the document such as section 3.6.
I couldn't quite get this to flow very well. It doesn't belong under
"Textual Representation" or "DNS binding" because the point is
independent of how the record is represented or delivered. It just
doesn't seem to "fit" in the overview. Perhaps I'm missing something.
Section 3.4 paragraph 5 "Only header fields listed as signed in the
signature header field are included" should say something about the
inclusion of the signature header-field itself, since it's not
listed.
I added "Note: the signature header field itself is presented at the
end of the hash, not with the other headers."
Section 3.4.2 last paragraph "the previous version" -> "a previous
version"
Actually, that entire clause can be deleted at this point.
Section 3.4.5 second to last paragraph "choose to reject" ->
"choose to ignore signatures" [this one isn't a nit]
I'm not sure we have consensus on dropping the "reject" language ---
I think Mark had some concerns. I'll add wording about ignoring the
signature though.
Section 3.6 i= tag INFORMATIVE DISCUSSION: Does XREF-TBD refer to
the overview document? Would this create a publication dependency
on that document?
Probably. I'll just remove that reference; we can add it back in if
that document appears before base publishes.
Section 3.7 paragraph 3 "using the header canonicalization" ->
"using the body canonicalization". "XXX=" -> "bh="
Already got it.
Section 4 paragraph 3 "DKIM-Signature headers" -> "DKIM-Signature
header fields", "if they know that the headers cannot be verified"
-> "if they know that the signatures cannot be verified"
Damn. Tricked again.
Section 9.2 Date on dkim-threats-02 is April 2006. Citation on
RFC3766 is a little terse (!)
Thanks on the date. At some point I managed to get some tool (I
thought it was the xmlrfc plugin for XMLEditor, but apparently not)
to look up the references and include all of the detail. If anyone
recalls what that is, I would appreciate it.
Section A.3 "_dkim" -> "_domainkey" (as others have pointed out)
Got it, thanks.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html