My sentiments exactly. (a) On Sun, Feb 22, 2009 at 5:21 PM, MH Michael Hammer (5304) <[email protected]>wrote:
> 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: [email protected] [mailto:ietf-dkim- > > [email protected]] On Behalf Of Murray S. Kucherawy > > Sent: Wednesday, February 18, 2009 8:30 PM > > To: Stephen Farrell > > Cc: [email protected]; 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 > -- Brad
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
