Hi James,
Thank you for the feedback. The main question that I have around draft-davies-idntables is whether it is meant for servers, for clients, or both. Would the Registrars have the need for the IDN Table code points as defined in draft-gould-idn-table or have the need for the more extensive Label Generation Rules (LGR) as defined in draft-davies-idntables from within EPP? I will provide separate feedback to draft-davies-idntables from a server perspective, but I would like to know what information the clients would like to have. Inclusion of the code points in draft-gould-idn-table was based on feedback from a Registrar to support caching, when the idea for draft-gould-idn-table was formed.
draft-davies-idntables has no specific target in mind with respect to servers or clients, it is just a descriptive format for describing label generation policies. It is silent on where you may choose to use the data. The primary driver is in any context where IDN tables may have been traditionally been used, but we were mindful to make it generic so it may be used in non-IDN contexts, and in fact non-domain contexts. It would be useful to know what the registrar expectation is for this data. Is the expectation that registrars can use this data to fully ascertain whether a label is within the registry’s rules, or a subset of them? Even if a client could pre-vet a given label against a table/LGR, it will still be for the registry to ultimately determine whether it is willing to allocate it given a table/LGR alone can not tell you if a given label is available for registration. The risk of using a format that only allows for describing simple code point eligibility as it appears to be undefined what happens if the registry enforces contextual rules? e.g. code point A is only permitted if it appears after code point B. If the EPP extension can only signal part of the policy then the client may be under a mistaken assumption that something is permitted when it is not, or vice versa, that a code point is not eligible but it actually is in the given context. kim