Re: The cost of choices

Makes perfect sense to me.  In my opinion, Hector is right - this is the way 
to go and this is what the existing DKIM draft already allows.

--
Arvel


----- Original Message ----- 
From: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
To: "Dave Crocker" <dcrocker(_at_)bbiw(_dot_)net>; 
<domainkeys-feedbackbase02(_at_)yahoo(_dot_)com>; "IETF MASS WG" <ietf-mailsig(_at_)imc(_dot_)org>
Sent: Wednesday, July 27, 2005 12:10 AM
Subject: Re: The cost of choices


> ----- Original Message -----
> From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
> To: <domainkeys-feedbackbase02(_at_)yahoo(_dot_)com>; "IETF MASS WG"
> <ietf-mailsig(_at_)imc(_dot_)org>
> Sent: Wednesday, July 27, 2005 12:06 AM
> Subject: The cost of choices
>
>
> > Whether operators choose to use all the features is a separate matter, 
> > but
> as
> > Mark notes, there is a problem if the initiating side uses it but the
> > receiving side does not.
>
> I brought this up in my response to your poll.  Did you read it?
>
> http://www.imc.org/ietf-mailsig/mail-archive/msg01718.html
>
> The suggestion is that q=DNS query be the standard fallback and that a
> extended SIGNER using some other "q=" query method must also publish the
> DKIM policy in DNS as well to support the fallback on non-compliant 
> extended
> query DKIM receivers.
>
> This allows us to concentrate on using DNS.
>
> But we should model the specification based on a standard Input/Output
> Model:
>
> Standard:
>
>        DKIM_POLICY = DKIM_DNS(selector, domain)
>
> Extended DKIM query protocols:
>
>        DKIM_POLICY = DKIM_XKMS(selector, domain)
>        DKIM_POLICY = DKIM_SOAP(selector, domain)
>        DKIM_POLICY = DKIM_other(selector, domain)
>
> These extender protocols would be out of scope for the core DKIM
> specification, but I think the core should include a simple modeling thus
> allowing future query methods to be invented.
>
> So I think, the only thing that needs to be clearly defined is what are 
> the
> minimum CORE expected input and output variables.   I think this is 
> already
> established. So it just a matter of modeling it in the specs.
>
> A separate DKIM-QUERY ID draft can be written that follows the DKIM-core
> draft.
>
> Make sense?  If not, please let me know what I am not seeing here that 
> makes
> this more difficult than it is?