[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
- [httpapi] linkset: use of "absolute URIs", corner… Christian Amsüss
- Re: [httpapi] linkset: use of "absolute URIs", co… Erik Wilde
- Re: [httpapi] linkset: use of "absolute URIs", co… Christian Amsüss
- Re: [httpapi] linkset: use of "absolute URIs", co… Erik Wilde