[ietf-dkim] Re: dkim-base-01 nits and semi-nits

[Eric Allman]

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