[ietf-dkim] Last call comment: Changing the g= definition

[Hector Santos]

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).

-- 
HLS

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 3.6.1.1 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 3.6.1.1 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
>> DKIM.
>>
>> At the time DKIM was developed, worrying about compatibility with, and
>> transition from, DomainKeys was essential.  Now it isn't.
>>
>> d/
>>    
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 



-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com