If there is any whitespace in the illegal domain name, we could also add a message to the user suggesting to run the test on the domain name with all whitespace stripped. Something like:

The domain name example .com contains characters that cannot appear in domain names. Did you mean to test example.com?

The same could be done when the user input looks like an HTTP URL, because looking through zonemaster.net’s logs shows many attempts at testing domain names such as https://example.com. That could look like:

The domain name https://example.com contains illegal characters that cannot appear in domain names. Did you mean to test example.com?

In all other cases, we don’t suggest anything.

How about going that route instead? It can be implemented consistently in CLI and GUI, becomes an opportunity to educate the user about the difference between a domain name and a URL, and also avoids “trying to be smarter” than the user by attempting to automatically fix their mistakes.

(Edit: urgh, even stupid Github seems to try to outsmart me by stripping spaces after ` characters in the Markdown syntax. What a funny coincidence!)

If there is any whitespace in the illegal domain name, we could also add a message to the user suggesting to run the test on the domain name with all whitespace stripped. Something like:

The domain name example .com contains characters that cannot appear in domain names. Did you mean to test example.com?

Is that something to be implemented in GUI? Or do you suggest an update to this specification?

The same could be done when the user input looks like an HTTP URL, because looking through zonemaster.net’s logs shows many attempts at testing domain names such as https://example.com. That could look like:

The domain name https://example.com contains illegal characters that cannot appear in domain names. Did you mean to test example.com?

Is that something to be implemented in GUI? Or do you suggest an update to this specification?

In all other cases, we don’t suggest anything.

If the domain name is not delegated, Basic02 strips off one label and creates a message where the user is suggested to test the superdomain of the domain name.

How about going that route instead? It can be implemented consistently in CLI and GUI, becomes an opportunity to educate the user about the difference between a domain name and a URL, and also avoids “trying to be smarter” than the user by attempting to automatically fix their mistakes.

What is your suggestion? Starting to suggest things in messages?

After our discussion in the work group meeting I started thinking about this in a pure Zonemaster GUI context. I had a quick look and counted four types of text fields in our UI: domain name, IP address, keytag and digest. If we think the trimming of surrounding space is important enough that we need to specify how it is done, we should specify it for text fields of all types, not only domain names. We could specify it for each type individually like it is done here for domain names, but I don't feel this is the most reasonable approach. A better approach, IMHO, would be to have a separate specification of how surrounding space is trimmed and apply that to all text fields in Zonemaster GUI as a preprocessing step before any validation is done.

It is true that trimming of leading and trailing white space should be done in all fields in GUI.

In GUI, if IP address, key ID or digest has white space an error is issued. I think that is done in Backend, isn't it? I think trimming would be more helpful. (Algorithm and digest type are drop down lists.)

In GUI, if IP address, key ID or digest has white space an error is issued. I think that is done in Backend, isn't it? I think trimming would be more helpful. (Algorithm and digest type are drop down lists.)

If we specify trimming in the Backend API we'd have to add trimming rules for every data type in the Backend API that happens to use a text field for input in the GUI. If we switch the input widgets for a field in the GUI, we'd have to update the Backend API as well to adapt to the normalization characteristics of the new widget. IMHO it's better to separate concerns and deal with GUI stuff in GUI.

But for the purpose of zonemaster/zonemaster-engine#1316 this PR should be good enough, and it would be nice to be done with that one in time for the release.

If we specify trimming in the Backend API we'd have to add trimming rules for every data type in the Backend API that happens to use a text field for input in the GUI. If we switch the input widgets for a field in the GUI, we'd have to update the Backend API as well to adapt to the normalization characteristics of the new widget. IMHO it's better to separate concerns and deal with GUI stuff in GUI.

I am not sure what you mean, but we should both make sure that we do not get garbage into the system and that users do not get error messages on trivial deviations if field content, i.e. where it is obvious what the users want.

Domain names are special and complex, as the document shows, but we could other elements to it such as IP addresses.

Another example is digest for DS. Bind often shows it two parts, but the space should be ignored. If you enter the digest in that way Zonemaster will complain. Maybe Zonemaster could be helpful, but should probably be up to GUI to do.