[Ietf-dkim] Re: I-D Action: draft-ietf-dkim-dkim2-spec-01.txt

[Hannah Stern <[e-mail]>]

Hi!

On 4/23/26 15:08, Steve Atkins wrote:

>> On 20 Apr 2026, at 13:06, Richard Clayton <[e-mail]> wrote:

>>[...]

>> As presaged a while back -- and no-one objected, I have removed the
>> definition of tag value list and incorporated the relevant text into the
>> descriptions of Message-Instance and DKIM2-Signature. This is the only
>> change that implementors MUST address -- the trailing ";" on these two
>> header fields is now required.

> This is a change from previous usage of tag value lists, and might
> reduce some code reuse for header generation as existing libraries don’t
> necessarily add the trailing semicolon.

> But as someone who mostly writes code that validates these fields I do
> find the mandatory trailing semicolon a useful check to protect against
> truncation.

I'm not sure I agree with that consideration.

Truncation will be caught in verification because it invalidates
signatures.

So for me the trailing semicolon change is mostly inconsequential
and I'm mostly agnostic about it.

Might simplify one or two code paths in generation/parsing though.

> Also I’ve been generating code from the json schema included in the
> draft and have a couple of comments.

> A trivial one is that in json schema the description field must be a
> string. The array of strings in the description of the “h” field causes
> parsing of the schema to fail.

> The other is that the narrative text describes the body recipes as
> either null or an array of recipe steps (“c”, “d” or “z”) while the json
> schema describes it as either null, or a {“z”: true} object or an array
> of recipe steps (“c” or “d”).

I'd want to do away with "z".  There has been discussion in some other
thread that that's actually not useful.

In a DSN the original message is included either as is or headers only.

The verifier inspecting a DSN can easily "know" if the body is left
off without such a hint.  (Check original body empty and the hash
in the original newest Message-Instance doesn't match - the latter
only if you need a distinction between "original message actually
had an empty body" and "original message had a non-empty body
that's not included in the DSN".)

> I think the json schema might be simpler to understand if we treated
> header steps and body steps separately, rather than reusing recipe-steps
> for both.

That argument goes in the opposite direction to the argument for
tag-lists.

Once you omit "z", you have uniform types (only with null alternatives
in 2 places, namely directly under "h", as alternative to the
field-name -> recipe-steps object, or directly under "h" as
alternative to recipe-steps (an array) directly).

> Cheers,
>    Steve

Hannah.
-- 
Hannah Stern

Software Developer
Mail Transfer Development

1&1 Mail & Media Development & Technology GmbH |  |   |
Phone: [phone]
E-Mail: [e-mail] | Web: www.mail-and-media.com www.gmx.net 
www.web.de www.mail.com www.united-internet-media.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452

Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, 
Dr. Verena Patzelt


Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte 
Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat 
sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte 
den Absender und vernichten Sie diese E-Mail. Anderen als dem 
bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, 
weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden.

This e-mail may contain confidential and/or privileged information. If 
you are not the intended recipient of this e-mail, you are hereby 
notified that saving, distribution or use of the content of this e-mail 
in any way is prohibited. If you have received this e-mail in error, 
please notify the sender and delete the e-mail.