I have quite a few comments on the proposed erratum submitted by Dave Crocker. Detailed comments first, general comments below.
Detailed Comments: 1. Is this a working group draft? The title would seem to imply that it is but I don't remember that happening. 2. Section 1, paragraph 2: "a consumer of the validated signing domain" is confusing: "consumer" in particular. DKIM doesn't say anything about how the results would be used, so all DKIM really has is a signer and a verifier (which is the term used throughout the spec, not validator). "...a user of successful verification results" also sounds too much like it's a human and not some other module that acts on the result. 3. same paragraph: '"responsible" domain name' implies that the result is the domain name (which I probably don't agree with, see below) and the last line talks about "details about the name". Details about the domain name? I'm not sure what details of a domain name are, unless you're hinting at the use of a subdomain with a particular name. 4. Section 2: Section 2.7 should come later to avoid forward references. Identity Assessor is a poor name for this module because it's not assessing an identity (depending on your definition of identity, the Verifier might be doing that) but rather something based on the signing identity. I'm not sure what it means by "optionally consume the UAID". Does that mean that it can ignore it if it is provided? I suppose, but DKIM-base specifies a protocol, not the API that the verifier uses to communicate with something downstream. 5. Section 3: "identity claiming responsibility" -> "domain claiming responsibility" since that's what the base spec says it does (4871 section 1). I don't see how this is opaque unless you say that domain names are opaque (which I'm not going to argue) but I find the word "opaque" in this definition confusing. 6. Section 4: User Agent Identifier is a terrible name for this. The UAID is the value of the i= tag, it says later. i= is defined as the "Identity of the user or agent (e.g., a mailing list manager)..." but nobody said anything about a user agent. We already have the term "signing identity" used in the specification, and it's quite clear what it means. [Aside: Having hung out with some people in the identity community since the publication of RFC 4871, the one terminology change I would make is to change "signing identity" to "signing identifier" because the i= value isn't an identity, it's a pointer to an identity...an identifier.] 7. Section 5 talks a lot about how the sender can put all sorts of things into the i= value. When we wrote the spec, there was a clear sense that most signers wouldn't even assert a local-part in the i= value, and unless they were doing parent domain signing (section 3.8), probably didn't need to use i= at all. That's simple and elegant. Instead, this section is emphasizing how signers can put all sorts of things in the i= value if they want to. What's the motivation for overloading the i= value with this stuff? If they want to say something only significant to themselves (perhaps for abuse tracking), it's easy to define another tag for that value. If they want to give a hint to a reputation service that might want to do something below the domain level (this is of dubious benefit; we don't know enough about reputation yet) they can define a tag for that in an extension to the DKIM spec. We didn't do that in DKIM-base because we didn't know enough about what was needed (and I'm not sure we do yet). 8. Section 5: First paragraph seems to read that, even if the i= tag is in the signature that verifies correctly, it's OK for the verifier not to communicate that to an assessor. Since some assessors may depend on this value, for interoperability reasons the value MUST be communicated if present. 9. Section 6: The old definition of d= seems much clearer. 10. Section 7: The replacement with UAID loses a useful example and implies it's always a User Agent. Sections 8-11 just seem to be sprinkling the UAID and SDID acronyms elsewhere into the text. Section 13: Good grief, are the authors corporations now? What happened to IETF being as organization of individuals? Appendix A: Was the reference to d= intended to be humorous? Perhaps you should have used SDID rather than d=. ===== General comments: Despite its intent to clarify RFC 4871, I find the new terminology at best adds little (SDID) and sometimes adds new confusion to the document (UAID). It emphasizes uses of the protocol, particularly "creative" ways to use the Signing Identity, that if they need to be described at all, probably belong in the Operations document. It also attempts to partially specify the API between the Verifier and a downstream Assessor, which is not the subject of the DKIM specification. -1. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
