Replace 'absolute URI' with 'URI'

[acoburn]

Resolves #46

The Authentication and Authorization sections of the specification make use of the phrase "absolute URI", but RFC 3986, section 4.3 defines an absolute URI as a URI without a fragment identifier. It was not the intention of the author to exclude URIs that contain fragment identifiers; instead, the goal was to exclude relative URI references, since these values will generally cross domain and/or security boundaries and so any ambiguity would be problematic. The terminology "URI" implies that these values are not relative URI references.

---

Preview | Diff

[TallTed]

Is there a reason not to forbid "relative URIs", which is absolutely clear, rather than mandating "URIs", which I do not find to imply "non-relative URIs" and which could also be the mandate, i.e., "non-relative URIs", if there is some proof that relative URIs are actually harmful?

In my world, a great many documents are authored using relative URIs, because they are trivially movable from internal deployment (for testing, etc., by company entities) to external deployment (for consumption by the general public). This prohibition seems likely to be problematic for this workflow.

[acoburn]

The rationale for non-relative URIs in these particular cases is that these identifiers are used for crossing security domains. E.g. an access token with a globally unique issuer or the location of an authorization server. In these cases, global uniqueness is important.

This change does not affect URIs in documents.

[TallTed]

OK, so given that I accept this prohibition in "non-documents" (though I think many documents are included under that label, e.g., *.ttl, *.jsonld), what about making the requirement be non-relative URIs rather than URIs?

[pchampin]

@TallTed, the problem that I raised in #46 and that this PR aims to address is that the common usage of terms like "URI", "absolute URI", "relative URI" is not aligned with RFC3986...

Consider the following examples:
A: https://example.org/foo/bar#baz
B: https://example.org/foo/bar
C: ../foo/bar

Many people would consider that A, B and C are all "URIs", A and B being "absolute URIs" and C being a "relative URI". Unfortunately, that's inaccurate.

According to Section 4. Usage of RFC3986, only A and B are "URIs", and C is a "relative reference (to a URI)". The term encompassing all three A, B and C is "URI Reference". Note that (contrary to common usage) there is no such thing as "relative URI" in the RFC (only references can be relative)... but there is a notion of "absolute URI", which only covers B in my example, because "absolute URIs" are URIs without a fragment (don't ask me!).

I don't expect our readers to be aware of the subtle oddities of the terminology of RFC3986, nor do I believe that we should make this a requirement to read the LWS spec. But I think that we should at least not use a term that is defined in RFC3986 with a meaning different from what we want to convey (in this case, "absolute URI").

[pchampin]

I suggest to accept this PR, and complement it with an entry in the "terminology" section to clarify what we mean by URI (i.e., recall what it means in RFC3986)

Proposal:

URI: this specification makes use of the notion of URI as defined by [[RFC3986]]. Recall that, according the RFC, URIs can not be relative: https://example.org/foo/bar#baz and https://example.org/foo/bar are URIs, but ../foo/bar is not. The latter is, strictly speaking, a relative reference, and the term encompassing both URIs and relative references is URI references.

[ebremer]

lgtm