Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[Dave Crocker <[e-mail]>]

On 2/8/2018 8:52 AM, John R. Levine wrote:
> On Thu, 8 Feb 2018, Mark Delany wrote:
>> Heh. I'm still waiting to hear a good reason as to why "v=" exists at 
>> all - apart
>> from exposing brittle parsers which mistakenly expect it to show up as 
>> the first
>> tag.
> 
> I had a draft that invented v=2, for headers with a tag syntax that is 
> not quite backward compatible with the current spec.  I realize that we 
> could change the header to DKIM-Improved-Signature but the change was 
> small and it smelled to me like the same header.


What you realized goes to the heart of the reason we don't need version 
numbers.

The issue falls into the category of how to specify a processing fork. 
At each protocol layer, there is a mechanism for specifying which 
processing engine is appropriate for the next layer up.  Ethertype, 
Protocol ID, Port, etc.

Version numbers serve that purpose /within/ a protocol layer.

They seek to distinguish important differences in processing for what is 
claimed to be the /same/ protocol.

Except really they don't.

If modifications to a protocol are upward compatible, the the new 
features, themselves, self-identify and version numbers aren't needed. 
If no new features are present, you have the old 'version' of the 
protocol.  If new features are present, you have the new 'version'.

If modifications are /not/ upward compatible, you really have a new 
protocol.  Make a new entry in whatever forking mechanism was used to 
get to the previous version.  As you note, a new header-field would be 
appropriate here.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html