Hi Roger,
Thanks for taking the time to answer my question.
I try to convince myself using client validation / UX argumentation. The most
common user journey we experience – but maybe that’s not a typical user journey
for all TLDs? – is:
1. A candidate Registrant visits the Registrar websit
Good Morning,
Thanks Pieter. I think the real goal of Validate is improved customer
experience.
I don’t think wrapping this in a transaction helps as the error identification
is still occurring to late in the process.
There are quite a few steps in the registration process but today one of the
Ulrich
I am impressed by your process of checking who tested and who did not and
actively contact those who did not test. We did something like that as well
when we turned off TLS1.0 so I agree to this procedure for some cases.
It kind of confirms my statement that a technical change needs lon
Changed milestone "Submit for publication "Registration Data Access Protocol
(RDAP) Object Tagging"", resolved as "Done".
URL: https://datatracker.ietf.org/wg/regext/about/
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/re
> -Original Message-
> From: regext On Behalf Of Patrick Mevzek
> Sent: Tuesday, July 17, 2018 3:37 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Tidbits after monday meeting, related to
> registry mapping extension => IPR
>
> I discovered this myself just before the meeting
Martin,
if I understand you right, the problem is ignorant registrars. And the
solution is to make it easier for them to stay ignorant.
I am convinced that this is not the best way to go.
Clear communication with registrars and all internal departments sounds
more feasible.
We deploy these change
Patrick,
Thank you for your detailed feedback. We'll take a look at your following
messages. I believe the goal of the Registry Mapping is to hit on the most
common use cases and leave exceptional cases up to extensions (the 80/20 or
90/10 rule). If there is a crosscutting policy being appli
Hi Ulrich
We do have contracts yes. However experience shows us that some registrars just
don't have the necessary technical skills or means to react on any changes we
ask them to implement. To pull a change through, long dead lines must be
granted and even after that, only a part of them actu
* some registries allow, in domain:create, either attributes or objects for
host.
One might say this is against the core EPP specification, so do we want to
treat it?
* some registries do not allow all possible values for IP addresses. For
example one is saying that it will
refuse any IP provid
* int/loc
The current 4 values in the draft (loc, int, locOrInt, locAndInt) should be
replaced by 3 independant booleans:
loc = loc only
int = int only
locAndInt = loc+int only
With combinations, that will makes us available to encode all cases I think:
- wide registries accepting every case (so
* contacts, the extension has:
: Zero or more elements
that defines the minimum and maximum number of contacts by
contact type.
This will not cover all cases, like those:
- admin contact is optional and falls back to registrant
- since you allow for custom type (and I disa
Specific points related to RFC5730:
* clTRID is optional; but some registries make it mandatory
* some registries do not allow some commands, like contact:transfer being not
implemented (this is very frequent)
or even sometimes contact:check (especially if registrars do not control their
IDs), o
I discovered this myself just before the meeting when preparing it but Scott
also clearly mentioned it during the meeting (thanks for that): there is
currently an IPR on this extension, with the case of "details will be provided
later".
You may recall that we were in a similar case for the key
https://datatracker.ietf.org/doc/html/draft-gould-carney-regext-registry
Multiple subjects were covered and I had to input some data, so I will be doing
different topics by replying to this email so that they are threaded together.
You may wish to read all of them for context before replying to
14 matches
Mail list logo
