Subject: RE: [ietf-dkim] Splitting the DKIM base doc

From: <[email-masked]>
Date: Mon, 27 Mar 2006 10:38:23 -0500

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-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Arvel Hathcock
Sent: Monday, March 27, 2006 9:58 AM
To: [email-masked]
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