Good Morning, Thanks for the comments Patrick. Agreed, another one of the concerns going with placeholders is that to some, it will lessen the urgency to solve the underlying issue. Not speaking specifically to the examples you gave on multiple mechanisms, I still believe that adding an additional contact mapping will increase implementation complexity that is not needed, more below. As far as tailoring the protocol, it seems to me that the current RFC 5733 has been tailored. I am not sure why 5733 required these fields to exist in the first place, I assume it was discussed when it was written many years ago and it was decided for some reason these fields be treated special, but I don't see a technical reason to treat them differently. I don't think the idea of making the EPP Contact Mapping more flexible is a gTLD specific solution. Thanks for digging deeper into what it takes to "improve" the current mechanism. As Gavin mentioned in his original email, this would require a new RFC be created and you have provided some more logistics to that effort. As you mention, there may be clients that may need to support both namespaces, but for servers that choose to use the new namespace the interface on both sides would be less complex than having two mapping mechanisms. Servers could have the option of supporting the namespace that is appropriate for them (though I assume for gTLDs ICANN would update policy to use the new namespace). Thanks Roger -----Original Message----- From: regext <regext-bounces@ietf.org> On Behalf Of Patrick Mevzek Sent: Friday, March 1, 2019 9:55 AM To: regext@ietf.org Subject: Re: [regext] [gtld-tech] EPDP recommendations and EPP 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 pm@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext