Thanks for the review Pawel. My response is in-line: On Wed, Jul 12, 2023 at 2:41 AM Pawel Kowalik <[email protected]> wrote: > > Hi Andy, > > Thanks for putting down this draft. A method for the client to signal > supported or wanted extensions is really needed. > > A remark to the Section 3: I think all cases should be covered by this > section. Currently I'm missing, the case when the server would support > more extensions than requested/understood by the client. I think it > would be good to make a recommendation for the server implementation > what is the desired behavior in such case. My suggestion is the server > SHOULD respond with no additional extensions as far as the server > capable of doing so (e.g. can render dynamic responses). It may be > relevant for the cases where the extensions define not only JSON > structures, which in general should not be an issue for the client > receiving an unsupported extension, but also define a response profile > which not necessarily have to be compatible with each other.
Yes, I think we should cover this scenario. Thanks for pointing it out. And I agree with your suggested behavior. > > Another remark to the media type. RFC7480 specifies the usage of > 'application/json', 'application/rdap+json' or both. Why the draft > changes the requirement to require only 'application/rdap+json'? Is this > change required to achieve the objectives of this draft? No, it is not required to reach the objectives of this draft. And if my logic is correct, this does not change the base behavior of 7480, but that "application/json" is not part of the rdap-x negotiation. We can add it back though if this causes more confusion or interoperability issues. What's your opinion? > > rfc9110 defines all media types as the same preference if having the > same weight. Wouldn't it be more appropriate to indicate > 'application/json' and or 'application/rdap+json' with different (lower) > weight than 'application/rdap-x+json' to indicate the clients' preference? Probably, though why would a client be using rdap-x at all if it didn't prefer it. But for completeness, we probably need to account for this. > > To the design considerations I am missing a bit whether usage of custom > http header has been considered by the authors. The usage of "Accept" > header with a new media type, where in fact the responses are of the > same media type is a bit of misuse of this header, so I understand there > are good reasons for choosing this way. Here's the squishy answer(s). We are unlikely to get a special header just for RDAP purposes via the IETF. I just don't see it happening. And there have been other attempts to get new headers that do "profiles" such as Accept-Profile and they didn't get very far. > > The last question to the discovery part. Shall client have a possibility > to find out support for this extension prior to a real request, for > example by OPTIONS http request? I understand this is not a real > extension, so it would not appear in RDAP conformance when requesting > /help path. This document does not disallow use of rdap-x in OPTIONS, so I guess they could. Are you advocating some specific behavior? Is there a CORS scenario we should think of? And though this is not an RDAP extension, a client using /help would know if a server supports rdap-x. I'm a bit skeptical of RDAP specific discovery scenarios. I know browsers will do HEAD and OPTIONS requests, but that's not RDAP specific. To my knowledge, there are no RDAP clients that do a /help and then change their behavior. /help is used by humans, if at all. -andy _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
