Subject: Re: [ietf-dkim] errata revision: Identity Assessor vs. Message Filtering engine

From: SM <[email-masked]>
Date: Thu, 02 Apr 2009 22:52:50 -0700

At 17:02 25-03-2009, Dave CROCKER wrote:
>The following is offered to prime the discussion/decision process 
>for the one of
>the pending Errata items, developed in the SF working group meeting. 
>It reflects
>what I heard as the gist of the group preference. Obviously, I might have
>entirely misunderstood...

[snip]

>"Old" refers to the Errata I-D; "New" is the proffered replacement.
>
>CAVEAT:
>
>     This last-of-three postings affects the same section of text as 
> the Assessor
>revision posting, but attends to a different issue.  I've only just gotten
>clarification on what this third item was to be, so here's another 
>apology for a
>bit of confusion.
>
>     Had I remembered all 3 items I would have tried to merge this 
> with the other
>Assessor change, which is what the current note attempts:
>
>
>8.  RFC4871 Section 2.11 Identity Assessor
>
>
>     Old:
>        The name of the module that consumes DKIM's primary payload, the
>        responsible Signing Domain Identifier (SDID).  It can optionally
>        consume the Agent or User Identifier (AUID) value, if provided to
>        the module.
>
>     New:
>        The name of the module that consumes DKIM's mandatory payload, the
>        responsible Signing Domain Identifier (SDID). The module is dedicated
>        to the assessment of the delivered name.  Other DKIM (and non-DKIM)
>        values can also be delivered to this module as well as to a 
> more general
>        message evaluation filtering engine. However this additional activity
>        is outside the scope of the DKIM signature specification.

It may be better to have "Assessor" or "DKIM Assessor" unless you 
want to constraint the module to consume the SSID only or identities 
only.  I suggest:

8.  RFC4871 Section 2.11 DKIM Assessor

        The name of the module that consumes DKIM's mandatory 
payload.  Other DKIM
        values can also be delivered to this module as well as to a
        more general message evaluation filtering engine. However 
this additional
        activity is outside the scope of the DKIM signature specification.

If you want to deliver non-DKIM values, then it does not sound right 
to have DKIM in the name.  If the mandatory payload is redefined in 
future, there won't be any need to change the text.

Regards,
-sm 

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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 3 Apr 2009 12:58:08 -0400

> only.

The whole point of defining this term is to isolate the assessment of
the identity from other decisions.  I think it's best as it is, with
"Identity Assessor".

> to have DKIM in the name.

All the more reason to keep "DKIM" out of the assessor's name.  The
inclusion of "and non-DKIM" is important to make it clear that this
isn't restricting what implementations can use -- only specifying what
the DKIM spec officially provides.   This was an important point of
contention, and the text that Dave posted is carefully balanced.

I much prefer Dave's proposed text to SM's.

Barry