Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authoritative Contained Resource Data #352

Merged
merged 24 commits into from
Dec 15, 2021
Merged

Authoritative Contained Resource Data #352

Changes from 23 commits
Commits
Show all changes
24 commits
Select commit Hold shift + click to select a range
f07d1ee
Add dc-terms iana-media-types to References
csarven Nov 17, 2021
de6eb1c
Add definition for authoritative-information
csarven Nov 17, 2021
0d10299
Add dcterms and stat to namespaces
csarven Nov 17, 2021
2e70f8f
Add section on Authoritative Resource Data
csarven Nov 17, 2021
294245e
Add reference to RFC 6570
csarven Nov 23, 2021
5ea32a4
Update authoritative resource type. Refer to RFC 6570
csarven Nov 23, 2021
630861c
Minor
csarven Nov 23, 2021
c0d8d4c
Update inapplicable condition and logically-part-of note
csarven Nov 23, 2021
91a77cb
Minor
csarven Nov 23, 2021
f599dd5
Update authoritative-resource-data-considerations
csarven Dec 3, 2021
4734bbf
Mention date as part of dcterms:modified
csarven Dec 3, 2021
98d2db4
Remove advisement on omitting data from unauthorized agents
csarven Dec 3, 2021
4eaf345
Add determining server-container-last-modified
csarven Dec 3, 2021
f2c8c8b
Remove contained-resource-state-cascading in favour of server-contain…
csarven Dec 3, 2021
30eee02
Add dcterms-modified-corresponds-last-modified
csarven Dec 3, 2021
1727bb8
Use resource-metadata instead of authoritative-information
csarven Dec 5, 2021
64d4841
Minor
csarven Dec 5, 2021
0b6db97
Add contained-resource-metadata-statements as Collection
csarven Dec 5, 2021
64e3738
Update protocol.html
csarven Dec 5, 2021
a1222a2
Update protocol.html
csarven Dec 5, 2021
746520d
Constrain server-container-last-modified. Add container-last-modified…
csarven Dec 15, 2021
c33e386
Minor
csarven Dec 15, 2021
4ebdc4d
Merge branch 'main' into feature/authoritative-contained-resource-data
csarven Dec 15, 2021
29b7094
Use 'SHOULD, unless' for server-contained-resource-metadata
csarven Dec 15, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 68 additions & 3 deletions protocol.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -161,7 +161,7 @@
<main>
<article about="" typeof="schema:Article doap:Specification">
<h1 property="schema:name">Solid Protocol</h1>
<h2>Editor’s Draft, 2021-12-14</h2>
<h2>Editor’s Draft, 2021-12-15</h2>

<dl id="document-identifier">
<dt>This version</dt>
Expand Down Expand Up @@ -192,7 +192,7 @@ <h2>Editor’s Draft, 2021-12-14</h2>

<dl id="document-modified">
<dt>Modified</dt>
<dd><time content="2021-12-14T00:00:00Z" datatype="xsd:dateTime" datetime="2021-12-14T00:00:00Z" property="schema:dateModified">2021-12-14</time></dd>
<dd><time content="2021-12-15T00:00:00Z" datatype="xsd:dateTime" datetime="2021-12-15T00:00:00Z" property="schema:dateModified">2021-12-15</time></dd>
</dl>

<dl id="document-repository">
Expand Down Expand Up @@ -350,7 +350,7 @@ <h3 property="schema:name skos:prefLabel">Terminology</h3>

<p property="skos:definition">The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification.</p>

<span rel="skos:hasTopConcept"><span resource="#data-pod"></span><span resource="#solid-app"></span><span resource="#uri"></span><span resource="#resource"></span><span resource="#container-resource"></span><span resource="#root-container"></span><span resource="#agent"></span><span resource="#owner"></span><span resource="#origin"></span><span resource="#read-operation"></span><span resource="#write-operation"></span><span resource="#append-operation"></span></span>
<span rel="skos:hasTopConcept"><span resource="#data-pod"></span><span resource="#solid-app"></span><span resource="#uri"></span><span resource="#resource"></span><span resource="#container-resource"></span><span resource="#root-container"></span><span resource="#resource-metadata"></span><span resource="#agent"></span><span resource="#owner"></span><span resource="#origin"></span><span resource="#read-operation"></span><span resource="#write-operation"></span><span resource="#append-operation"></span></span>

