Re: [regext] IANA Considerations in draft-ietf-regext-rdap-reverse-search

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: regext <[e-mail]> On Behalf Of Patrick Mevzek
> Sent: Friday, July 31, 2020 11:51 AM
> To: [e-mail]
> Subject: [EXTERNAL] Re: [regext] IANA Considerations in draft-ietf-regext-
> rdap-reverse-search
>
> On Fri, Jul 31, 2020, at 10:35, Mario Loffredo wrote:
>
> > The server might inlcude in rdapConformance either the hints to all
> > the supported features or the only hints to the features allowed to
> > the consumer.
> >
> > This also applies to the help response. Definitively, it's a matter of
> > server policy.
>
> If you introduce options (the list is either related to the content OR the full
> list of server features), how is a client supposed to know in which case he is?
> He can't right now, which is why I don't think such options should be added.

As it's currently written, 7482bis says this about the help query:

"The help path segment can be used to request helpful information (command syntax, terms of service, privacy policy, rate-limiting policy, supported authentication methods, supported extensions, technical support contact, etc.) from an RDAP server.  The response to "help" should provide basic information that a client needs to successfully use the service."

Note "supported extensions". This is why I'm saying that we need to register all extensions with IANA and include them in the rdapConformance data structure even if they don't describe a response extension. To Patrick's question above, I think it's a good idea to be consistent about it. The help response should include supported extensions that are available to that client. Note, though, that the list of supported extensions might vary if the client is identified and authenticated. In that case, some clients MAY have access to extensions that other clients don't.

Scott