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