REPPP is not a transport, it’s much more than that. And changing RFC 5730 has a trickle-down effect to some of the EPP users that might be unwanted, like the gTLD space.
But rechartering this WG seems the most logical course of action, since this audience is likely the one for discussing REPP. Or whatever we name it, since it might be extensible or not. Rubens > Em 2 de abr. de 2024, à(s) 11:41, Gould, James > <jgould=40verisign....@dmarc.ietf.org> escreveu: > > Maarten, > > The scope of an EPP transport is limited and is specifically defined in > Section 2.1 of RFC 5730. Defining a stateless protocol that has additional > options for the command and response format is not EPP and not an EPP > transport. SMTP being referenced in RFC 5730 doesn't make it a true viable > EPP transport since it's up to a transport draft to fully define it by > complying with Section 2.1 of RFC 5730. Examples of EPP transports include > EoT with RFC 5734 and new proposals with EoH in > draft-loffredo-regext-epp-over-http and EoQ in draft-yao-regext-epp-quic. > Defining a new EPP transport cannot require a change in RFC 5730. > > Thanks, > > -- > > JG > > > > James Gould > Fellow Engineer > jgo...@verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > > On 4/2/24, 10:14 AM, "Maarten Wullink" <maarten.wull...@sidn.nl > <mailto:maarten.wull...@sidn.nl>> wrote: > > > 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. > > > 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? > > > > >> 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? > > > > > > > Maarten > > > > > > > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
