Andy,
I'm not comparing EoH with REPP in any way since they're not competitive. I
view the EoH and EoQ drafts as a fully complaint transports with the
extensibility defined in EPP RFC 5730, and therefore they're covered by the
existing REGEXT charter. REPP is a competitive draft to EPP
Il 22/03/2024 13:01, Gould, James ha scritto:
Andy,
It's not a question of fairness, but a question of what is defined in EPP RFC
5730 as it comes to extensibility of EPP. EPP RFC 5730 includes extensibility
of transport, as reflected in Section 2.1.
This is what I meant to say with my
James,
If you wish to persist this line of reasoning whereby your drafts are
in charter but REPP is not due to an unorthodox definition of what is
and what is not an EPP extension, be aware that there is plenty of
text in the current RFCs that define more strictly the nature of an
EPP extension.
Andy,
It's not a question of fairness, but a question of what is defined in EPP RFC
5730 as it comes to extensibility of EPP. EPP RFC 5730 includes extensibility
of transport, as reflected in Section 2.1.
--
JG
James Gould
Fellow Engineer
jgo...@verisign.com
703-948-3271
12061
I am against any logic that creates different gating factors for the
different, competing solutions. Any contortion of the concept of an
EPP "extension" that results in the favor of one set of drafts over
the other is obviously unfair.
-andy
On Fri, Mar 22, 2024 at 5:33 AM Mario Loffredo
wrote:
>> . . I believe the rate limiting and exclusivity or non-exclusivity on a
>> single transport as server policy and out of scope for the definition of the
>> transports.
+1 – that seems like server side policy and should not be handled here.
Thanks,
Jody Kolker
319-329-9805 (mobile)
Please
Hi Mario,
Agreed. REPP looks like a new protocol that is more like the writing
counterpart of RDAP in terms of using HTTP methods for (most of) the EPP
semantics. In contrast, EoH and EoQ nicely fit in as the EPP transport
extensions. But, as Pawel said, it would be good to get REPP off the
Hi Jasdip,
IMO, REPP is not an "EPP extension" as defined by RFC5730. It provides
neither just a switch of transport (like EoH and EoQ) nor an extension
to EPP comands and responses.
Instead, it presents a full revision of EPP that maps some EPP features
onto HTTP features.
Moreover, the
Hi,
After the discussion we had in Prague my impression was that the group was open
to consider approaches that go beyond just exchanging the transport.
And as Maarten already highlighted in Prague there is an immersing need to have
provisioning protocol in form of REST API with JSON
