[httpapi] linkset: use of "absolute URIs", corner cases, formatting

Christian Amsüss <christian@amsuess.com> Mon, 14 June 2021 14:14 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: httpapi@ietfa.amsl.com
Delivered-To: httpapi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB0B3A25C4; Mon, 14 Jun 2021 07:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddCgNXVzQdUI; Mon, 14 Jun 2021 07:14:06 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F1D3A25C0; Mon, 14 Jun 2021 07:14:02 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 105204007A; Mon, 14 Jun 2021 16:13:55 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 020D1D7; Mon, 14 Jun 2021 16:13:54 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:d2c7:a3e0:d816:8e87]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9D3467D; Mon, 14 Jun 2021 16:13:53 +0200 (CEST)
Received: (nullmailer pid 426387 invoked by uid 1000); Mon, 14 Jun 2021 14:13:53 -0000
Date: Mon, 14 Jun 2021 16:13:53 +0200
From: Christian Amsüss <christian@amsuess.com>
To: draft-ietf-httpapi-linkset@ietf.org
Cc: httpapi@ietf.org
Message-ID: <YMdkITTB4NeAqnRC@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="vnKBw41Cc9jZJWZz"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/gpGk29iXZsxD47FvVIxLvWtIu-o>
Subject: [httpapi] linkset: use of "absolute URIs", corner cases, formatting
X-BeenThere: httpapi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Building Blocks for HTTP APIs <httpapi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/httpapi>, <mailto:httpapi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/httpapi/>
List-Post: <mailto:httpapi@ietf.org>
List-Help: <mailto:httpapi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpapi>, <mailto:httpapi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jun 2021 14:14:09 -0000

Hello linkset authors,

I've had a read through draft-ietf-httpapi-linkset-02 in the context of
CoRE work on embedded-usable resource metadata (in the course of which I
spent quite some time battling RFC6690).

Absolute URIs
-------------

In the current draft I noticed the term "absolute URIs" used in several
occasions to refer to URI references that are only URIs and not relative
references. It is regrettable that RFC3986 provides no good language to
keep these apart, or (more precisely) that it has become commonplace to
use the term "URI" also for URI references. The term "Absolute URI",
somewhat counter-intuitively, does not refer to a URI that is not
relative, but more strictly to one that has no fragment identifier.
(Makes sense for how it's used in HTTP requests, but not in links).

Figure 2 gives a concrete example of a URI that is a (full) URI but not
an absolute URI:  https://example.org/resource1#comment=1

I therefore suggest that all references to "absolute URIs (as defined in
Section 4.3 of [RFC3986])" be replaced with text that conveys the intent
of having a URI and not a relative reference.

Multi-rel links
---------------

Links do occasionally (albeit in what I assume to be a deprecatd
corner case) use multiple rel values in combination; rel="alternate
stylesheet" is the typical legacy example (where the combination of rels
has meaning), rel="start http://example.net/relation/other" is what
RFC8288 gives.

I understand 4.2.2 "For each distinct relation type" to refer to each
type individually (with white-space splitting of the Link header's rel
value) -- but then, which of these do the target attribtues get attached
to? The first? All?

(And what does that mean for round-tripping?)

Empty link params
-----------------

The RFC8288 ABNF describes link-params as having an optional value
token; for example, in CoAP we often annotate observable resources as
</status>;obs;ct=0 where the obs attribute has no value.

RFC8288 equates these to empty-string values in its appendix B.3 items 7
and 8.

As this document is quite explicit about the "if absent, set as
empty-string" behavior on href and anchor, it may be helpful to point
this out in 4.2.4.3 "Extension Target Attributes".

Round-tripping and sequence
---------------------------

Round-tripping between JSON and Link header format may part of the
sequence of links as well as target attributes; the partial ordering of
elemnts of the same anchor and relation is preserved, as is the partial
ordering of values to like-named attributes, but the order between
different attributes is lost to JSON objects' unordered nature and to
the aggregation of alike keys. (For example, bot ;foo=bar;a=b;foo=baz
and ;foo=bar;foo=baz;a=b become the same JSON even if the JSON processor
could preserve the sequence of object attributes, and the same as
;a=b;foo=bar;foo=baz if not).

This is consistent with my understanding of link equivalence, but may be
worth pointing out.

rel=linkset vs. more generic "see also"
---------------------------------------

The to-be-defined linkset relation does, by its description,
characterize the target as "providing more information about" the
context, but does so in a very technology specific way.

I'm unaware of any registered "see-also" relation (but frequently see
rdfs:seeAlso in the semantic web world), but such a generic link would
IMO present the same information more cleanly if accompanied by a
;type="application/linkset" or ;type="application/linkset+json"
attribute -- especially given that the type information is already
present in the example.

Please consider a more generic name. The IANA description can even stay
as it is, or be generalized a bit (from "set of links" to "metadata").

Formatting
----------

In an unrelated note, you may want to check the figure with the German
"nächstes Kapitel" which shows as "nachstes Kapitel" in the rendered
text. The figure may need to be declared as artwork for the character to
be shown correctly after rendering through xml2rfc.


Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom