Re: [regext] EPP evolution and the REGEXT charter

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Maarten Wullink <[e-mail]>
> Sent: Tuesday, April 2, 2024 10:15 AM
> To: Gould, James <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Hollenbeck,
> Scott <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] Re: [regext] EPP evolution and the REGEXT charter
> 
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi James,
> 
> 
> >
> > An EPP transport mapping must fully comply RFC 5730 and specifically
> > Section 2.1 of RFC 5730.  REPP defines application-level protocol
> > aspects that do not comply with RFC 5730, such as being stateless,
> 
> When  RFC5730 section 2.1 was written, an EPP deployment as a stateless
> service was probably not something that was thought of, which makes sense
> at the time.
> Modern APIs and web services nowadays make heavy use of stateless
> architectures.

[SAH] Yes, it *was* thought of. Section 2 of RFC 5730 explicitly describes the outcome of that thought process:

"EPP is a stateful XML protocol that can be layered over multiple transport protocols."

A very specific decision was made to make EPP a stateful protocol.

> When we feel that statelessness may be something that should be compatible
> with EPP, then we may choose to update RFC5730 section 2.1 so it also allows
> for statelessness?

[SAH] That would be a fundamental change to EPP.

> > defining a new command format, and defining a new response format.  REPP
> defines an alternative to EPP using RESTful concepts and reusing some
> elements of EPP and is not an EPP transport extension.
> 
> REPP does not use new data structures for command and response, existing
> data structures are reused.
> How can something such as SMTP be regarded as a transport extension and a
> HTTP based (RESTful) solution cannot?
> both are mapped to a different endpoint when compared to EPP over TCP,
> email addresses ( SMTP) and URIs (REPP)
> 
> >  I'm not opposed to rethinking EPP using RESTful concepts, but it's not
> supported in the REGEXT charter.
> 
> 
> You mean, updating RFC5730 section 2.1 is not support? we would need to
> update the charter?
> 
>  RFC5730 section 2.1 contains the guiding principles and requirements  for
> new EPP extension transport mappings and is a core part of the EPP extension
> mechanism and therefore should it not be logical that the regext charter not
> only cover epp extensions but also the requirements for those extensions?

[SAH] I'm not a WG chair, or our AD, so this is just my opinion as someone who's very familiar with both the process and the subject matter: correct, updates to RFC 5730 are not something we can currently work on. We can work on EPP extensions, and requirements/guidelines for those extensions as described in RFC 3735.

Scott