On Tue, Mar 5, 2019, at 07:42, Gavin Brown wrote:
> > Instead of updating RFC5733 I would suggest creating a new object,
> > a "light (or shallow) contact" which is like a contact currently, just with
> > less fields.
> > Domains could use "full contacts" (the ones we know today) or light
> > contacts (the new
> > ones).
>
> I can't see how this would work. Let's say we define a new object
> mapping for "light" contacts, with its own namespace, to be used with
> just the <contact type="tech"> element in domain objects.
>
> Could such contacts be used with domains without an update to RFC 5731?
Probably not, but so what? You can not just "update" RFC 5733, you will need to
write
a new one, with a new XML schema, and hence you will need to update RFC 5731
as well.
> Could a registrar determine whether a given contact object was a "full"
> contact or a "light" without performing an <info> command?
Since the registrar created the object in the first place, I do not see
the issue there.
Also, there may not be a need to mix contacts: a registry can decide to use
only one form (if the new schema is constructed in such a way to fit all
contacts
cases), and hence there is no question.
> I think this would cause a huge amount of confusion and pain.
Using placeholders creates even more confusion and just tries to go around
a schema that does not fit its use anymore...
> Furthermore, my research[1] indicates that the "one-to-many"
> relationship between domains and contacts that is implicit in EPP does
> not reflect reality,
And yet in the nearly 20 years of existence of EPP noone came forward to
propose working on this...
Please do not use the result of an ICANN *policy* to change the protocol
while implying this is needed for all EPP servers as it is was an EPP
deficiencies
in the first place.
It may well be an EPP deficiency and if so it needs to be tackled separately,
but that is really not the correct channel at this point.
> If we're going to write a new RFC just for technical contacts then I
I never suggested "just for technical contacts". On the contrary, if defined
properly, the schema could be used, in place, for all contacts. For some
registries,
like gTLDs ones bound by specific contracts, they could then just use those
instead of the current "contact-1.0" ones.
> would suggest that it should define an extension to the domain object,
> since that is (a) simpler for clients and servers to implement and (b)
> more accurately maps to the way the data is represented and handled
> outside of EPP.
This would create even more confusion, as clearly today the hosts as objects
vs hosts as attributes is one of the major pain point of any registrar
(again, one has to try to be in registrar shoes, for a registry everything
is simple, it has one case to handle, its own, and it can often forget that
its registrar have other cases to handle too, so all the complexities finish
on the registrars' shoulders)
> > One has to keep remembering that EPP is not just used by gTLDs, so any
> > change has to
> > be done in such a way that it does not impact negatively any operation done
> > outside
> > of ICANN circles.
>
> It seems to me that updating RFC5733 would have a bigger impact outside
> the gTLD world than either of the other options I've proposed:
I am still waiting on non-gTLD registries to participate in the subject
and to see how much they will be happy to see EPP changed for everyone
*just because* ICANN enacted some new policy.
> presumably many ccTLD registries rely on the the XML schema in RFC 5733
> to enforce their data collection policies, but if we change that schema,
> and they unknowingly update their implementation, then their data
> collection policy will be changed without them knowingly accepting it.
You can not "change that schema". You need to create a new namespace.
Besides, I have no idea what you mean. Registries policies on contact data
go far beyond what is in the EPP schema, in the sense of validation done
and constraints.
You already have far more problematic issue like "id" being either ignored
or just refused (while being mandatory in the schema), the "int" vs "loc" issue,
the semantics of "update" on "postalAddr", etc.
And again, if a new contact schema appears, registries that want it use it,
those that want to keep the current contact-1.0 keep it, and all is fine
(besides the complexities for registrars, but obviously they will have
to deal with it in any way, placeholders introduce their own complexities
as they will be hardcoded in every piece of code, so that the value is
not offered for edition for example, etc.)
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
