Eric Allman wrote:
Jim, thanks for the comments.
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.
Part of the problem is that I read "incrementally" and "independently"
as the same word. This is fine.
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?
How about something like this:
DKIM is designed to support the extreme scalability requirements which
characterize the email identification problem. There are currently over
70 million domains and a much larger number of individual addresses.
DKIM seeks to preserve the positive aspects of the current email
infrastructure, such as the ability for anyone to communicate with
anyone else without introduction.
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.
I'm not sure of the solution to this either. It just seemed like it was
a little early to discuss that sort of key/selector management detail
right after having introduced the concept of selectors themselves.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html