Re: Publishing of the IDN Table EPP Mapping IETF Draft
Kim Davies <[email protected]> Fri, 13 Mar 2015 22:26:35 +0000
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
Hi James, > Thank you for the feedback. The main question that I have around draft-d= avies-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 Gen= eration Rules (LGR) as defined in draft-davies-idntables from within EPP? = I will provide separate feedback to draft-davies-idntables from a server pe= rspective, 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-go= uld-idn-table was formed. = draft-davies-idntables has no specific target in mind with respect to serve= rs or clients, it is just a descriptive format for describing label generat= ion policies. It is silent on where you may choose to use the data. The pri= mary 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 wh= ether a label is within the registry=92s rules, or a subset of them? Even i= f a client could pre-vet a given label against a table/LGR, it will still b= e for the registry to ultimately determine whether it is willing to allocat= e 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 poin= t eligibility as it appears to be undefined what happens if the registry en= forces 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 permi= tted when it is not, or vice versa, that a code point is not eligible but i= t actually is in the given context. kim _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg