-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]>, Dave
Crocker <[email protected]> writes
>>> Having nearly identical definitions of tag-value lists in
>>> different documents produces ambiguity and is not modular.
>>>
>>
>> We'll just have to disagree about that purported ambiguity.
>
> oh? you think that having multiple places that define something
> does not invite diverging -- and therefore conflicting --
> interpretations?
People processing DKIM1 tag-value lists should read the DKIM1
specification, people processing DKIM2 tag-value lists should read the
DKIM2 specification ... I don't see any confliction there.
If people wish to use the same code for both then they will need to
concentrate for a few moments to see if this is wise ... but if
developers build a separate DKIM2 library (rather than using a "mode
bit" [1]) then the fact we have removed encoding options will allow for
a simpler codebase, so that may well be what people do.
... this also applies to the way in which the body is canonicalised and
hashed since that is intended to be the same but the WG may change their
mind about that in due course.
Note that we use the DKIM1 keys "as is" and expect that decision will
not change -- so we felt it was advantageous to move the material about
those keys into a separate draft; since that also allows us to deprecate
some features that have turned out to be unused/useless.
[1] Kidder, Soul of a New Machine -- reporting on the design instruction
of "no ... mode bit" (I've toned that down for the list)
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBaM/ilmHfC/FfW545EQI4LQCgqUUQo5yMAjEdLYQL7w4EvXZ0PGoAn10d
5uHBy6TpPvLLjex1SToFOaAz
=slXg
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
