[ietf-dkim] Nits with section 2 Language and Terminology

[Jim Fenton]

More good comments.  See comments inline:

Arvel Hathcock wrote:
> Some additional suggestions:
>
> 2.  Language and Terminology
>
>       One thing that was a clear take-away form the recent Interop
> event was that we must have a clear definition of "signing identity". 
> Please consider adding this definition somewhere:
>
>    2.x  Signing Identity - The "Signing Identity" is the value listed
> in the i= tag of a DKIM-Signature header field.  If the i= tag is not
> present then the "Signing Identity" becomes the @ sign followed by the
> domain value taken from the d= tag of the same DKIM-Signature header
> field.

I think this adds a lot of clarity.  I would probably put it before the
current 2.3 to avoid forward references.
>
>    2.5  Alleged Signer - An "Alleged Signer" is the Signing Identity
> claimed within an as-yet unverified DKIM-Signature header.

OK.
>
>    2.7  I wouldn't call this section "Sender Signing Practices" as
> this is the name of the overall document itself.  Can this be called
> "Sender Signing Practices Record"?

Makes sense to me.
>
>          "...which includes information about whether or not that
> domain...." -> "...which includes information on whether and how that
> domain signs their email."  I think it's not necessary to try and
> illiterate here all the possibilities (or some of the possibilities)
> that can be done with the current draft of SSP.

The "and how that domain signs" might be a little confusing.  How a
subject signs their email might be interpreted as something like "the
domain always signs the Subject header field" and I think we decided not
to do that.  How about instead "which includes information on whether
that domain signs their email and related information."  Less specific,
but less confusing IMO.

>
>  2.8  Assuming you agree to add my definition of "Signing Identity"
> then this could be rewritten like this:
>
>      "An "Originator Signature" is any Valid Signature where the
> Signing Identity matches the Originator Address. If the Signing
> Identity does not include a local-part, then only the domains must
> match; otherwise, the Originator Address and the Signing Identity must
> be identical.

OK.
>
>  2.9   Possible rephrasing:
>    "Messages that do not contain a valid Originator Signature and
> which are inconsistent with a Sender Signing Practices check (for
> example, messages without a Valid Signature when a Sender Signing
> Practices Record advertises an expectation to the contrary) are
> referred to as "Suspicious".

I agree, the definition that's currently there goes well beyond being a
definition.  We should move the rest of the information somewhere else
(probably section 3).
>
>  2.11  "For the message" -> "for the message"

I couldn't find this one.
>
> More to come.

And more to come on the responses, too.  Thanks, Arvel.

-Jim