Skip to content

Update conformance model #120

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

Merged
csarven merged 5 commits into from
Dec 5, 2022
Merged

Update conformance model #120

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
dabca8d
Add normative-informative-content
csarven Nov 21, 2022
376684a
Add classes-of-products
csarven Nov 21, 2022
a3e3ce7
Add specification-category
csarven Nov 21, 2022
78ef508
Add interoperability
csarven Nov 21, 2022
b4b4f3f
Add conformance to change-log
csarven Nov 21, 2022
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
48 changes: 46 additions & 2 deletions protocol.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -477,9 +477,52 @@ <h3 property="schema:name skos:prefLabel">Namespaces</h3>
<section id="conformance" inlist="" rel="schema:hasPart" resource="#conformance">
<h3 property="schema:name">Conformance</h3>
<div datatype="rdf:HTML" property="schema:description">
<p>All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.</p>
<p>This section describes the <span about="" rel="spec:conformance" resource="#conformance">conformance model of the Solid Notifications Protocol</span>.</p>

<p>The key words “MUST” and “MUST NOT” are to be interpreted as described in <cite><a href="https://tools.ietf.org/html/bcp14" rel="rdfs:seeAlso">BCP 14</a></cite> [<cite><a class="bibref" href="#bib-rfc2119">RFC2119</a></cite>] [<cite><a class="bibref" href="#bib-rfc8174">RFC8174</a></cite>] when, and only when, they appear in all capitals, as shown here.</p>
<section id="normative-informative-content" inlist="" rel="schema:hasPart" resource="#normative-informative-content">
<h4 property="schema:name">Normative and Informative Content</h4>
<div datatype="rdf:HTML" property="schema:description">
<p id="normative-informative-sections">All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.</p>

<p id="requirement-levels">The key words “<span rel="dcterms:subject" resource="spec:MUST">MUST</span>”, “<span rel="dcterms:subject" resource="spec:MUSTNOT">MUST NOT</span>”, “<span rel="dcterms:subject" resource="spec:SHOULD">SHOULD</span>”, and “<span rel="dcterms:subject" resource="spec:MAY">MAY</span>” are to be interpreted as described in <a href="https://tools.ietf.org/html/bcp14">BCP 14</a> [<cite><a class="bibref" href="#bib-rfc2119">RFC2119</a></cite>] [<cite><a class="bibref" href="#bib-rfc8174">RFC8174</a></cite>] when, and only when, they appear in all capitals, as shown here.</p>

<p id="advisement-levels">The key words “<span rel="dcterms:subject" resource="spec:strongly-encouraged">strongly encouraged</span>”, “<span rel="dcterms:subject" resource="spec:strongly-discouraged">strongly discouraged</span>”, “<span rel="dcterms:subject" resource="spec:encouraged">encouraged</span>", “<span rel="dcterms:subject" resource="spec:discouraged">discouraged</span>", “<span rel="dcterms:subject" resource="spec:can">can</span>", “<span rel="dcterms:subject" resource="spec:cannot">cannot</span>”, “<span rel="dcterms:subject" resource="spec:could">could</span>”, “<span rel="dcterms:subject" resource="spec:could-not">could not</span>”, “<span rel="dcterms:subject" resource="spec:might">might</span>”, and “<span rel="dcterms:subject" resource="spec:might-not">might not</span>” are used for non-normative content.</p>
</div>
</section>

<section id="classes-of-products" inlist="" rel="schema:hasPart" resource="#classes-of-products" typeof="skos:ConceptScheme">
<h4 property="schema:name skos:prefLabel">Classes of Products</h4>
<div datatype="rdf:HTML" property="schema:description">
<p property="skos:definition">The <span about="" rel="spec:classesOfProducts" resource="#classes-of-products">Solid Notifications Protocol</span> identifies the following <cite><a href="https://www.w3.org/TR/qaframe-spec/#cop-def" rel="dcterms:subject" resource="spec:ClassesOfProducts">Classes of Products</a></cite> for conforming implementations. These products are referenced throughout this specification.</p>

<span rel="skos:hasTopConcept"><span resource="#Client"></span><span resource="#NotificationServer"></span><span resource="#ResourceServer"></span></span>

