Re: [httpapi] linkset: use of "absolute URIs", corner cases, formatting
Erik Wilde <erik.wilde@dret.net> Tue, 15 June 2021 07:31 UTC
Return-Path: <erik.wilde@dret.net>
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 70B993A248C; Tue, 15 Jun 2021 00:31:10 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3zObb1yeKr8e; Tue, 15 Jun 2021 00:31:05 -0700 (PDT)
Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 C117D3A2487; Tue, 15 Jun 2021 00:31:05 -0700 (PDT)
Received: from ip5b41ddc0.dynamic.kabel-deutschland.de ([91.65.221.192]:62338 helo=[192.168.178.42]) by postoffice.gristmillmedia.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <erik.wilde@dret.net>) id 1lt3XK-0002jh-EG; Tue, 15 Jun 2021 03:31:02 -0400
To: Christian Amsüss <christian@amsuess.com>, draft-ietf-httpapi-linkset@ietf.org
Cc: httpapi@ietf.org
References: <YMdkITTB4NeAqnRC@hephaistos.amsuess.com>
From: Erik Wilde <erik.wilde@dret.net>
Message-ID: <f3e1df0d-4c3f-db8c-560e-f871e1275bfc@dret.net>
Date: Tue, 15 Jun 2021 09:31:00 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <YMdkITTB4NeAqnRC@hephaistos.amsuess.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dret.net
X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net
X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/DjYgR8qdAx8_by6GhStIFsmuB4o>
Subject: Re: [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: Tue, 15 Jun 2021 07:31:11 -0000
hello christian. thanks for the detailed feedback! On 2021-06-14 16:13, Christian Amsüss wrote: > 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. good point. https://github.com/ietf-wg-httpapi/linkset/issues/17 captures this issue. my proposal is to say "non-relative URI" which seems to be the best option since it says what we mean without conflicting with RFC 3986. please feel free to add your preference to the issue. > 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? RFC 8288 makes it clear that it's simply a syntax variant to list links separately or use the "space-separated shortcut". "The rel parameter can, however, contain multiple link relation types. When this occurs, it establishes multiple links that share the same context, target, and target attributes." this implies that all of the link's data applies to all links established by multiple rel values. do you disagree? > (And what does that mean for round-tripping?) this syntactic variant cannot be round-tripped. which is fine, we certainly don't strive to represent every syntax detail. > 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". this may make sense to add. anybody else having an opinion? if so, please add an issue so that we can track it. thanks! > 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. it seems to me that if we list everything that is not round-tripped, we create a lot of noise and little information. we could add some general language about this in section 4.2, though. if anybody thinks that would add value, please raise an issue. thanks! > 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. it's not "more information about", it's more specifically "a set of web links in which the resource is participating". > 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"). we've discussed this and believe that being more specific about the linked resource providing web links makes sense. we have specific scenarios (section 3) which really are about links, and not just generic "other info about the resource" scenarios. > 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. https://github.com/ietf-wg-httpapi/linkset/commit/19e8c8c26d35391862dddeb3470c1c1755c84381#diff-21c61f895fd508e08595960d4f6f7d351019bc380b60c492530a3a7c4ea58f17 fixes this issue. thanks for your feedback. i have created one issue and have answered the remaining issues inline. if you feel that they do need more discussion, please open issues, so that we can have targeted discussions for each. thanks again and cheers, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret |
- [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