[regext] RDAP and link context

James Mitchell <james.mitchell@iana.org> Tue, 27 February 2024 23:56 UTC

Return-Path: <james.mitchell@iana.org>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3487C151098 for <regext@ietfa.amsl.com>; Tue, 27 Feb 2024 15:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynMn5dgqrNlD for <regext@ietfa.amsl.com>; Tue, 27 Feb 2024 15:56:27 -0800 (PST)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EDEEC14CE42 for <regext@ietf.org>; Tue, 27 Feb 2024 15:56:27 -0800 (PST)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa2.lax.icann.org (8.17.1.24/8.17.1.24) with ESMTPS id 41RNuQXV014008 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <regext@ietf.org>; Tue, 27 Feb 2024 23:56:26 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Tue, 27 Feb 2024 15:56:25 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) by MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) with mapi id 15.02.1258.028; Tue, 27 Feb 2024 15:56:25 -0800
From: James Mitchell <james.mitchell@iana.org>
To: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: RDAP and link context
Thread-Index: AQHaZD7sbpex40/6BU+9HhLMhWa5DQ==
Date: Tue, 27 Feb 2024 23:56:25 +0000
Message-ID: <E057A842-3FF6-4A0A-BD95-9CB8C047BBE9@iana.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: multipart/alternative; boundary="_000_E057A8423FF64A0ABD959CB8C047BBE9ianaorg_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-27_10,2024-02-27_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/m8hHozP3ohSHX5PbGiBJhJk-o3o>
Subject: [regext] RDAP and link context
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Feb 2024 23:56:27 -0000

Hi all,

What is the purpose of the context URI in the links structure? From 9083:
The "value" JSON value is the context URI as described by [RFC8288]. The "value", "rel", and "href" JSON values MUST be specified.

My understanding is that the context URI is the request URI that generated the JSON response. Implementing this correctly presents problems for a valid server implementations given caching is non-trivial because one object can be located from more than one URI. For example, /domain/EXAMPLE.COM, /domain/example.com, /domain/eXaMpLe.cOm are all different context URIs even though we understand they will return the same object. For a less trivial example, consider a domain object matched by A-labels, U-labels, and any other labels that identify an object via UTS46 or variant processing.

I’ve surveyed a few registries and noted inconsistent implementations of the spec:

  *   .org – link context is identical to the target for all links
  *   .com – link context is present for a singular self link and the context and relation type are absent for links in notices
  *   .xyz – link context is absent from all links

I am not aware of any specifications where the link context is explicitly defined with the creation/definition of a link (e.g. HTTP link header, w3c HTML5 spec, Atom).

Is the link object’s context/value used at all? Is it possible for a future update the RDAP spec to remove the link context, perhaps in RDAP-X?

Thanks,
James