<dl>
<dt about="#Client" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:Consumer" typeof="skos:Concept"><dfn id="Client">Client</dfn></dt>
<dd about="#Client" property="skos:definition">A <em>client</em> that builds on HTTP <cite>client</cite> [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>], [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>], and [<cite><a class="bibref" href="#bib-fetch">FETCH</a></cite>] by defining behaviour in terms of fetching across the platform.</dd>
Copy link
Member

@elf-pavlik elf-pavlik Dec 1, 2022

Choose a reason for hiding this comment

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

I suggest Subscription Client, since in notifications flow the Notifications Receiver can act as a client or as a server, depending on the type of created subscription.

<dt about="#NotificationServer" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="NotificationServer">Notification Server</dfn></dt>
<dd about="#NotificationServer" property="skos:definition">A <em>notification server</em> that builds on HTTP <cite>server</cite> [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>] and [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>].</dd>
Copy link
Member

@elf-pavlik elf-pavlik Dec 1, 2022

Choose a reason for hiding this comment

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

I suggest Subscription Server, since in notifications flow the Notifications Sender can act as a server or as a client depending on the type of created subscription.

<dt about="#ResourceServer" property="skos:prefLabel" rel="skos:relatedMatch" resource="spec:RespondingAgent" typeof="skos:Concept"><dfn id="ResourceServer">Resource Server</dfn></dt>
<dd about="#ResourceServer" property="skos:definition">A <em>resource server</em> that builds on HTTP <cite>server</cite> [<cite><a class="bibref" href="#bib-rfc7230">RFC7230</a></cite>] and [<cite><a class="bibref" href="#bib-rfc7231">RFC7231</a></cite>] by defining media types, HTTP header fields, and the behaviour of resources, as identified by link relations.</dd>
</dl>
</div>
</section>

<section id="specification-category" inlist="" rel="schema:hasPart spec:specificationCategory" resource="#specification-category" typeof="skos:ConceptScheme">
<h4 property="schema:name skos:prefLabel">Specification Category</h4>
<div datatype="rdf:HTML" property="schema:description">
<p property="skos:definition">The <span about="" rel="spec:specificationCategory" resource="#specification-category">Solid Protocol</span> identifies the following <cite><a href="https://www.w3.org/TR/spec-variability/#spec-cat" rel="dcterms:subject" resource="spec:SpecificationCategory">Specification Category</a></cite> to distinguish the types of conformance: <span rel="skos:hasTopConcept" resource="spec:API">API</span>, <span rel="skos:hasTopConcept" resource="spec:NotationSyntax">Notation/syntax</span>, <span rel="skos:hasTopConcept" resource="spec:SetOfEvents">Set of events</span>, <span rel="skos:hasTopConcept" resource="spec:Protocol">Protocol</span>.</p>
</div>
</section>

<section id="interoperability" inlist="" rel="schema:hasPart" resource="#interoperability">
<h4 property="schema:name skos:prefLabel">Interoperability</h4>
<div datatype="rdf:HTML" property="schema:description">
<p id="interoperability-resource-server-client">Interoperability of implementations for <a href="#Client" rel="rdfs:seeAlso">clients</a> and <a href="#ResourceServer" rel="rdfs:seeAlso">resource servers</a> is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to this specification.</p>

<p id="interoperability-notification-server-client">Interoperability of implementations for <a href="#Client" rel="rdfs:seeAlso">clients</a> and <a href="#NotificationServer" rel="rdfs:seeAlso">notification servers</a> is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to this specification.</p>
</div>
</section>
</div>
</section>
</div>
Expand Down Expand Up @@ -933,6 +976,7 @@ <h3 property="schema:name">Changes from notifications-protocol-20220509 to this
<li>Add server notification channel discovery requirements with <code>Link</code> headers: <a href="#server-link-resource-notification-channel"><code>describedby</code></a>, <a href="#server-link-storage-notification-channel"><code>http://www.w3.org/ns/solid/terms#storageDescription</code></a>.</li>
<li>Clarify <a href="#authentication-authorization">authentication and authorization</a> as non-normative and encouragement.</li>
<li>Clarify server notification channel resource requirement using <a href="#server-notification-channel-resource-jsonld-context">JSON-LD <code>@context</code></a>.</li>
<li>Update <a href="#conformance">Conformance</a> to add <a href="#normative-informative-content">Normative and Information Content</a>, <a href="#classes-of-products">Class of Products</a>, <a href="#specification-category">Specification Category</a>, <a href="#interoperability">Interoperability</a>.</li>
</ul>
</div>
</section>
Expand Down