Hi Pawel, +1 for prioritizing what we said we would at IETF-121. See [DJK] below.
--Dan On 11/21/24, 7:36 AM, "Pawel Kowalik" <kowa...@denic.de <mailto:kowa...@denic.de>> wrote: Hi, As extensions draft is the first to get through the WG doors and dependency for others I took it for a more detailed review. Sorry it is quite long. If responding to a particular issue, I would appreciate separate email threads with distinct subject if the issues are not related. This would help to follow and response the threads I believe. Formatting and structure done with https://secure-web.cisco.com/1g9duRMk0S0rhr31S1LtFjcel3890kKJN1nExqs1kzINODcXXwn6Kdeh1U6p4kFOU56TKbl3prZpayta8nexNN8vkCN9V__UtyReFzYpCwGZgcC8bSd2NcXRyJFWFM_WVs6QJ2hB1QtVoJAgHi66rDCcOeHv8sCal1qhKmPwAvrfrKeFeeJHzcARf96wJVXg-N3bY1aiU253OnIAULTcnYVfSJ7Uimhu_0CFR_tC3CjPSoQI95QQXUAQqDIDKoidb5ESGlQlXhzkTrEcagIhv2ccf07NXafYvEatKgym0VoGOoMmfERmNO5lohh481WfX/https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool <https://secure-web.cisco.com/1g9duRMk0S0rhr31S1LtFjcel3890kKJN1nExqs1kzINODcXXwn6Kdeh1U6p4kFOU56TKbl3prZpayta8nexNN8vkCN9V__UtyReFzYpCwGZgcC8bSd2NcXRyJFWFM_WVs6QJ2hB1QtVoJAgHi66rDCcOeHv8sCal1qhKmPwAvrfrKeFeeJHzcARf96wJVXg-N3bY1aiU253OnIAULTcnYVfSJ7Uimhu_0CFR_tC3CjPSoQI95QQXUAQqDIDKoidb5ESGlQlXhzkTrEcagIhv2ccf07NXafYvEatKgym0VoGOoMmfERmNO5lohh481WfX/https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool> ------------------------------------------------------------------------------- DISCUSS ------------------------------------------------------------------------------- Section 2.1.1, paragraph 1 > While the RDAP extension mechanism was created to extend RDAP queries > and/or responses, extensions can also be used to signal server policy > (for example, specifying the conditions of use for existing response > structures). Extensions that are primarily about signaling server > policy are often called "profiles". For a profile extension it is needed to define what is it supposed to do. Here some initial list of what such list might consist of: - mark some specific extensions (and versions thereof) as required - mark some specific optional fields/url segments/object classes as required - limit value space of specific fields (for example enumeration of values or a pattern for a text field, narrowed down enum, value range for numeric fields etc.) I would also not mention "server policy" as in the end such profile puts down certain technical requirements on a server which a client can rely on. So it increases technical interoperability. Interesting aspect is, whether a profile may be an alias for a certain configuration of extensions when doing requiests. So for example if profile1 would define it requires extension foo to be supported and included in the answer, then would it be enough for the client to request profile1 and be sure that extension foo is always included in the response? It may be an interesting property if a list of extensions (and their versoins) defined in a profile would be long. Finally it would be worth mentioning if it's either/or between profile extensions and regular extensions or it is OK for a regular extension to define profile as well (with all the properties explained above). [snip] [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?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
