Il 04/03/2019 21:51, Andrew Newton ha scritto:
I don't have much skin in the game, but I agree with Patrick on this.
+1
ccTLDs are not directly affected by EPDP recommendations at present but
it could be in the future since ccTLDs might meet the requirements
coming from those registrars which are also gTLDs registrars.
In my opinion, if there was enough time according to the deadline to
implement EPDP recommendations, a better solution than using placeholder
values should be found.
As suggested by Patrick, the definition of a "light contact" object
might be enough to bypass contact-1.0 schema constraints.
In my view, the new schema could define the operations (i.e. create and
info) together with a type to be used as a response extension (e.g. in a
domain info) in order to list the light contacts' ids.
In this way, both domain-1.0 and contact-1.0 schemas could remain unchanged.
If there was absolutely no time, even if RegExt WG fast-tracked the
light contact (or whatever else) standardization process, I agree with
Roger about using placeholder values as a temporary solution.
Regards,
mario
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
--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
