(Subject changed, to take this out of the tally thread.)
SM, You cite some issues that I would be interested is seeing you expand a bit: SM wrote: > An errata is generally noncontroversial. First, you say "generally" which means that an errata is not disqualified by being controversial. Further, I've never heard of any requirement for being non-requirement. My own experience with errata is pretty small, but I've seen them range from silly to obvious. Instead of being a > clarification of the d= and i= tags in the current specification, > this one turned into a determination of how DKIM will be used in > future. I don't understand this statement, if it means more than your stated concern about ADSP. FIrst, any specification is determining how things will be done in the future. Any correction (errata) to a specification is modifying the specification and, therefore, also determining how things will be done in the future. You imply there is something bad about this, whereas it's inherent. Please clarify. One of the proposal affects the work currently being done on > ADSP. I'll quote Section 2.7 of draft-ietf-dkim-ssp-09: > > "Note: ADSP is incompatible with valid DKIM usage in which a signer > uses "i=" with values that are not the same as addresses in mail > headers. In that case, a possible workaround could be to add a > second DKIM signature a "d=" value that matches the Author > Address, but no "i="." > > With the change, we may need to sign the message more than once in > some circumstances if we are using the i= tag. That's an extra > overhead both for signers and verifiers. I am reasonably certain the draft Errata makes no such requirement. At the least, Please explain. Your quotation, above, does not contain any text that makes this obvious to me. It is further confusing that you cite some ADSP text as the basis for your concern about the Errata draft, but then go on to cite some of Jim's text as the basis for saying his is the better choice. > Quoting part of Jim's proposal: > > "In many cases, the i= tag will not be present in the DKIM-Signature > header field at all; it is not required unless the signing key > restricts the signing identity or identities via its g= value." > > That is better suited for a document about deployment. > > J.D. suggested leaving i= opaque and see what operators (on both ends > of the transaction) do with it. That could be discussed in a > document about deployment. Leaving i= as opaque is the job of a specification, not a usage document. How does Jim's draft help leave i= as opaque? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
