Adding missing connector 'and'

Co-authored-by: Christoph Braun <braun@kit.edu>

Author: csarven

index.html

@@ -1074,7 +1074,7 @@ <h3 property="schema:name">Security Considerations</h3>
                   <p id="consider-provenance-accountability">Implementations that want to allow a class of write or control operations on resources are encouraged to require agents to be authenticated, e.g., for purposes of provenance or accountability.</p>
                   <p about="" id="consider-client-agnostic-control" rel="spec:advisement" resource="#consider-client-agnostic-control"><span property="spec:statement">Implementations are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to consider scenarios in which Authorizations granting <code>acl:Control</code> are client-agnostic and issuer-agnostic, avoiding inadvertent <a href="#loss-of-control-mitigation" rel="rdfs:seeAlso">loss of control</a> if a client or issuer becomes unavailable or untrustworthy, as well as scenarios in which restricting control access to specific clients or issuers could expose the controller to manipulation through a malicious client or issuer.</span></p>
                   <p about="" id="consider-condition-legacy" rel="spec:advisement" resource="#consider-condition-legacy"><span property="spec:statement">Implementations are <span rel="spec:advisementLevel" resource="spec:StronglyEncouraged">strongly encouraged</span> to be aware that Authorizations including <code>acl:condition</code> evaluated by a server without condition support could result in access rights broader than those intended by the original Authorization. Similarly, clients that do not support a condition type will process the Authorization without evaluating that condition. System operators are strongly encouraged to verify Authorizations with conditions against the condition capabilities of the server prior to deployment.</span></p>
-                  <p about="" id="consider-condition-control" rel="spec:advisement" resource="#consider-condition-control"><span property="spec:statement">Implementations are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to consider granting <code>acl:Control</code> access using an <code>acl:Condition</code> to clients known to support conditions, to preserve Authorization integrity. to reduce the risk of inadvertent condition removal by condition-unaware clients.</span></p>
+                  <p about="" id="consider-condition-control" rel="spec:advisement" resource="#consider-condition-control"><span property="spec:statement">Implementations are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to consider granting <code>acl:Control</code> access using an <code>acl:Condition</code> to clients known to support conditions, to preserve Authorization integrity, and to reduce the risk of inadvertent condition removal by condition-unaware clients.</span></p>
                 </div>
               </section>
               <section id="privacy-considerations" inlist="" rel="schema:hasPart" resource="#privacy-considerations" typeof="spec:PrivacyConsiderations">