On Fri, Mar 1, 2019, at 16:22, Roger D Carney wrote: > Thanks for the comments Patrick. I agree about the pollution of > placeholders and that is one reason why I think it can only be used as > a temporary solution.
If this is implemented, it will become permanent and there will be nothing else replacing it later. > I am not sold on creating a "new object." Another way to do the same > intention, to me this will just get convoluted for implementers (look > here unless you should look over there). I do not feel that convoluted and even if it is the case we already have many of them: - host attributes vs host objects - secDNS keyData vs dsData etc. > To me this is just creating a > new mechanism to avoid fixing a problem in the current mechanism. There is no problem in current mechanism. ccTLDs are all "fine" with it. Right now we are discussing (in multiple places so that makes participating difficult) things that will only apply to gTLDs. I really do not want again to give everyone's impression that we are tailoring a protocol to a very specific case just because the major vocal interests are there. In short, if gTLDs need another contact model because the one in RFC5733 is not fitting today anymore, it seems the clearer and simpler to me to just define a new model for contacts. > I am not sure how improving RFC 5733 to be more flexible and data > privacy/protection aware is a detriment to anyone using EPP. Anyone > using 5733 needs to be acutely aware of data "processing" and would > greatly benefit from a more flexible technical solution. You can not "improve" RFC 5733. You will need to create a new namespace, like "contact-2.0" At which point it is quite the same for implementors because any client with multi registries need will need to handle both namespaces (you can not expect all registries, specially non gTLD ones, just moving to your new schema, even if it is a strict superset of previous ones, because they will have absolutely 0 reasons, technical or economical, to do the change), so if you have "contact-1.0" and "contact-2.0" namespaces to handle OR "contact-1.0" and "lightContact-1.0" (or "shallowContact-1.0" or "gtldContact-1.0" or whatever) it is basically the same amount of work, but second option seems better to me for multiple reasons. And again, there is a huge non technical difference. If we give again the impression to change the EPP just to suite gTLD needs, we should not lament later on the state of EPP worldwide and why not everyone follows the standard to the letter, or best current practices, etc. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
