Hi George and Scott,
This WG, or whichever WG ends up doing this work (if any), should not be
hesitant to take on work because of ICANN. The IETF should support a much wider
audience than gTLD registries and registrars. This initiative has come from the
ccTLD world, and it would be unfair to
I view two options for meeting the goals of REPP, which I believe is to have a
more Cloud-friendly provisioning protocol:
1. Incremental Approach
* Implement incremental changes to EPP that make it more Cloud-friendly,
which does need to be fully compliant with the EPP RFCs. This inc
I agree with this. Furthermore, if a greenfield approach is desired it
would help if the protocol is not called EPP or a variation otherwise there
will be confusion.
-andy
On Thu, Jul 25, 2024 at 4:57 AM Gould, James wrote:
> I view two options for meeting the goals of REPP, which I believe is
Hi,
I would not see it that black and white.
Scott expressed perfectly yesterday, what I think should be a firm
design goal for a RESTful approach, that data representations and
protocol interactions should allow for easy and stateless translation
layer from/to RFC5730 EPP. I would add that t
Pawel,
REPP is clearly not EPP and not an EPP extension (not a transport compliant
with RFC 5730 section 2.1, not any of the EPP extension types defined in RFC
3735) . Below is an example list of compliance issues with REPP and EPP:
1. Being stateless
2. Changing the command framework b
Yes Jim, I am only not sure how this relates to what I've written.
Kind Regards,
Pawel
On 25.07.24 07:37, Gould, James wrote:
Pawel,
REPP is clearly not EPP and not an EPP extension (not a transport
compliant with RFC 5730 section 2.1, not any of the EPP extension
types defined in RFC 3735
Pawel,
It relates since there is a question of the problem that is being addressed.
If there is the assumption that REPP is EPP and not defining a new provisioning
protocol, then I don’t believe there is alignment in defining the appropriate
path forward. Are you proposing a third possible ap
Hi Jim,
Please refer to the slides Maarten presented yesterday. There is no
assumption that REPP is EPP, at least not in a sense if EPP is defined
as literally RFC 5730.
The Hybrid Approach as you call it is actually THE approach in my mind.
And yes the Design Considerations require further
Pawel,
Great, let’s add the Hybrid Approach to the list of options for clarity:
1. Incremental Approach
* Implement incremental changes to EPP that make it more Cloud-friendly,
which does need to be fully compliant with the EPP RFCs. This includes adding
support for the HTTP transpo
Hi folks,
I’m not yet operative so please forgive me if I will not reply to your
messages suddenly.
Would just like to make you know my idea of “hybrid approach”.
I basically intend the REPP implementation as EoH whereas EPP
Login/Logout are replaced by Bearer Token management.
That means upda
if possible and palatable, recharting RegExt still looks better to me.
And this is orthogonal to the ICANN risk that has been mentioned, which can be
addressed by not obsoleting or updating EPP RFCs, as they are the ones
mentioned in the gTLD agreements.
Rubens
> Em 24 de jul. de 202
Hi,
I've attended the meetings since Prague but am not an EPP person. Permit me
to offer a different perspective, based on what you've been saying about
the other topics of discussion.
When you've talked about EPP during those meetings, you talked about the
data model, the commands, but you
Hello all,
I asked one of our developers at GoDaddy to implement the Redacted RFC with the
changes that were included in the Errata. He was able to implement the RFC
with the proposed redaction as GoDaddy would be using it with redaction by
empty value and redaction by replacement in under two
13 matches
Mail list logo
