RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
draft-ietf-dkim-rfc4871-errata-07

This comment is perilously close to a Discuss!
I agree with Alexey that I would have prefered a revision of 4871.
I assume that the WG and advising ADs have discussed this and have a Good Reason (TM) for not revising an RFC.
To me, however, it is non-intuitive why we would create a second normative RFC when a single one could be constructed.

In particular, I am uncomfortable with an update to the Abstract of another RFC.

I wish you have done a revision of RFC 4871. But I trust this was discussed in the WG.


In Section 9:

   Corrected Text:

 [...]

         ABNF:

                       sig-d-tag   = %x64 [FWS] "=" [FWS] domain-name
   domain-name = sub-domain 1*("." sub-domain)
                 ; from RFC 2821 Domain, but excluding
                   address-literal

Indentation is wrong (not a big deal).

I also suggest you reference RFC 5321 in the comment above.


In Section 12:

      INFORMATIVE DISCUSSION: This document does not require the value
      of the SDID or AUID to match the identity in any message header
      fields.  This is considered to be an assessor policy issue.
      Constraints between the value of the SDID or AUID and other
      identities in other header fields seek to apply basic
      authentication into the semantics of trust associated with a role
      such as content author.

I've reread the last quoted sentence 4 times and still don't know what it means. Is any word missing? Or maybe this sentence can be split into multiple?

I support Adrian's DISCUSS and COMMENT.

Can the indentation of the various pieces of ABNF be fixed? I'd hate anyone to submit an errata against this RFC...

Personally, I would have been much happier to see this as a full
document obsoleting the original RFC. I realize people sometimes fear
such an action when other issues and redesign might be done as soon
as a document is "opened". But there is no reason for that, and I think
we have a responsibility to the readers of our RFCs to produce clear,
up-to-date specs, and not a patchwork of erratas.

I don't understand what the advantage of an "errata RFC" is over the normal collection RFC Editor erratas. (I mean, I expect Alfred within days to file an errata on this errata RFC...)

If a new RFC is desired, I'd much rather see a comprehensive update that would obsolete 4821.

Generally, +1 to the request for clarity about section 4-8 adding new sections to RFC 4871.

I'm also looking forward to discussion of relative merits of revising RFC 4871 and publishing this doc as a new RFC.

Really minor nit: is there any significance to the different indentation styles used throughout the doc?

In:

9.  RFC4871 Section 3.5 The DKIM-Signature Header Field

   [...]
   Corrected Text:

      d=

         Specifies the SDID claiming responsibility for an introduction
         of a message into the mail stream (plain-text; REQUIRED).  This
         is the domain that will be queried for the public key. 

...what is the "This" in "This is the domain..."?  The domain identified by the SDID?