Hi Andy, On 10.01.25 18:21, Andrew Newton (andy) wrote:
On Wed, Jan 8, 2025 at 10:42 AM <kowa...@denic.de> wrote:Hi Jasdip,On 03.01.25 22:59, Jasdip Singh wrote: https://github.com/anewton1998/draft-regext-rdap-extensions/issues/56Section 4.2, paragraph 3 Extensions MUST explicitly define any required behavioral changes to the processing of referrals. If an extension does not make any provision in this respect, clients MUST assume the information provided by referrals requires no additional processing or modification to use in the dereferencing of the referral.Similar to the comment in 4.1 the same applies here. If the referral is to be treated as redirect, so that no processing of href is expected from the client, then anything in the href must fulfill the same requirements as redirect URL. In this case it is up to the server to assure compatibility of the request with the link target. An alternative scenario would be if media type application/rdap+json is an indicator of RDAP resources and in this case the responsibility shall be put on client to construct a valid RDAP request compatible with the target server and client's capabilities. In this case one would need to define this default processing expected from the client.[JS] Sorry, missing your point. That’s what this para is asking of an extension; to guide the client in case anything beyond the default “don’t touch the referral URL” scenario. [PK] It was rather an question with 2 possible outcomes - just pick one. The current text does not account for a situation that eventual post-processing may be a result from a different extension than the one specifying the referral.I am confused by the premise. If an extension does something like: "foo99_bar": [ "link": { ... } ] Why would that referral be subject to the link processing of the extension "faz1001"? The only issue I see here is that if extension "foo99" says all links in RFC 9083 json should be processed using X and extension faz1001 says the processing should by Y. But in that case, the server operator needs to not do that.
[PK] versioning is such example. Just imagine the request was done with ?versioning=foo99-1.0,faz1001-0.9If the (RDAP) referral link in foo99_bar would not contain versioning query parameter, the client would have to post-process to add it.
Otherwise the client would need to expect no post-processing required and the request would be done without versioning parameter.
foo99 could not know in its specification, if there would be a versioning extension. Versioning extension could specify that the query parameter should be added to all RDAP referrals from any extension. Alternatively the extension draft could make a generic requirement for this behaviour, like with redirects.
First option is that the servers (thus extension authors) shall assure referral links are valid and complete RDAP links and undergo exactly the same scrutiny as redirects, inkl. addition of query parameters based on the request from the client (like versioning parameter). If this option would be chosen some language around it would be helpful. Second option is that the client is always expected to post-process application/rdap+json referral links, because server will never add query parameters based on how the request from the client looks like. If this is the option adding some text would be needed as well.Third option which is the last paragraph. The extension explicitly states the necessary processing otherwise it is assumed the clients will do none, in which case the href is assumed to be valid and complete and does not leak sensitive or security information.
[PK] as indicated above it is not about the extension specifying the referral.
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
