As a reminder, the Chairs have suggested having an interim meeting as described below. There were no objections to this suggestion and 4 expressions of support. However, the Chairs have found themselves unable to find time to schedule this meeting.

Here is what we propose.

Next week, the Chairs will start a WG Adoption request for the following three documents as a package:

https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/

These documents will then form the starting point for the discussion to be had.

The Chairs will open the discussion at the REGEXT meeting during IETF119. Unfortunately, we won’t have a lot of time for an extended working session; what we will seek to accomplish is an understanding of what problem we want to solve. In addition, we will plan for an interim meeting during April that will be a working session to continue this discussion in detail.

If anyone has any questions or concerns about this path please do reply on list. If there are no objections this is how the Chairs will proceed.

Thanks,

Antoin and Jim



On 11 Dec 2023, at 9:09, James Galvin wrote:

The Chairs have caught up on this thread and have the following proposal for the working group

We suggest that the working group take on the problem space of considering negotiation, signaling, and versioning in RDAP.

To properly consider this problem space we should adopt as working group documents the following three drafts, all of which address at least part of this problem space:

https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/ (-02 just posted)
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/

In general, our goal as a working group is to have one solution on the standards track to a problem. After we have adopted these documents the working group will have to answer at least two questions:

1. Is there one problem to be solved or more than one?
2. Is there one solution or, if there are multiple problems, do we need multiple solutions?

These are technical questions based on use cases that have been discussed. The Chairs also suggest that we have an interim meeting, perhaps in late January or early February, during which we have a focused discussion seeking answers to those two questions, studying the value and benefits of each of the proposals in the documents above. The Chairs will address the logistics of an interim meeting after we have adopted these documents.

In addition, there is the question of whether or not the solution(s) to be proposed impact the following two documents:

https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/

The Chairs suggest that the simple-contact document should also be adopted, to move forward on the Experimental track with jsContact, and that we consider if either is impacted by the solution(s) to be proposed.

Thanks,

Antoin and Jim




On 14 Nov 2023, at 18:26, Jasdip Singh wrote:

Hello Antoin, Jim,

Given the ongoing discussion on how to negotiate extensions between RDAP clients and servers (using HTTP headers versus query parameters), be it for SimpleContact [1], JSContact [2], or versioning in RDAP [3], Andy and I want to request a call for WG adoption of the RDAP-X draft [4]. We believe that the HTTP headers-based approach could help unify extensions negotiation across the RDAP ecosystem.

Thanks,
Jasdip & Andy

[1] https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/ [2] https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ [3] https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/ [4] https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Reply via email to