Hi Pawel,
On Mon, Oct 21, 2024 at 09:29:49AM +0200, kowa...@denic.de wrote:
> The ambiguity seems to be also there because /domains path segment
> is used the same in both context of RIR and domain name registry.
> The draft puts however RIR in focus. This poses an interesting
> question - if a domain name registry would like to define relation
> type of search as in this draft, is it ok to signal this extension
> and just support 'domains/rirSearch1/<relation>/<domain name>' path,
> or would it be expected to support all the paths defined, meaning in
> practice this extension would not be able to be used at all and an
> extension would have to be defined separately for this use case?
>
> Section 6 seems to imply that a partial implementation is not an
> intention of authors (even though I did not find any normative
> language around that:
>
> "[...] that is not meant to imply that a server can support only a
> portion of the functionality defined in this document."
The beginning of section 6 has "[a] server that supports the
functionality specified in this document MUST include additional
string literals in the rdapConformance array of its responses, in
accordance with the following: ...". In the absence of any text
permitting partial implementation, this text requires implementers to
implement the whole document ("the functionality specified in this
document"). The "that is not meant to imply" text was included just
to avoid any potential doubt about the option of partial
implementation, which is greater in this case than with other
extensions, due to their being multiple extension identifiers.
As far as the forward domain use case is concerned, the
"/domains/rirSearch1/..." specification text can't be relied on as-is,
because it's all in terms of reverse domains, and depends on their
correspondence with internet number resources. If somebody wanted
similar link relation searches for forward domains, then I think it
makes more sense to define that in a separate document, rather than
trying to generalise this document to support that use case as well.
-Tom
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
