I admit that I also got confused a few times while working on the DKIM
documents and keeping it straight as to which section was referring to
which set of arguments. Having them use different values and different
tags for items that were conceptually the same was an unfortunate aspect
aspect of the history behind DKIM.
Indded. And the inverse. That the same tag had different syntax or
semantics depending on location.
Originally there was a unified tag-space to avoid these risks. That
was easy back then as there was only 11 tags that covered policy, keys
and signature thus little risk of tag-space depletion even with single
character tags.
Perhaps ironically, around the time tag-space was dimensionally
expanded with versioning and multi-character tags, the principles
underlying the unified tag-space disappeared.
Anyway, as others have suggested, one solution is to put a tag-space
hierarchy into the spec or...
Alternatively, if you're a believer in versioning you could simply
bump the versions and re-assign tags. This way you get to feed two
birds with one cracker. Prove that versioning is useful and consign
this tag-space fuzziness to history!
Just kidding. Seems like Barry's later diagnosis is accurate thus if
any clarification is needed at all it can be bundled with other
errata.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html