Hi all,
On Wed, Feb 28, 2024 at 07:03:10AM -0500, Andy Newton wrote:
> 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.
RFC 8288 (section 2) has:
This specification does not define a general syntax for links
across different serialisations, nor does it mandate a specific
context for any given link; it is expected that serialisations of
links will specify both aspects.
which appears to leave the definition of context open, but in section
2.1 it has:
In the simplest case, a link relation type identifies the
semantics of a link. For example, a link with the relation type
"copyright" indicates that the current link context has a
copyright resource at the link target.
Relation types are not to be confused with media types [RFC2046];
they do not identify the format of the representation that results
when the link is dereferenced. Rather, they only describe how the
current context is related to another resource.
and in section 2.1.1.1, about link relation registrations:
o *Description*: A short English description of the type's
semantics. It SHOULD be stated in terms of the relationship
between the link context and link target.
so although there's an expectation that specifications making use of
web links will define how the context is to be set, there are some
bounds on what a specification is able to do here.
In the APNIC implementation, the request URI is used for the context
for all links in a response. However, given the text in 8288, that
behaviour doesn't appear to be correct. For example, for a link in a
nested entity in a search response:
$ curl -s https://rdap.apnic.net/entities?fn=Test* | jq
.entitySearchResults[0].links
[
{
"value": "https://rdap.apnic.net/entities?fn=Test*";,
"rel": "self",
"href": "https://rdap.apnic.net/entity/TC1001-AP";,
"type": "application/rdap+json"
}
]
$
Given that the link relation description for "self" from the registry
is "[c]onveys an identifier for the link's context", I think the
"value" entry above should be
"https://rdap.apnic.net/entity/TC1001-AP";, rather than the request
URI.
On Mon, Mar 04, 2024 at 06:58:43PM +0000, James Mitchell wrote:
> The link context should not have been made mandatory. If you are to
> fix this, I would suggest text along the lines of:
>
> A link must have a context, a relation type, and a target as
> described in Section 2 of [RFC8288]. By default, the context is the
> is the URI associated with the entire JSON response and does not
> need to be explicitly defined. The "value" JSON value can be used to
> assign a different context URI, however servers and clients should
> be aware of Section 3.2 and Section 5 of [RFC8288] when providing
> assigning different contexts. The JSON name/values of "rel", "href",
> "hreflang", "title", "media", and "type" correspond to values found
> in Section 3<https://www.rfc-editor.org/rfc/rfc8288#section-3> of
> [RFC8288<https://www.rfc-editor.org/rfc/rfc9083#RFC8288>]. A
> "related" link relation MUST NOT include an "href" URI that is the
> same as the "self" link relation "href" URI to reduce the risk of
> infinite client processing loops. Internationalized Domain Names
> (IDNs) returned in URIs SHOULD be consistently returned in LDH name
> format to allow clients to process these IDNs according to their
> capabilities.
Because nested objects are included in responses, I don't think
defaulting to "use the request URI" can work here. I think it would
work better if the guidance were about using the URI of the specific
object within which the link appears.
On Tue, Mar 05, 2024 at 08:42:43PM +0000, James Mitchell wrote:
> From: "Andrew Newton (andy)" <a...@hxr.us>
>> What's the issue with setting it to the request URI?
>
> The server can’t pre-compute a response where multiple URIs map to
> one object – one has to patch any pre-computed response prior to
> sending back on the wire. This is a use of compute resources for
> what seems to be no benefit. I could have the response link the
> request.path to a canonical path, and anchor links of that canonical
> path, but this seems like busywork.
I understand the first two sentences here, but I'm not sure about the
last one. If the server accepts a request like /domain/EXAMPLE.ORG,
and returns exactly the same response as it would for the request
/domain/example.org (i.e. all top-level context URIs in the response
are ".../domain/example.org"), that seems like a reasonable approach
that the current text permits. It also means that a single canonical
response for /domain/example.org can be generated ahead of time, and
returned to all requestors. What is the concern here regarding
canonicalisation?
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
