Script updating gh-pages from 17e8ac4. [ci skip]

ietf-scitt · Jul 10, 2023 · a30d1af · a30d1af
1 parent a138a0e
commit a30d1af
Show file tree

Hide file tree

Showing 2 changed files with 3 additions and 3 deletions.
diff --git a/generic-structures/draft-steele-cose-merkle-tree-proofs.html b/generic-structures/draft-steele-cose-merkle-tree-proofs.html
@@ -1440,7 +1440,7 @@ <h2 id="name-proof-types-in-cbor">
 <p id="section-4-2">Implementers should not expect interoperability accross "verifiable data structures",
 but they should expect conceptually similar properties across registered proof types.<a href="#section-4-2" class="pilcrow">¶</a></p>
 <p id="section-4-3">For example, 2 different merkle tree based verifiable data structures might both support proofs of inclusion.
-Protocols requireing proof of inclusion ought to be able to preserve their functionality,
+Protocols requiring proof of inclusion ought to be able to preserve their functionality,
 while switching from one verifiable data structure to another, so long as both structures upport the same proof types.<a href="#section-4-3" class="pilcrow">¶</a></p>
 <div id="sec-verifiable-data-structure-proof-types">
 <section id="section-4.1">

diff --git a/generic-structures/draft-steele-cose-merkle-tree-proofs.txt b/generic-structures/draft-steele-cose-merkle-tree-proofs.txt
@@ -210,8 +210,8 @@ Table of Contents
    properties across registered proof types.
 
    For example, 2 different merkle tree based verifiable data structures
-   might both support proofs of inclusion.  Protocols requireing proof
-   of inclusion ought to be able to preserve their functionality, while
+   might both support proofs of inclusion.  Protocols requiring proof of
+   inclusion ought to be able to preserve their functionality, while
    switching from one verifiable data structure to another, so long as
    both structures upport the same proof types.