Script updating gh-pages from cc290c8. [ci skip]

carsten-wglc-2/draft-ietf-core-groupcomm-bis.html

@@ -2155,7 +2155,7 @@ <h4 id="name-client-handling-of-multiple">
 <p id="section-3.1.6-2">For example, if the client sends a group request specifying the Observe option set to 0 (see <span><a href="https://rfc-editor.org/rfc/rfc7641#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>) and this server adds the client to the list of observers for the targeted resource, then the server will send multiple responses as Observe notifications to notify the client of changes to the resource state (see <span><a href="https://rfc-editor.org/rfc/rfc7641#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>). The use of Observe with group communication is discussed in more details in <a href="#sec-observe" class="auto internal xref">Section 3.7</a>. As an alternative example, this server might not implement the optional CoAP message deduplication based on Message ID; or it might be acting out of specification as a malicious, compromised or faulty server.<a href="#section-3.1.6-2" class="pilcrow">¶</a></p>
 <p id="section-3.1.6-3">When this happens, it is up to the specific client implementation to decide at which layer deduplication of responses is performed, or whether it is necessary in an application at all. If the processing of a response is successful, the client delivers the response to the application as usual.<a href="#section-3.1.6-3" class="pilcrow">¶</a></p>
 <p id="section-3.1.6-4">The application itself can be in a good position to decide what to do, depending on the available context information. For instance, it might accept and process all the responses from the same server, even if they are not Observe notifications (i.e., they do not include an Observe option). Alternatively, the application might accept and process only one of those responses, such as the one that is deemed to be the most recent one from that server, e.g., when this can trigger a change of state within the application.<a href="#section-3.1.6-4" class="pilcrow">¶</a></p>
-<p id="section-3.1.6-5">As part of a long exchange between the client and any of the servers in the CoAP group, the responses considered above are examples of the more general concept elaborated in <span><a href="https://datatracker.ietf.org/doc/html/draft-bormann-core-responses-03#section-2" class="relref">Section 2</a> of [<a href="#I-D.bormann-core-responses" class="cite xref">I-D.bormann-core-responses</a>]</span>.<a href="#section-3.1.6-5" class="pilcrow">¶</a></p>
+<p id="section-3.1.6-5">As part of a message exchange between the client and any of the servers in the CoAP group, the multiple responses considered above are examples of the more general concept elaborated in <span><a href="https://datatracker.ietf.org/doc/html/draft-bormann-core-responses-03#section-2" class="relref">Section 2</a> of [<a href="#I-D.bormann-core-responses" class="cite xref">I-D.bormann-core-responses</a>]</span>.<a href="#section-3.1.6-5" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>

carsten-wglc-2/draft-ietf-core-groupcomm-bis.txt

@@ -1232,9 +1232,9 @@ Table of Contents
    to be the most recent one from that server, e.g., when this can
    trigger a change of state within the application.
 
-   As part of a long exchange between the client and any of the servers
-   in the CoAP group, the responses considered above are examples of the
-   more general concept elaborated in Section 2 of
+   As part of a message exchange between the client and any of the
+   servers in the CoAP group, the multiple responses considered above
+   are examples of the more general concept elaborated in Section 2 of
    [I-D.bormann-core-responses].
 
 3.2.  Caching