[ietf-dkim] DKIM BOF -- draft charter and agenda

[Hallam-Baker, Phillip]

I think it is inevitable that we will propose additions. In particular I
think it is inevitable that we will end up specifying a new
canonicalization algorithm. That's why I argued that the original spec
should only have two (because we should not have more than three).

I think the objection is met if we introduce the work 'backwards' in
front of 'incompatible' 

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org 
> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Stephen Farrell
> Sent: Thursday, October 13, 2005 10:19 AM
> To: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] DKIM BOF -- draft charter and agenda
> 
> 
> >>>>"The working group recognizes that a significant amount of 
> >>>>infrastructure and deployed software already compatible with the 
> >>>>input specifications currently exists.  The working group will 
> >>>>therefore make every reasonable effort to refrain from 
> introducing 
> >>>>incompatible change."
> >>>
> >>>I like it.
> > 
> > 
> >>This can open up a political can of worms.
> 
> I agree that the can is open, and that we ought impose some 
> compatabililty requirement in the charter.
> 
> However, I'd quibble with the above (which is btw, *much* 
> better than the "minimal" phease), in that I don't believe 
> there is a requirement for the dkim standard protocol to be 
> backwards compatible on-the-wire with what's deployed today, 
> but rather that the dkim standard be such that it's not a 
> problem to migrate from today's deployments or perhaps even 
> to run them in parallel.
> (Questions: Is parallel operation needed? If so, need that 
> apply to a single message?)
> 
> Concrete example: if the dkim wg decided to move the 
> DKIM-signature field as input to hashing from after the body 
> to being the first input (e.g. so we could perturb hashing 
> with some of our own randomness), then that'd be incompatible 
> on-the-wire, but no problem for migration.
> 
> Stephen.
> 
> _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
> 
>