Hi Jasdip, On 03.01.25 22:59, Jasdip Singh wrote:
[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.https://github.com/anewton1998/draft-regext-rdap-extensions/issues/56 >> Section 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.
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.
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
