Thank you Rob for taking the time to respond. Further comments in line.
Clarification 1. The fields which are explicitly listed are allowed to be blank if they have no data. But what of those fields not listed? Are those fields not allowed to be blank? It should be noted that the EPP RFCs have "voice" as an optional element, yet it is excluded from Clarification 1 as one of the fields allowed to be blank. It concerns me that a clarification document is trying to introduce new behaviour. If OPTIONAL elements are to become required, a public discussion should be had.
All fields are mandatory unless option, excluding those that can be blank, or errors in the specification ;) Or in English * optional fields - dont output the label & data if the data is not provided * fields explicity mentioned as allowed to be blank - output the label but no data if the data is not provided * everything else - output the label and the data KF - You and I have subtly different interpretations of Clarification 1. It says _all_ fields in 1.5 of the RA ("phone number" being one of them) MUST be shown in the output. So we don't have an option to not show the key. Only an option to show no data if no data exists. This then runs afoul of the explicit listing of those keys for which having no data is acceptable (phone number this time not present). So your first point is one that my reading of the clarification suggests is not a valid option, much as I'd like it to be.
Clarification 7. If IP addresses are provided for name servers Clarification 8. Hosts may be added without IP addresses.
For self-referencing domains (glue) output the label, IP and FQDNs otherwise just label and FQDN KF - It is perfectly legal to have no IP address for a host and to assign a domain to such a host. While DNS may not work in this instance, at least for the name server concerned, it is nevertheless legal behaviour. Again we have a "MUST" for outputting optional data. I think such a case was not considered when writing the clarification. I would argue however that a clarifications communication should take all such corner cases into account, lest they contradict system behaviour.
I echo Alexander's request that a complete specification, with no contradictions and no guesses, is required.
Yes, and that doenst contradict the *contract* KF - completely agree. Rob