RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
RFC 5672
Yes
No Objection
No Record
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert No Objection
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.
(Pasi Eronen; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
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.
(Alexey Melnikov; former steering group member) No Objection
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?
(Dan Romascanu; former steering group member) No Objection
I support Adrian's DISCUSS and COMMENT.
(Jari Arkko; former steering group member) No Objection
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.
(Lisa Dusseault; former steering group member) No Objection
(Ralph Droms; former steering group member) (was No Record, No Objection) No Objection
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?
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) (was No Record, Discuss) No Objection
(Cullen Jennings; former steering group member) (was Discuss, No Objection, Abstain) No Record
I asked three implementors to have a look at this and let me know what changes might be needed to an 4871 implementation to make the code complaint with this errata. They all told me this document was completely incomprehensible and they have no idea what needs to change. I suspect this draft says more than "you MUST have a (d=) and you MAY have (i=)", but I have missed it.