When two or more vendors are arguing in front of a customer whose implementation is at fault is where the customer points at the RFC and states THIS is correct. Any time I have been a customer/referee in an industry dogfight (WLNP wars) simple single documents carefully spelled out work. Multipart xrefed do not. Thanks,
Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arvel Hathcock Sent: Monday, March 27, 2006 9:58 AM To: [email protected] Subject: Re: [ietf-dkim] Splitting the DKIM base doc > I'm really having a hard time understanding why we're so intent on > snatching defeat from the jaws of victory. Mike's comment above got me thinking on this. Aren't we very close as a WG to resolving all known issues with -base now without this split? If so, why introduce such a change if there's no large faction amongst us calling for it? As an implementor, I agree with Mike that when and where possible, the fewer documents, the better. I'm also a little worried that the DKIM specification might become a library of cross-referencing documents all of which depend upon the others which begs the question of why they aren't/weren't in the same specification to begin with. My own view is that if DNS is a mandatory mechanism, if 'simple' and 'relaxed' are manditory mechanisms, they ought to be included in the -base spec so that an implementor has everything necessary in a single source. Other mechanisms currently optional or to be determined in the future should be specified elsewhere. Naturally, I will go with the flow on this topic but I just wanted to get my own view out in the open. -- Arvel _______________________________________________ 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
