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

[Tony Hansen]

Barry, there are crossing questions.

This question came up in response to removing 3.6.1.1 totally separate 
from the question of removing g= altogether.

If we remove 3.6.1.1 without removing g= altogether, the question below 
becomes pertinent.

If we remove g= altogether, then we can remove 3.6.1.1 *along* with all 
the other references to g= within the document.

     Tony Hansen

On 10/14/2010 2:54 PM, Barry Leiba wrote:
> On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansen<tony at att.com>  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?
>>      
> I don't see the problem.  If we just remove 3.6.1.1, then, yes, we
> have an issue with migration.
>
> If we remove g= altogether, then we remove the problem: ALL key
> records will be treated as though they had "g=*", which means that the
> problematic situation is treated just as it was in DK, and the key
> records are compatible.
>
> Or am I missing something?
>
> The only thing we're eliminating by removing g= is the ability to
> restrict a key record for use only by specific i= identifiers.  And
> Murray's stats show that there are fewer than ten instances of that in
> some 300,000 samples -- well below any reasonable threshold of caring.
>
> Barry, as participant
>