(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