[regext] Re: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt

Hi Gavin, Like Marc, i’m not a big fan of duplicating the link information from the json response into the response headers. However, for the HEAD method request i do see a use case, because in this case there exists no data duplication and the client can efficiently navigate the Link headers

Re: [regext] [Ext] Re-chartering REGEXT?

Hi Gavin, Thank’s for your comments! If "scalability" (based on a cloud paradigm which is designed around HTTP) is the sole objective, then I think that draft-loffredo-regext-epp-over-http would be the "smallest shippable delta" to achieve that objective. However, your use of the term

Re: [regext] Re-chartering REGEXT?

OFMXHHnujQGPhAF2M8id >>> 1FtuOAGKUZx_ >>>> 9lN0uy8-nt1j1GSUq_MDc4bXP3HycIzx_GA3O2pl8aT3qQv- >>> UMzd2TyyR6F9rxo3by0Gxd >>>> nKWY4K-F9kROR8T3Y8pcLSeN_xYzXCTdgqo- >>> ReR6LfvzIrlt1RqQuo4CdEXYRT7bpkT1Oz >>>> /http%3A%2F%2Fverisigninc.com%2F> >>

Re: [regext] Re-chartering REGEXT?

Hi George and others, > > > The protocol is in the registry-registrar and client-registrar > interaction space we work on. Thank you George, that was just the point i was trying to make. For the re-charter discussion It does not really matter if we define something such as REPP to be a

[regext] Re-chartering REGEXT?

Hello everyone, The REGEXT WG charter seems to be limited to only allow work on EPP extensions? The WG preliminary consensus is that updating the charter for new transports (requires RFC5730, sec 2.1 compliance) is not required. Because a new transport is regarded as a type of extension, so for

Re: [regext] EPP evolution and the REGEXT charter

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

Re: [regext] EPP evolution and the REGEXT charter

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

Re: [regext] EPP evolution and the REGEXT charter

RFC5730 Section 2.7 describes how to extend the XML data model to create a new EPP extension. and the transport considerations in section 2.1 describe how to create a new transport mapping. The charter then considers both to be types of an EPP extension, this works for me. but it does seem

[regext] EPP evolution and the REGEXT charter

Hi all, Is the charter for the REGEXT WG limited to working on EPP XML extensions only? If so, what is then required for allowing the different new transport proposals to continue? A new transport is clearly something different. Do we need to expand the current charter and maybe change the WG

Re: [regext] EPP Transport Service Discovery

how about using an iana registry similar as described for rdap? see Bootstrap Service Registry for Domain Name Space

[regext] RESTful EPP version 01

Hi all, We have just uploaded the 01 version of the draft for RESTful EPP https://datatracker.ietf.org/doc/draft-wullink-restful-epp/ We have requested some time at the meeting in Brisbane, to discuss the changes we’ve made between the 00 and the 01 version and to receive guidance on how to

Re: [regext] Call for agenda items IETF119

Hi Antoin and Jim, I would like to request some time to present the progress made on the RESTful EPP draft and to get feedback on our work and open questions. thx. Maarten The draft can be found here: https://github.com/SIDN/ietf-epp-restful-transport and the draft for handling json, here:

Re: [regext] Call for agenda items IETF 118

> Ok, Maarten, I squeezed you in for the 10 minutes Andy gave up. Thank’s! > > You can upload your presentation to > https://datatracker.ietf.org/meeting/118/session/31683/propose_slides > Or you can send them to the chairs to do so when ready. > Please have your slides uploaded at latest

Re: [regext] Call for agenda items IETF 118

overrun. >> Perhaps we should consider a 2 hour meeting request for next IETF 119. >> >> Regards, >> >> Antoin >> >>> Op 16 okt. 2023, om 17:52 heeft Maarten Wullink >>> het volgende geschreven: >>> >>> Hi Antoin,

Re: [regext] Call for agenda items IETF 118

Hi Antoin, Maybe a bit late, but would it be possible to add a few minutes for a discussion about the usefulness of REST enabled EPP. Thanks! Maarten see below for my motivation from a mail to the list last week: Seeing that more and more registries are moving their infrastructure into the

[regext] EPP and cloud deployment, improvements possible?

Hi All, Seeing that more and more registries are moving their infrastructure into the cloud, it might be a good time to take look again at the transport used for EPP. Adding a method for easily running EPP services in the cloud could make things easier for registries and registrars. some of