Tim, On 3/10/2010 3:18 PM, Polk, William T. wrote: > Dave, > > First, I do think it is harmful when document content does not match the > (explicit or implied) scope.
And since I quoted text that made clear that the scope was constrained, what is the problem? Again the question: just how much bullet-proofing against careless reading is required? > I certainly had different expectations > based on the title and introductory material. In retrospect, I should > have brought my discuss up another level of abstraction but I apparently > got focused on the details (what was missing) instead of why it mattered. And yet even your original and later notes detail lacked detail, since there was no way of knowing exactly what problem you were trying to address /or/ what would satisfy and you did not provide clarification. > Personally, I would prefer to see this document expanded and either > address the various topics that are covered elsewhere or explicitly > reference the various bits of the DKIM overview and protocol specs where > the rest of this information resides. Since the document is loaded with citations, including the other DKIM documents, once again I have no idea what you mean. > Is there a chance that I am carrying my concern for the reader too far? Not only "too far". As two of my earlier responses suggested, implementing additional text in line in response to the concern you initially stated a likely downside, given the intended audience. It would have been helpful for you to address that point, over the last 5 weeks. > Perhaps... If you assume that the reader has already consumed the > protocol specs, then I am way off base. It certainly is not surprising > that the wg members weren’t confused. I just don’t make that assumption. Again, the text I quoted you earlier today is rather pointed in declaring the role of this document as being to augment, rather than replace, other documents. > My concern for the reader is based on my perspective at NIST. Deployment > guidance is actually something we do here, and sometimes we may even do > it well. The IETF has some history here, too. RFCs with the word "deployment" in them date back to 1992. Interestingly, the first was about X.500 and X.400. In any event, your statement here suggests that you are relying on the NIST culture for your concern, rather than the IETF culture. > However, they might use google to search on dkim and deployment > and try to use this document. People "might" choose to do an infinite number of unreasonable things. Taking a document out of context is only one of them. We cannot protect against every unreasonable action by a reader. And, again, the document states its nature and goals explicitly. > I don’t like holding this document up, especially when there are a > variety of simple solutions. To say "solution" is to take as a given that there is a problem. You have not responded to the responses that critique that assumption. > It > is clear this document will not evolve into “some sort of standalone, > complete instructional missive” so let’s be clear about the document > scope, and move on. The document /is/ already clear Tim, per the text that I quoted. It merely needs the reader to be paying attention. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