<dl>
<dt about="#data-pod" property="skos:prefLabel" typeof="skos:Concept"><dfn id="data-pod">data pod</dfn></dt>
Expand All @@ -371,6 +371,9 @@ <h3 property="schema:name skos:prefLabel">Terminology</h3>
<dt about="#root-container" property="skos:prefLabel" typeof="skos:Concept"><dfn id="root-container">root container</dfn></dt>
<dd about="#root-container" property="skos:definition">A root container is a container resource that is at the highest level of the collection hierarchy.</dd>

<dt about="#resource-metadata" property="skos:prefLabel" typeof="skos:Concept"><dfn id="resource-metadata">resource metadata</dfn></dt>
<dd about="#resource-metadata" property="skos:definition">Resource metadata encompasses data about resources described by means of RDF statements [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>].</dd>

<dt about="#agent" property="skos:prefLabel" typeof="skos:Concept"><dfn id="agent">agent</dfn></dt>
<dd about="#agent" property="skos:definition">An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [<cite><a class="bibref" href="#bib-webid">WEBID</a></cite>].</dd>

Expand Down Expand Up @@ -430,6 +433,16 @@ <h3 property="schema:name">Namespaces</h3>
<td>http://www.w3.org/ns/auth/acl#</td>
<td>ACL Ontology</td>
</tr>
<tr>
<td>dcterms</td>
<td>http://purl.org/dc/terms/</td>
<td>[<cite><a class="bibref" href="#bib-dc-terms">DC-TERMS</a></cite>]</td>
</tr>
<tr>
<td>stat</td>
<td>http://www.w3.org/ns/posix/stat</td>
<td>POSIX File Status</td>
</tr>
</tbody>
</table>
</div>
Expand Down Expand Up @@ -561,6 +574,51 @@ <h3 property="schema:name">Resource Containment</h3>
<p id="server-hierarchical-containment">There is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy. [<a href="https://github.com/solid/specification/issues/98#issuecomment-547506617" rel="cito:citesAsSourceDocument">Source</a>]. It follows that all resources are discoverable from a container and that it is not possible to create orphan resources. [<a href="https://github.com/solid/specification/issues/97#issuecomment-547459396" rel="cito:citesAsSourceDocument">Source</a>]</p>

<p><span about="" id="server-basic-container" rel="spec:requirement" resource="#server-basic-container"><span property="spec:statement">The representation and behaviour of containers in Solid corresponds to LDP Basic Container and <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> be supported by <span rel="spec:requirementSubject" resource="spec:Server">server</span>.</span></span> [<a href="https://github.com/solid/specification/issues/47#issuecomment-561675764" rel="cito:citesAsSourceDocument">Source</a>]</p>

<p id="server-container-last-modified">Servers can determine the value of the HTTP <code>Last-Modified</code> header field in response to <code>HEAD</code> and <code>GET</code> requests targeting a container based on changes to containment triples.</p>

<div class="note" id="" inlist="container-last-modified-comparison" rel="schema:hasPart" resource="#container-last-modified-comparison">
<h4 property="schema:name"><span>Note</span>: Container Last-Modified Comparison</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>The <code>Last-Modified</code> of a container will not change when other parts of the container changes. This is to avoid instant propagation of changes all the way to the root container. As <code>Last-Modified</code> cannot be reliably used to check whether the container representation has changed in any way. In future versions of this specification, this design may be revisited.</p>
</div>
</div>

<section id="contained-resource-metadata" inlist="" rel="schema:hasPart" resource="#contained-resource-metadata">
<h4 property="schema:name">Contained Resource Metadata</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>Container descriptions are not limited to containment triples. To further support client navigation and application interaction, servers can include <a href="#resource-metadata">resource metadata</a> about contained resources as part of the container description, as described below.</p>

<p><span about="" id="server-contained-resource-metadata" rel="spec:requirement" resource="#server-contained-resource-metadata"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include <a href="#contained-resource-metadata-statements" rel="rdfs:seeAlso">resource metadata about contained resources</a> as part of the container description, unless that information is inapplicable to the server.</span></span></p>

