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

[Erik Wilde <[e-mail]>]

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:[e-mail] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |