Hi Jasdip, Tom, On 03.01.25 22:37, Jasdip Singh wrote:
https://github.com/anewton1998/draft-regext-rdap-extensions/issues/39 >> 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.)[JS] Good idea.> 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.[JS] OK[TH] I think this is fine, but I also think we are probably in agreeance with Pawel on this point already, in that the extension itself is what is documenting the relevant server policy here. (I might be misunderstanding Pawel's last statement here, though.)
[PK] the understanding is correct. Thanks.
> Interesting aspect is, whether a profile may be an alias for a certain configuration of extensions when doing requests. 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 versions) defined in a profile would be long.[JS] Interesting idea. The NRO RDAP Profile [1] has something similar where it includes the “cidr0” extension.[1] https://bitbucket.org/nroecg/nro-rdap-profile/raw/v1/nro-rdap-profile.txt[TH] In a strict sense, including the original identifier is not necessary, because clients that understand the profile will know what to do, and clients that don't will simply ignore the unknown members. I do think it makes sense to say that profile extensions SHOULD include the original identifiers in a case like this, though.
[PK] Yes, this was the point. Thanks.
[PK] Yes, this is a matter of practice but this would help the reader to be clear that it is allowed. A case when it would happen would be when an extension would build on top of other extension. In this sense it would implicitly require it, defining a profile in a sense.> 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).[JS] Interesting point. Nothing should preclude a regular extension from profiling, but it typically is more focused on a narrower problem.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
