Naming of domain message args

[mattias-p]

This is another step towards solving #60 and #713. The main focus is renaming domain name arguments to "domain".

An accidental omission from #853 is also included,
in a couple of places missing arguments were added,
a few unused messages are cleaned up, and
some refactoring is included in order to ease the renaming of the domain arguments.

[matsduf]

A domain name on what? There is already "nsname" with the same data type. The description should be more specific so that it excludes name server names, or else there should only be one.

One approach is to let instances of domain name be represented by the same argument, e.g. "domain". In the case of non-negative integer you have taken the path to have different arguments for different use of non-negative number. If the same path is followed for domain name I find the split name server name, on one side, and all other use of domain name, on the other, not to be optimal for Zonemaster.

There are some domain names that are special for Zonemaster in the sense that they point out central concepts and are frequent.

• Name server name
• Zone name of parent
• Zone name of child

Other use that we have include

• Reverse name of name server IP address
• Mail domain
• Non-existing zone name

If there are more than one argument for data type domain name, then at least the first three (name server name, zone name of parent and zone name of child) should be their own arguments. The last three could be grouped into one argument, but could as well be their own arguments.

[mattias-p]

It's a relevant and difficult topic you bring up. But I'll try to spell out how I'm think about it. Maybe we ought to take it offline, but I want to gather my thoughts in text anyway so I'll just post it here. Bare in mind that since I started working with this my perspective has been evolving.

First of all I doubt we'll be able to find a perfect design for the argument naming. I have a feeling that no matter how we turn in this question, we'll have our butts behind us.

I see a few main reasons to have give variables different names.

1. Differences in format E.g. things that have clearly distinct presentation formats.
2. Differences in grammar. E.g. whether it should be "more than 5" or "longer than 5" depends on what the unit is.
3. Disambiguation. When you need more than one variable of the same kind in the same message.

In the first case the format of an argument value might affect the best way to punctuate a message, so it's seems helpful to provide translators with a hint to that end.

I apply the same general idea to the second case. If the unit of an argument value might affect the language around it, it's seems helpful to provide a hint for that.

The third case is different in my mind. It seems impossible to come up with a partitioning of different kinds of variables that's both reasonable and granular enough to ensure that no message will need to use two variables of the same kind. We need some kind of general disambiguation solution. My first choice for solving this problem is using common prefixes that indicates the kind of variable together with locally unique disambiguation suffixes.
A way to mitigate the ambiguity problem and reduce (though not eliminate) the need for disambiguation suffixes is to single out a few very common sub-kinds and promote them to a proper kind of their own. The obvious example here is nsname which I estimate to be about a third of all domain name arguments.

Returning to your question "A domain name on what?". In my mind the msgid ought to be good enough to answer what kind of domain name. From my current understanding of the issue, I don't see any reason to disambiguate different kinds of domain names any further than "domain" and "nsname". If it can be shown that having distinct kinds for "nsname" doesn't help much with disambiguation, I think we should at least consider integrating it into the generic domain kind. The same goes for the special kinds of integers.