Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement FromStr for zonemd Scheme and Algorithm #444

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

mozzieongit
Copy link
Member

While writing the dnst signzone zonemd argument parsing, I noticed that zonemd::Scheme and zonemd::Algorithm implement neither FromStr nor a from_mnemonic function (as with the enums created with the iana int_enum macro).
I was unsure which one should be used, but settled on FromStr with both number and mnemonic, as it allows an easy use of str::parse.

…e consistent with how other IANA parameters are codified in domain, and in so doing gain string and mnemonic conversion functions.

This is a breaking change because it renames types, moves types within the module tree, and removes support for named variants for reserved and private use ranges for ZONEMD parameters (as we don't do that for other IANA parameters in domain).
@ximon18 ximon18 added the breaking A PR that includes a breaking change. label Nov 29, 2024
@ximon18
Copy link
Member

ximon18 commented Nov 29, 2024

After discussing internally I have reworked this to implement the ZONEMD IANA parameters using the IANA macros as we do for other IANA types and I have labelled this as a breaking change.

By using the macros we get a FromStr impl and to/from_mnemonic() functions, and consistency with the rest of domain.

This does however mean that types are renamed, moved in the module tree, and the "reserved", "unassigned" and "private" enum variants are gone (as we don't do that for other IANA parameters) and the ZonefileFmt impl no longer produces comments for the scheme (as it's a bit of a pain to code cleanly to match the way it was before with "unassigned", "private" and "reserved" ranges and without them there's only a single scheme so the comment has little value, nor does LDNS produce a comment for this type) and algorithm (as we don't output comments for the algorithm on other types).

@mozzieongit
Copy link
Member Author

Noting it down, to not forget it: This (and other types in future PRs) should potentially change to use int_enum_str_with_decimal! instead of int_enum_str_decimal; the difference being that ..._with_decimal offers from_str with a mnemonic AND a number (as a string), while _str_decimal only allows using a number.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking A PR that includes a breaking change. needs-review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants