> -----Original Message----- > From: Maarten Wullink <maarten.wull...@sidn.nl> > Sent: Saturday, March 23, 2024 3:56 AM > To: Gould, James <jgo...@verisign.com> > Cc: a...@hxr.us; mario.loffr...@iit.cnr.it; jasd...@arin.net; Hollenbeck, > Scott <shollenb...@verisign.com>; regext@ietf.org > 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. > > REPP is not meant to be a replacement for RFC5730. Version 01 uses a custom > schema based on the RFC5730 schema, because that looked to be a cleaner > way to do it. > But we could change it so REPP uses the RFC5730 schema as in Version 00. In > that case we can describe which XML elements and types are not reused by > REPP.
[SAH] Modification of the schema is where we cross into "this isn't an extension" territory. Using the 5730 schema would eliminate that concern. > I don’t see REPP therefore as a new protocol. it reuses almost all EPP > datastructures and protocol commands. Commands are mapped to URLs and > all extensions should still work > > I believe the closest match for REPP is a transport mapping. A transport > mapping doest have to use a obvious transport protocol such as tcp/quic it > can also be an L7 layer protocol. Section 2.1 for instance gives the SMTP > protocol as an example for a possible transport mapping. [SAH] Here's a thought: could REPP build on the newly proposed HTTPS transport mapping and focus instead on the mapping of commands to URLs? Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
