(Re-posted to working group, with the complete original and an expanded
response.)
Tim,
On 3/10/2010 11:32 AM, Polk, William T. wrote:
Authors,
While I am still reviewing documents for I have been thinking about an
alternative proposal to move dkim deployment forward. By making slight
revisions in the abstract and introduction indicating that this document is
not intended to be a stand alone specification, the errors of omission that
concern me become less important.
Your note appears to be in response to my guess about the core concern you
have.
After one month of of blocking the discussion, and no response to the
responses you were previously given, this the sort of change that you think is
essential to prevent the "harm" that you cited in your Discuss?
So, you think the word "considerations", in the Abstract, and "practical tips"
and "organized around the key concepts", in the Introduction, might lead one to
mistake the document as some sort of standalone, complete instructional missive?
Is there perhaps a chance that you are carrying your concern for protecting the
reader a bit too far, particularly for an Informational document and
particularly since the document has had extensive review and you appear to be
the first person confused about this? How does this justify a Discuss?
As for the proposed title change, it too does not match the established practice
that I've seen for other "deployment" RFCs, with no compelling benefit.
d/
ps. why did you copy the SMTP working group?
P.S. The draft RFC Editor Note also proposes a tweak to the title.
I’ll admit the proposed title is way too long, and I think that is
less important than the changes to the Abstract and Introduction, but
it would help make it clear that more detail exists elsewhere. I
figured I’d throw it out there just in case...
-----------draft RFC Editor Note----------
Title:
OLD
DomainKeys Identified Mail (DKIM) Development, Deployment and Operations
NEW
Supplemental Development, Deployment and Operations Considerations for
DomainKeys Identified Mail (DKIM)
In the Abstract:
OLD
This document provides
implementation, deployment, operational and migration considerations
for DKIM.
NEW
This document supplements the DKIM overview and protocol
specifications with additional implementation, deployment, operational
and migration considerations.
In the Introduction, insert the following as a new second sentence in the
first paragraph:
This specification supplements initial guidance previously included in
[RFC4871], [RFC5585], [RFC5617], and [RFC5672].
The revised paragraph would read as follows:
DomainKeys Identified Mail (DKIM) allows an organization to claim
responsibility for transmitting a message, in a way that can be
validated by a recipient. This specification supplements initial
guidance previously included in [RFC4871], [RFC5585], [RFC5617], and
[RFC5672]. This document provides practical tips for:
those who are developing DKIM software, mailing list managers,
filtering strategies based on the output from DKIM verification, and
DNS servers; those who are deploying DKIM software, keys, mailing
list software, and migrating from DomainKeys [RFC4870]; and those who
are responsible for the on-going operations of an email
infrastructure that has deployed DKIM.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html