ietf-dkim
[Top] [All Lists]

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

2007-11-02 16:43:59
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

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

<Prev in Thread] Current Thread [Next in Thread>