Hi!
On 1/7/26 16:54, Hannah Stern wrote:
On 12/25/25 02:29, Richard Clayton wrote:
I have put in the changes and clarifications I emailed about earlier.
I'll go through the draft with a few remarks:
- 5 Message-Instance/change recipes
- "r="... "c:"
* This addresses the overlapping/non-monotonic issue well.
* How would a verifier handle invalid specifications
(line number 0 or > number of lines)? Same as z?
Or completely invalid signature (permfail)?
* Would we want a shortcut for single-line copies?
Currently they're like "c:42-42"
- "r_header="
* This addresses the inconsistency with the tag-name spec
in the previous version.
* How are header field names with "-" handled though?
An obvious solution would be substituting an underscore.
Another possibility would be allowing "-" in tag-name.
* "c:" addresses the overlapping/non-monotonic issue well.
Same question for invalid header field numbers though.
Would we want a short-cut for single-header-field copies?
- "mi-rh-tag-data = mi-rh-recipes / %07A"
* s/0/x/
* Perhaps lowercase the "a" for stylistic consistency
with "mi-r-tag-data"?
I only now noticed more inconsistencies in the change recipe specs:
For body changes, the textual description says:
c: startnumber-endnumber
Copy the lines numbered startnumber up to and including the line
numbered endnumber. The first line of the body (immediately after
the blank line that indicates that there are no more header fields)
is numbered 1. If the endnumber is omitted then all lines
(from the startnumber line onwards) are to be copied.
The startnumber of every "c" instruction MUST be in ascending order
and MUST be greater than
the endnumber of all preceding "c" instructions. There MUST NOT
be any further "c" instructions after a "c" instruction with
an omitted endnumber. In other words a recipe is not allowed to
use "c" instructions to duplicate or re-order lines.
and the ABNF says:
mi-r-recipe = %x63 ":" 1*DIGIT "-" [ 1*DIGIT ] /
%x62 ":" [ base64string ]
In my eyes, this fits together.
However, for header change recipes, the textual description says:
c: startnumber-endnumber
Keep the instances of the header fields (with the relevant header
field name) which are at position startnumber to endnumber.
The startnumber of every "c" instruction MUST be in ascending order
and MUST be greater than
the endnumber of all preceding "c" instructions.
Unlike for body change recipes, this doesn't allow omitting the
endnumber.
The ABNF says:
mi-rh-recipe = %x63 ":" 1*DIGIT /
%x62 ":" base64string
This seems to not allow ranges at all and thus contradicts the
textual description.
In addition, the specification is dissimilar between body and header
recipes, allowing less code refactoring.
I'd suggest having the ABNF to be the same for both:
mi-recipe = %x62 ":" base64string /
%x63 ":" (1*DIGIT / 1*DIGIT "-" [1*DIGIT])
This way, "c" recipes would allow addressing a single line,
if there's no "-" at all in the recipe. It would also allow
the shortcut for "up until the last line".
I'd keep the semantic differences for "b:": for header fields,
the "Field-Name:" prefix is implicit.
I'd keep the semantic rule that the ranges named in "c:" recipes
must be strictly monotonous: Only the last entry may have the
form 1*DIGIT "-" without endnumber, and the 1*DIGIT form is just
a shortcut for number-number (with same start/endnumber).
I'd probably keep the "bottom-up" numbering semantics for header "c:"
recipes. Theoretically "top-down" could allow for leaving off an
endnumber more often (e.g. an MTA has added a "Foo" line at the top,
being the 42th instance of "Foo" - it could generate "c:2-" instead
of "c:1-41"). But as apparently people are already working on
implementations, this would be a gratuituous breaking change.
I could alternatively work with a different outcome too, as long
as the inconsistency between textual description and ABNF for header
recipes is fixed in _some_ way.
Kind regards,
Hannah.
--
Hannah Stern
Software Developer
Mail Transfer Development
1&1 Mail & Media Development & Technology GmbH | | |
Phone: +49 721 91374-4519
E-Mail: [email protected] | 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.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
