[regext] Re: I-D Action: draft-ietf-regext-rdap-extensions-07.txt

Hi, First, thanks for the work already put into this document, but i have to say that i’m not a big fan of forbidding bare extension identifiers and mandating prefixes. Using prefixes to create namespaces for new attributes (JSON/URL/Headers) has limited additional value when: new attributes

[regext] Re: JSON syntax for TTL values (was Re: EXTENDED CALL FOR ADOPTION: draft-brown-rdap-ttl-extension)

Hi Andy, > > For clients that use mapping frameworks, some of those frameworks will have > problems with mapping unknown tags and therefore the client implementer will > have to specifically provide a mapping for every RR type therefore the > array approach is actually better for them espe

[regext] Re: EXTENDED CALL FOR ADOPTION: draft-brown-rdap-ttl-extension

agree, with adoption. i would like to see some changes to the data format if possible, now there are a bunch of nested arrays, as a developer i this is very annoying to work with. maybe we can make it a bit more developer friendly. for example, change this: { "objectClassName": "nameserver

[regext] Re: Fwd: New Version Notification for draft-ietf-regext-rdap-x-media-type-03.txt

Hi, Are we sure that it's a good idea to have a server response contain the used extensions in both the media type parameter and in the json response? the draft states that the contents should be the same, but it seems to me this is something that might endup going wrong in practice and conflict

[regext] Re: On bare identifiers in Extensions draft

>>> >> I mentioned it as it was referred to in -04 4.5. But you are right, paths, >> query parameters and object class names have the same properties. >> If there is a single item added by the extension, and it's equal to >> extension identifier - it's all same. >> For class names and query par

[regext] Re: ONE WEEK REVIEW of FINAL proposed revised charter for REGEXT

Hi Jim, my 2 cents regarding the following text from the proposed charter changes: "The working group may also take on work to develop specifications that are related to the EPP or RDAP registration processes, describe the information exchanged between entities involved in Internet identifier r

[regext] Re: Charter proposal for domain connect (dconn) working group

Hi Pawel, I like Domain Connect, i tried it in real world use case and it works very well, so definitely a +1 for DC as something that needs to be standardized. but, is creating a separate wg just for DC not a lot of overhead for you? as you probably already know, there is now some discussion in

[regext] Re: [Ext] Re: RESTful EPP Charter side meeting Thursday 13:00

Hello, Based on the feedback and comments we received during the regext session and the side meeting, we have decided that the best way forward is to: Charter a new working group which will use the Hybrid approach as suggested by Jim Gould, and develop a new protocol, that will not be called EP

[regext] RESTful EPP Charter side meeting Thursday 13:00

Hi All, Thank you all, for the comments and suggestions during our discussion earlier today about RESTful EPP. The Area Director suggested we create a new working group for this and similar work. If you are interested in joining us, to discuss and write a concept charter for this new WG, we ha

[regext] Re: RESTful EPP draft next session how to move forward

Hi Scott, Sorry i forgot to include a reference to the draft, you can find it here. https://datatracker.ietf.org/doc/draft-wullink-restful-epp/ - Maarten Op 23 jul 2024, om 07:03 heeft Hollenbeck, Scott het volgende geschreven: -Original Message- From: Maarten Wullink Sent: Monday

[regext] RESTful EPP draft next session how to move forward

Hi All, During the next REGEXT session on Wednesday we will be asking the WG where to best continue to work on RESTful EPP (REPP). There was broad support for this work during previous sessions and on the mailing list and by other communities such as CENTR (centr.org ) But,

[regext] Re: using experimental to move items forward

Hi, +1 for optimizing the process where possible. But i wonder why this new process is limited to RDAP extensions only? What is the distinction between RDAP extensions and other work done in REGEXT such as EPP extensions? - Maarten > Op 17 jun 2024, om 16:25 heeft Hollenbeck, Scott > he

[regext] Re: regext - New Meeting Session Request for IETF 120

Hi Jim, We would like to discuss and make a decision on how to move forward with RESTful EPP, potential options to discus include: - Adopt under current charter - Adopt under updated charter (will send concept text to the list, before the meeting) - Create new working group - Work on it outside

[regext] Re: regext - New Meeting Session Request for IETF 120

We were thinking about requesting an additional side-meeting to discuss how to best proceed with RESTful EPP, because there is not much time during the regext meeting. But if there is an additional hour for regext, then this side-meeting may not be required. - Maarten > Op 3 jun 2024, om 16:5

[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 "REST",

Re: [regext] Re-chartering REGEXT?

t;> D89FjLRT5lrZaVa9cMZxyPuSEYmYARHamAXBNMOFMXHHnujQGPhAF2M8id >>> 1FtuOAGKUZx_ >>>> 9lN0uy8-nt1j1GSUq_MDc4bXP3HycIzx_GA3O2pl8aT3qQv- >>> UMzd2TyyR6F9rxo3by0Gxd >>>> nKWY4K-F9kROR8T3Y8pcLSeN_xYzXCTdgqo- >>> ReR6LfvzIrlt1RqQuo4CdEXYRT7bpkT1Oz >>>>

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 transp

[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 s

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 ar

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 ther

[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 n

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 iana.org

[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 be

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: ht

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 2023

Re: [regext] Call for agenda items IETF 118

t;> to 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: >>> >>>

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 the