Re: [regext] RDAP and link context

"Andrew Newton (andy)" <andy@hxr.us> Wed, 28 February 2024 12:03 UTC

Return-Path: <andy@hxr.us>
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 A3693C14F6B5 for <regext@ietfa.amsl.com>; Wed, 28 Feb 2024 04:03:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20230601.gappssmtp.com
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 bJPeNmpdN-Fx for <regext@ietfa.amsl.com>; Wed, 28 Feb 2024 04:03:24 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AC7C14F5F1 for <regext@ietf.org>; Wed, 28 Feb 2024 04:03:24 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2d28e465655so42402991fa.0 for <regext@ietf.org>; Wed, 28 Feb 2024 04:03:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20230601.gappssmtp.com; s=20230601; t=1709121802; x=1709726602; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uhXuaAG/JsndwluhyOko67BF5dFFqIAFeRFfBmbgBT8=; b=cQ1itW5p0nbk0Fluq2A0nwp9atFpkyxasPyN8AoZ3+o/m8fTOu7l477JL/szOfIzyJ iT0cv9b1iBkSo7JDqIGyaxiFvY9p3aZZ7HGllPSjHqiDsRMe76kp5QT7yEOOfzr/H1PC xHGyiyOnIy88f3xJGkzhyJfB7ofbvI4Ym/fDatPCcitOy79GVlyLOTm6Oq/LpF5kG1g6 OtE3RkknXoc3fSXUp56P/6Uv7LRDnqc3Rs1eyR2SMH9pUioaEXdcR7bCwyi78NUJvvug 8dEMEoPaDidZ0GRw+deEGstz/yewB3FL4xsHhf22C40k6tBVWnW/zvqOC8tmU12q4z+g zrRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709121802; x=1709726602; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uhXuaAG/JsndwluhyOko67BF5dFFqIAFeRFfBmbgBT8=; b=AKNwmxjhXUtyWTw6wmvY2vQv0v1A0Z9sHMSL2XdcCGkeT5PtmX9xZ9vdIH9p5cEJHz vLtofUkDaceDa81pXKu42z7YXFkugdxy7inE1SV+vFVIPhsXWBHBOy75SX4ZOW0tWL6f gTulE4HOZTaYXdq+1EKMGAUtcFxbmm8kazLgD3UmM6Mo4vcckVUF2mUwX/j/75ti8fJw OFwP8YzVjooEekeMLSevD90JhKMsGx7uqnOK98W0UoJSKKjsHa+Y7blrJcPWhr4kRg73 zYIpFNzwYbtp7TCAVpGrez0OqxHYy77kcgLS3GCgJXVmlkYYGe3MMbN2YG29oifj36VC +lXQ==
X-Gm-Message-State: AOJu0YyRj7s7sBiwiqn844/PHTOFG7FBEWMap0fjw1oyj/iJ7myzQSY3 AhmTid9MoaVrCJ84B3K9R/duaVcKfqdN0Xkjb//640tq29DcMpc8bOYmkbdThy3gA65qPxf4Or2 YZzEgKdCtWFymj7oG5ssVgp4Fi4yEVDxU93ypCVOxZ72ItmY6
X-Google-Smtp-Source: AGHT+IFYdp/pfRV3Yztl2OdtBnkc9+uJTvtVO4hKly4c/A2STApUoTpWNKO3qDvoFE6UosA+dYTgshhnlpPjZyqaoyg=
X-Received: by 2002:a2e:9402:0:b0:2d2:4ccb:747e with SMTP id i2-20020a2e9402000000b002d24ccb747emr7226652ljh.17.1709121801705; Wed, 28 Feb 2024 04:03:21 -0800 (PST)
MIME-Version: 1.0
References: <E057A842-3FF6-4A0A-BD95-9CB8C047BBE9@iana.org>
In-Reply-To: <E057A842-3FF6-4A0A-BD95-9CB8C047BBE9@iana.org>
From: "Andrew Newton (andy)" <andy@hxr.us>
Date: Wed, 28 Feb 2024 07:03:10 -0500
Message-ID: <CAAQiQRco_P-U2EzwXPOudpohUvO0kNhbBkkFBGKbrCG+ANUogA@mail.gmail.com>
To: James Mitchell <james.mitchell@iana.org>
Cc: "regext@ietf.org" <regext@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/q6qF2oMQxd153saLiV_yNP5-DsM>
Subject: Re: [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: Wed, 28 Feb 2024 12:03:25 -0000

Hi James,

RFC 7483 did not require the 'value' attribute, however when the
standard was revised in RFC 9083 this attribute became required.

I believe you are correct that a link context is not well defined. It
is supposed to be the scope in which a link is to be understood. In a
JSON response full of all sorts of other things (such as an RDAP
response), that scope could be seen as the request URI that got that
JSON response. However, that is just one interpretation. The new gTLD
Response profile makes use of the 'value' attribute as the RDAP base
URL for registrars, which I think is also a fair interpretation of the
context of a link since the href is a specific URL that is a subset of
a large group of URLs in which the base URL is the parent.

If we want to start more strictly defining what that value should be,
I think the rdap-extensions document is a better place than the rdap-x
document. I don't know about making it optional again. Hopefully
others who have a clearer recollection of the 7483 -> 9083 transition
can provide better context - pun intended. :)

-andy

On Tue, Feb 27, 2024 at 6:56 PM James Mitchell <james.mitchell@iana.org> wrote:
>
> 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
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext