From 6d4adf87105b8a9932a102908ccc3748d220083e Mon Sep 17 00:00:00 2001
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 28 Dec 2023 16:36:13 -0500
Subject: [PATCH 1/2] Add protocol statements related to pub/sub of status
 lists.

---
 common.js  |  7 +++++++
 index.html | 23 ++++++++++++++++-------
 2 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/common.js b/common.js
index b6b87ec..284cb67 100644
--- a/common.js
+++ b/common.js
@@ -83,6 +83,13 @@ var ccg = {
       status: 'CG-DRAFT',
       publisher: 'Credentials Community Group'
     },
+    'OHTTP': {
+      title: 'Oblivious HTTP ',
+      href: 'https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp',
+      authors: ['Martin Thomson', 'Christopher A. Wood'],
+      status: 'Working Group Draft',
+      publisher: 'IETF Oblivious HTTP Application Intermediation'
+    },
     'IPFS': {
       title: 'InterPlanetary File System (IPFS)',
       href: 'https://en.wikipedia.org/wiki/InterPlanetary_File_System',
diff --git a/index.html b/index.html
index 78e4a21..079d703 100644
--- a/index.html
+++ b/index.html
@@ -815,17 +815,26 @@ <h3>Bitstring Expansion Algorithm</h3>
 
   </section>
 
-  <section class="informative">
+  <section class="normative">
     <h2>Media Types</h2>
+
+    <p>
+When publishing status list information, issuers SHOULD publish the status list
+using an HTTPS URL and in a way that makes it not possible to correlate usage
+patterns related to the list. When retrieving status list information, verifiers
+SHOULD retrieve the status list over protocols that guard against access
+pattern correlation, such as Oblivious HTTP [[?OHTTP]].
+    </p>
+
     <p>
-  When dereferencing `statusListCredential`, the content type of the
-  `statusListCredential` might be any media type registered for the purpose of
-  expressing a verifiable credential with one or more proofs.
+When dereferencing `statusListCredential`, the content type of the
+`statusListCredential` might be any media type registered for the purpose of
+expressing a verifiable credential with one or more proofs.
     </p>
     <p>
-  For example, a verifiable credential secured with Data Integrity Proofs might
-  have content type `application/vc+ld+json`, whereas a verifiable credential
-  secured with SD-JWT might have content-type `application/sd-jwt`.
+For example, a verifiable credential secured with Data Integrity Proofs might
+have content type `application/vc+ld+json`, whereas a verifiable credential
+secured with SD-JWT might have content-type `application/sd-jwt`.
     </p>
     <p>
 Some implementations might choose to support less specific media types such as

From 3293cce9f4fa8816db7dc00005c5b1f1fb542eb2 Mon Sep 17 00:00:00 2001
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 29 Dec 2023 19:05:27 -0500
Subject: [PATCH 2/2] Fix grammar in protocol statements.

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
---
 index.html | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/index.html b/index.html
index 079d703..108349a 100644
--- a/index.html
+++ b/index.html
@@ -819,22 +819,22 @@ <h3>Bitstring Expansion Algorithm</h3>
     <h2>Media Types</h2>
 
     <p>
-When publishing status list information, issuers SHOULD publish the status list
-using an HTTPS URL and in a way that makes it not possible to correlate usage
-patterns related to the list. When retrieving status list information, verifiers
-SHOULD retrieve the status list over protocols that guard against access
+<a>Issuers</a> SHOULD publish status list information
+using HTTPS URLs and in ways that minimize possible correlation of usage
+patterns related to the list. <a>Verifiers</a>
+SHOULD retrieve status list information using protocols that guard against access
 pattern correlation, such as Oblivious HTTP [[?OHTTP]].
     </p>
 
     <p>
-When dereferencing `statusListCredential`, the content type of the
+When dereferencing `statusListCredential`, the content of the returned
 `statusListCredential` might be any media type registered for the purpose of
 expressing a verifiable credential with one or more proofs.
     </p>
     <p>
 For example, a verifiable credential secured with Data Integrity Proofs might
-have content type `application/vc+ld+json`, whereas a verifiable credential
-secured with SD-JWT might have content-type `application/sd-jwt`.
+have media type `application/vc+ld+json`, while a verifiable credential
+secured with SD-JWT might have media type `application/sd-jwt`.
     </p>
     <p>
 Some implementations might choose to support less specific media types such as