[ietf-dkim] Last call comment: Changing the g= definition
hsantos at isdg.net
Thu Oct 14 06:20:26 PDT 2010
I'm all for simplification of the specs (and software logic) to one
protocol and not mix in old stuff. I know that DKEYS are still in the
minds of implementations that do both, but I don't think that will be
case as we move forward with new implementations and APIs (which will
most likely be DKEYS stupid anyway).
Tony Hansen wrote:
> Even though I supported the addition of wording on how to improve the
> compatibility with DomainKeys records, I would support removing the new
> proposed section 18.104.22.168 for the reasons Dave brings up. But I'd like to
> ask the question: Is it still worth changing that section into a WARNING
> for people upgrading from DomainKeys, saying to make darn sure that they
> REMOVE g=; in their old DNS records because of interoperability issues?
> So the question becomes: if we remove the section on how DKIM and DK can
> play nice together, 1) do we chop out all references to DomainKeys, or
> 2) do we keep a short warning on what needs to be changed in the DK
> record to make it work with DKIM?
> Tony Hansen
> On 10/14/2010 8:09 AM, Dave CROCKER wrote:
>> On 10/13/2010 1:52 PM, Jim Fenton wrote:
>>> I propose removing section 22.214.171.124 in its entirety.
>> Not only do I support this, but I think we can remove all references to
>> DomainKeys, except for the obvious historical reference to its role as input to
>> At the time DKIM was developed, worrying about compatibility with, and
>> transition from, DomainKeys was essential. Now it isn't.
> NOTE WELL: This list operates according to
Hector Santos, CTO
More information about the ietf-dkim