Re: [regext] EPP evolution and the REGEXT charter

[Gould, James]

Maarten,

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, 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.  I'm not opposed to rethinking EPP using RESTful concepts, but it's 
not supported in the REGEXT charter.  

Thanks,

-- 

JG 



James Gould
Fellow Engineer
jgo...@verisign.com 


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com  




On 3/23/24, 3:55 AM, "Maarten Wullink" 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. 


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.


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. 


The name “Transport mapping” might be misleading in RFC5730. 


Maarten 
> 
> [You don't often get email from jgo...@verisign.com 
> . Learn why this is important at 
> https://aka.ms/LearnAboutSenderIdentification 
>  ]
> 
> 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 itself since it 
> replaces EPP RFC 5730. REPP may reuse some aspects of EPP, but it is a 
> replacement protocol. Can you find language in the REGEXT charter that 
> supports working on a replacement protocol to EPP?
> 
> Thanks,
> 
> --
> 
> JG
> 
> 
> 
> James Gould
> Fellow Engineer
> jgo...@verisign.com  
>  >
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com 
> 
>  
> ;>
> 
> 
> 
> 
> On 3/22/24, 9:28 AM, "Andrew Newton (andy)" mailto:a...@hxr.us> 
> >> 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.
> 
> 
> 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.
> 
> 
> I also take a more inclusive view that REPP could be covered under the
> latter section of the regext charter, specifically in that it defines
> XML and/or JSON files, exchanged over HTTP, between registration
> entities that need insertion in or extraction from EPP or RDAP.
> 
> 
> -andy
> 
> 
>> On Fri, Mar 22, 2024 at 8:01 AM Gould, James >  > >> wrote:
>> 
>> 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  > 

Re: [regext] EPP evolution and the REGEXT charter

[Maarten Wullink]

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.

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. 

The name “Transport mapping” might be misleading in RFC5730. 

Maarten 
> 
> [You don't often get email from jgo...@verisign.com. Learn why this is 
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> 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 itself since it 
> replaces EPP RFC 5730.  REPP may reuse some aspects of EPP, but it is a 
> replacement protocol.  Can you find language in the REGEXT charter that 
> supports working on a replacement protocol to EPP?
> 
> Thanks,
> 
> --
> 
> JG
> 
> 
> 
> James Gould
> Fellow Engineer
> jgo...@verisign.com 
> 
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com 
> 
> 
> 
> 
> On 3/22/24, 9:28 AM, "Andrew Newton (andy)"  > 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.
> 
> 
> 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.
> 
> 
> I also take a more inclusive view that REPP could be covered under the
> latter section of the regext charter, specifically in that it defines
> XML and/or JSON files, exchanged over HTTP, between registration
> entities that need insertion in or extraction from EPP or RDAP.
> 
> 
> -andy
> 
> 
>> On Fri, Mar 22, 2024 at 8:01 AM Gould, James > > wrote:
>> 
>> 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 Bluemont Way
>> Reston, VA 20190
>> 
>> Verisign.com 
>> 
>>  
>> ;>
>> 
>> 
>> 
>> 
>> On 3/22/24, 7:40 AM, "Andrew Newton (andy)" >  >> 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.
>> 
>> 
>> 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:
>>> 
>>> 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 f