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