<p id="contained-resource-metadata-statements" about="#contained-resource-metadata-statements" typeof="skos:Collection"><span property="skos:prefLabel">Contained resource metadata statements</span> include the properties:</p>

<dl about="#contained-resource-metadata-statements" rel="skos:member">
<dt about="#contained-resource-metadata-rdf-type" id="contained-resource-metadata-rdf-type" property="skos:prefLabel"><code>rdf:type</code></dt>
<dd about="#contained-resource-metadata-rdf-type" property="skos:definition">A class whose URI is the expansion of the <em>URI Template</em> [<cite><a class="bibref" href="#bib-rfc6570">RFC6570</a></cite>] <code>http://www.w3.org/ns/iana/media-types/{+iana-media-type}#Resource</code>, where <code>iana-media-type</code> corresponds to a value from the IANA Media Types [<cite><a class="bibref" href="#bib-iana-media-types">IANA-MEDIA-TYPES</a></cite>].</dd>
<dt about="#contained-resource-metadata-stat-size" id="contained-resource-metadata-stat-size" property="skos:prefLabel"><code>stat:size</code></dt>
<dd about="#contained-resource-metadata-stat-size" property="skos:definition">A non-negative integer giving the size of the resource in bytes.</dd>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This item in particular should be discussed in the security considerations section

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you consider stat:size (I assume that's what your comment is referring to - GitHub UI trips me up sometimes) to more of a concern than the others?

Had this text earlier in the Note #contained-resource-metadata-considerations :

Servers are encouraged to consider omitting authoritative data about a contained resource when an agent is unauthorized to read the contained resource.

Removed it as per Kjetil's suggestion: #352 (comment)

Can revive and put it under #security-considerations but note that it may be equivalent / already captured by:

Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.

If you'd like more specific considerations that should be mentioned in there, we can do that as well. Have something in mind?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Provided that a server can choose to omit this data (under the "inapplicability" clause), this is fine as-is.

Knowing the size of a file that one may not otherwise have access to read, can be extremely useful data when looking to exploit weaknesses in a server. I would have serious reservations about including that information on a Storage that holds sensitive personal data.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I believe that since we do know that we cannot have a server check the authz of every child resource, then is inappropriate to leave it as an implementation detail, we'd need to specify a concrete mechanism. I think it would be better for this to be a SHOULD, as per RFC2119, but for now, it seems that it could be left out under the inapplicability clause.

<dt about="#contained-resource-metadata-dcterms-modified" id="contained-resource-metadata-dcterms-modified" property="skos:prefLabel"><code>dcterms:modified</code></dt>
<dd about="#contained-resource-metadata-dcterms-modified" property="skos:definition">The date and time when the resource was last modified.</dd>
Copy link
Member

@acoburn acoburn Dec 7, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming that a server provides a Last-Modified header and assuming that we do not want to break how caching works for browsers, I do not see how this (dcterms:modified or stat:mtime) can be implemented without causing a cascade of updates to the root of a Storage.

For example, consider a resource at /lvl-1/lvl-2/foo.ttl with the following response headers:

Last-Modified: Sun, 05 Dec 2021 17:45:02 GMT
ETag:  "abcd"

The container at /lvl-1/lvl-2/ has the following headers:

Last-Modified: Tue, 07 Dec 2021 12:23:15 GMT
ETag: "1234"

That container would include the following triples:

</lvl-1/lvl-2/> 
    dcterms:modified "2021-12-07T12:23:15Z"^^xsd:dateTime ;
    ldp:contains </lvl-1/lvl-2/foo.ttl> .
</lvl-1/lvl-2/foo.ttl>
    dcterms:modified "2021-12-05T17:45:02Z"^^xsd:dateTime .

The container at /lvl-1/ has the following headers:

Last-Modified: Tue, 07 Dec 2021 19:37:22 GMT
ETag: "zyxw"

And the following body:

</lvl-1/> 
    dcterms:modified "2021-12-07T19:37:22Z"^^xsd:dateTime ;
    ldp:contains </lvl-1/lvl-2/> .
</lvl-1/lvl-2/>
    dcterms:modified "2021-12-07T12:23:15Z"^^xsd:dateTime .

Now consider that a client adds a triple to /lvl-1/lvl-2/foo.ttl. The result will lead to the Last-Modified being updated on /lvl-1/lvl-2/foo.ttl. The content of that resource has changed, so the ETag header also changes.

Because the Last-Modified header changes, the representation of /lvl-1/lvl-2/ now also changes to reflect the new status of the contained resource. As a consequence, and in order to ensure that clients receive the latest version of /lvl-1/lvl-2/, the Last-Modified and ETag headers of this container resource must change.

Because the Last-Modified header for /lvl-1/lvl-2/ changes, the representation of /lvl-1/ also needs to change, which leads to a further cascade of changes to the root of the storage.

There are three ways around this, as I see it:

  • Do not include the dcterms:modified or stat:mtime triples (i.e. ignore this part of the spec)
  • Don't worry about breaking how browser caching works (i.e. ignoring app/client needs)
  • Put this data in a separate (auxiliary) resource that doesn't lead to a cascade of change.

I prefer the third option because it makes it possible to include this data without breaking how browsers interact with HTTP resources, but absent that approach, the only route forward I see (while staying roughly in line with this spec) is to simply not include the modified time of contained resources (again, arguing "inapplicability").

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, @acoburn , I have been arguing the same, an auxiliary resource solves all problems, it can represent the entirety of the resource (and it makes sense to add data for each representation too if needed), avoids cascading problems, can be subject to separate authorization, can be used to track any changes and should be at least as easy to implement.

However, we haven't been able to find consensus around that for 0.9, so indeed, the result is that these data may be stale when conditional requests are used. I disagree with the conclusion, but as the RFC7232 is fairly vague at this point, I have chosen to accept it for 0.9, sincerely hoping we can revisit for 1.0.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the Last-Modified header changes, the representation of /lvl-1/lvl-2/ now also changes to reflect the new status of the contained resource.

While the representation data of /lvl-1/lvl-2/ changes because of the dcterms:modified value of /lvl-1/lvl-2/foo.ttl , the Last-Modified header of /lvl-1/lvl-2/ need not change - nor prohibited - as there were no changes to the containment triples ( #server-container-last-modified ).

A recommendation (or advisement) along the following lines may be necessary:

When the resource metadata of an existing contained resource changes, the server MUST send a weak entity-tag when responding to container’s request URI.

I want to mention again that the requirements introduced by this PR does not expect a container (/lvl-1/lvl-2/) to include resource metadata about itself (</lvl-1/lvl-2/> dcterms:modified "2021-12-07T12:23:15Z"^^xsd:dateTime .). (I don't care if that's not the point - it easily introduces complications/assumptions to the discussion that we are better off without.) And again, if resource metadata about the container itself is desired - I may have missed the discussion that calls for it - the specification should needs to say so because both the generation and protection of those resource metadata needs to apply. On a related note:

When a server plans to include resource metadata about the container in the response of the same container, the server should determine the Last-Modified header value as a regular change to the representation data. (It can send a strong entity-tag as usual.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does mean that apps/users will see stale data. From an impl perspective (given the choice), I would rather not provide the data than provide it in a way that confuses users.

I am really trying to be constructive here, but I don't see how this is implementable, given this text

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As it stands, the Protocol uses the same requirement levels as in the RFC for Last-Modified and ETag headers. Servers might not include either Last-Modified or ETag headers, and so clients can't absolutely rely on them for being there.

That aside,

https://datatracker.ietf.org/doc/html/rfc7232#section-2.4 and https://datatracker.ietf.org/doc/html/rfc7232#section-6 suggests that headers with entity-tags will have higher precedence.

Server needs to enable the use of conditional requests so that client can eventually get a 200/304/412 or whatever.

Perhaps I'm missing something here but as mentioned in previous comment, I don't see a staleness issue around entity-tags.

If a client is only making decisions with Last-Modified/If-*-Since (when Last-Modified is provided by the server), then the representation metadata in the response will not help them to differentiate between a change to containment triples or any change to the representation. In this particular scenario, client has to make a GET request on the container.

We can certainly revisit that in 1.0.

For now, I suggest to add the following and go ahead with 0.9:

When the resource metadata of an existing contained resource changes, the server MUST send a weak entity-tag when responding to container’s request URI.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the entity tag changes from x to y, there is no issue, but that is orthogonal to the weakness indicator

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good. Then in what case would it not change from x to y?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any time the representation changes, the ETag changes. There is no argument about that. I am only responding to the proposed requirement to use weak ETags. And to be clear, I am not opposed to using weak ETags, but we can't claim that weak ETags will solve this issue

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The weak entity-tag is suggested because strong entity-tag wouldn't be correct when only the resource metadata changes. All meanwhile allowing the client to make conditional requests. Right at this second, I don't have a strong opinion on adding that requirement because I do think it comes directly from the RFC but it may be reasonable to mention.

That aside, I acknowledge that there is (always) room to discuss/work this out further but it doesn't need to be a blocker for 0.9. (We mark handful of stuff to be revisited for 1.0, and I don't see why it can't be done here as well.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

746520d

<dt about="#contained-resource-metadata-stat-mtime" id="contained-resource-metadata-stat-mtime" property="skos:prefLabel"><code>stat:mtime</code></dt>
<dd about="#contained-resource-metadata-stat-mtime" property="skos:definition">The Unix time when the resource was last modified.</dd>
</dl>
RubenVerborgh marked this conversation as resolved.
Show resolved Hide resolved

<p id="dcterms-modified-corresponds-last-modified">The <code>dcterms:modified</code> value of a contained resource corresponds with the <code>Last-Modified</code> header value of the contained resource. If one were to perform <code>HEAD</code> or <code>GET</code> requests on the URI of the contained resource at the time of the HTTP message’s generation, then a response with the <code>200</code> status code including the <code>Last-Modified</code> header would indicate the same date and time.</p>
csarven marked this conversation as resolved.
Show resolved Hide resolved

<div class="note" id="contained-resource-metadata-considerations" inlist="" rel="schema:hasPart" resource="#contained-resource-metadata-considerations">
<h5 property="schema:name"><span>Note</span>: Contained Resource Metadata Considerations</h5>
<div datatype="rdf:HTML" property="schema:description">
<p>The generation of contained resource metadata may be inapplicable to some servers, for example, when that information does not exist or is expensive to determine.</p>
</div>
</div>

<p>Contained resource metadata is <a href="#server-protect-contained-resource-metadata" rel="cito:discusses">protected by the server</a>.</p>

<p>[<a href="https://github.com/solid/specification/issues/227" rel="cito:citesAsSourceDocument">Source</a>]
[<a href="https://github.com/solid/specification/issues/343" rel="cito:citesAsSourceDocument">Source</a>] [<a href="https://github.com/solid/specification/pull/352" rel="cito:citesAsSourceDocument">Source</a>]</p>
</div>
</section>
</div>
</section>

Expand Down Expand Up @@ -710,6 +768,8 @@ <h3 property="schema:name">Writing Resources</h3>

<p><span about="" id="server-protect-containment" rel="spec:requirement" resource="#server-protect-containment"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST-NOT">MUST NOT</span> allow HTTP <code>PUT</code> or <code>PATCH</code> on a container to update its containment triples; if the server receives such a request, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid/specification/issues/40#issuecomment-573358652" rel="cito:citesAsSourceDocument">Source</a>]</p>

<p><span about="" id="server-protect-contained-resource-metadata" rel="spec:requirement" resource="#server-protect-contained-resource-metadata"><span property="spec:statement"><span rel="spec:requirementSubject" resource="spec:Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST-NOT">MUST NOT</span> allow HTTP <code>POST</code>, <code>PUT</code> and <code>PATCH</code> to update a container’s <a href="#contained-resource-metadata-statements">resource metadata statements</a>; if the server receives such a request, it MUST respond with a <code>409</code> status code.</span></span> [<a href="https://github.com/solid/specification/issues/227#issuecomment-919312592" rel="cito:citesAsSourceDocument">Source</a>]</p>

<div class="note" id="conditional-update" inlist="" rel="schema:hasPart" resource="#conditional-update">
<h4 property="schema:name"><span>Note</span>: Conditional Update</h4>
<div datatype="rdf:HTML" property="schema:description">
Expand Down Expand Up @@ -1054,8 +1114,12 @@ <h2 property="schema:name">References</h2>
<h3 property="schema:name">Normative References</h3>
<div datatype="rdf:HTML" property="schema:description">
<dl class="bibliography" resource="">
<dt id="bib-dc-terms">[DC-TERMS]</dt>
<dd><a href="http://dublincore.org/documents/2010/10/11/dcmi-terms/" rel="cito:citesAsAuthority"><cite>Dublin Core Metadata Terms, version 1.1</cite></a>. DCMI Usage Board. DCMI. 11 October 2010. DCMI Recommendation. URL: <a href="http://dublincore.org/documents/2010/10/11/dcmi-terms/">http://dublincore.org/documents/2010/10/11/dcmi-terms/</a></dd>
<dt id="bib-fetch">[FETCH]</dt>
<dd><a href="https://fetch.spec.whatwg.org/" rel="cito:citesAsAuthority"><cite>Fetch Standard</cite></a>. Anne van Kesteren. WHATWG. Living Standard. URL: <a href="https://fetch.spec.whatwg.org/">https://fetch.spec.whatwg.org/</a></dd>
<dt id="bib-iana-media-types">[IANA-MEDIA-TYPES]</dt>
<dd><a href="https://www.iana.org/assignments/media-types/" rel="cito:citesAsAuthority"><cite>Media Types</cite></a>. IANA. URL: <a href="https://www.iana.org/assignments/media-types/">https://www.iana.org/assignments/media-types/</a></dd>
<dt id="bib-json-ld11">[JSON-LD11]</dt>
<dd><a href="https://www.w3.org/TR/json-ld11/" rel="cito:citesAsAuthority"><cite>JSON-LD 1.1</cite></a>. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: <a href="https://www.w3.org/TR/json-ld11/">https://www.w3.org/TR/json-ld11/</a></dd>
<dt id="bib-ldn">[LDN]</dt>
Expand All @@ -1080,6 +1144,7 @@ <h3 property="schema:name">Normative References</h3>
<dd><a href="https://datatracker.ietf.org/doc/html/rfc6454" rel="cito:citesAsAuthority"><cite>The Web Origin Concept</cite></a>. A. Barth. IETF. December 2011. Proposed Standard. URL: <a href="https://datatracker.ietf.org/doc/html/rfc6454">https://datatracker.ietf.org/doc/html/rfc6454</a></dd>
<dt id="bib-rfc6455">[RFC6455]</dt>
<dd><a href="https://datatracker.ietf.org/doc/html/rfc6455" rel="cito:citesAsAuthority"><cite>The WebSocket Protocol</cite></a>. I. Fette; A. Melnikov. IETF. December 2011. Proposed Standard. URL: <a href="https://datatracker.ietf.org/doc/html/rfc6455">https://datatracker.ietf.org/doc/html/rfc6455</a></dd>
<dt id="bib-rfc6570">[RFC6570]</dt><dd><a href="https://www.rfc-editor.org/rfc/rfc6570" rel="cito:citesAsAuthority"><cite>URI Template</cite></a>. J. Gregorio; R. Fielding; M. Hadley; M. Nottingham; D. Orchard. IETF. March 2012. Proposed Standard. URL: <a href="https://www.rfc-editor.org/rfc/rfc6570">https://www.rfc-editor.org/rfc/rfc6570</a></dd>
<dt id="bib-rfc6892">[RFC6892]</dt>
<dd><a href="https://datatracker.ietf.org/doc/html/rfc6892" rel="cito:citesAsAuthority"><cite>The 'describes' Link Relation Type</cite></a>. E. Wilde. IETF. March 2013. Informational. URL: <a href="https://datatracker.ietf.org/doc/html/rfc6892">https://datatracker.ietf.org/doc/html/rfc6892</a></dd>
<dt id="bib-rfc7230">[RFC7230]</dt>
Expand Down