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