From: Andrew Newton (andy) <a...@hxr.us> Date: Tuesday, January 14, 2025 at 11:52 AM To: Keathley, Daniel <dkeathley=40verisign....@dmarc.ietf.org> Cc: regext@ietf.org <regext@ietf.org> Subject: [regext] Re: Review of draft-ietf-regext-rdap-extensions-04 (Section 2.1.1 para 1) On Mon, Dec 16, 2024 at 9:33 AM Keathley, Daniel <dkeathley=40verisign....@dmarc.ietf.org> wrote:
> [DJK] There was some similar discussion at IETF-121. Formally defining RDAP > extension points I think is a good thing. An extension could then choose > which of those points to leverage e.g. path segments, query parameters, > object classes, etc. Basically, your list here. It's an interesting idea to > define an extension as simply an aggregate of other extensions. Such an > extension doesn't implement the formal extension points itself but instead > requires compliance with other extensions that do. Could be useful. Would you > still expect each of those "nested" extensions to be present in the rdap > conformance array, or just the profile extension? Such an example already exists in the 2024 gTLD profile and the NRO profile. [JS] Right, an Extension Styles section explaining how each extension style (regular, profile/marker, and bare) works vis-a-vis preventing naming conflicts in requests (paths, query parameters) and responses (JSON names, object class names) should help extension authors with the style choice. Jasdip
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
