ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Errata

2009-02-22 16:11:09
On 2/22/09 4:29 PM, Dave CROCKER wrote:
(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.

Right, which is something I believe the RFC-Editor intended to fix. Neither silly nor obvious are suitable. If there truly is confusion, that's a more appropriate point.


   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.

Allow me: thus far the interoperability issue is related to the relationship between i= and d=. Nobody has demonstrated anything more than that. You've decided that it is necessary for there to be a single primary output. That goes beyond addressing the confusion. QED.


   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.

That is what some of us call "a comparison".


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?


Dave, you're (repeatedly) missing the point, as you like to say to me. Operational experience can provide guidance as to how best i= should be used, and whether you are in fact correctly defining a single primary output. It's called "slow as you go", for new areas of work.

Eliot
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html