From: Andrew Newton (andy) <[email protected]> Date: Tuesday, January 14, 2025 at 11:52 AM To: Keathley, Daniel <[email protected]> Cc: [email protected] <[email protected]> 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 <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
