My vote:
(a) The erratum I-D [1] is ready to go. Process it.
I would have voted (b) because like Murray I believe that the errata
might be less verbose. Not having any specific recommendations I
therefore fall back to (a).
Mike
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, February 18, 2009 8:30 PM
To: Stephen Farrell
Cc: barryleiba(_at_)computer(_dot_)org; ietf-dkim
Subject: Re: [ietf-dkim] Consensus call on d=/i= clarification
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html