My vote: > (a) The erratum I-D [1] is ready to go. Process it.
If there is indeed a requirement to conform to the concept that a protocol must specify its payload, I believe this is the right way to go. At present, a new API implementor has no clear indication of what a minimal DKIM implementation has to provide to be compliant. To recite my prior example, the payload of a DNS reply is the answer which all APIs have to return, but there's auxilliary data (flags, counts, glue records) which an API might choose to expose as well, and some consumers might want. An implementor of a protocol can choose to expose via its API whatever it wants (our DKIM library offer the means to get at pretty much everything), but it has to do the prescribed minimum. Then it becomes a matter of choosing the API that satisfies the consumer's needs; a minimal one, or a more feature-rich one. Typical DNS implementations have a "just give me the answer" API, namely the gethostbyxxx() calls, or something more detailed, namely the res_xxx() interface. RFC3464 (DSNs) section 3 specifies what a minimal implementation of that specification needs to do to be compliant. I think what this document does is essentially analogous with respect to DKIM. I would also be satisfied with a change which stipulates that both i= and d=, or the UAID and SDID, are both mandatory outputs, but I don't want or need this strongly enough to advance it in a formal manner. This could be done in DKIM v2, or the "bis" draft whenever that comes, or an extension draft, or something. I don't believe all of the introduced terminology is strictly necessary, and note it makes the erratum document somewhat bloated and people reasonably find that uncomfortable. But I don't believe that makes the document incorrect or more technically difficult to apply. -MSK _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
