I don't have much skin in the game, but I agree with Patrick on this. Especially with the notion that there are non-gTLD players in this space.
Also, is EPDP the law now? Is there not time to implement the right solution? -andy On Fri, Mar 1, 2019 at 10:54 AM Patrick Mevzek <p...@dotandco.com> wrote: > > 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
