Script updating gh-pages from 5ff3d56. [ci skip]

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

@@ -2218,7 +2218,7 @@ <h5 id="name-etag-option-in-a-group-requ">
 <p id="section-3.2.2.1-3">A server endpoint <span class="bcp14">MUST</span> process an ETag Option in a GET or FETCH group request in the same way it processes an ETag Option for a unicast request.
 A server endpoint that includes an ETag Option in a response to a group request <span class="bcp14">SHOULD</span> construct the ETag Option value in such a way that the value
 will be unique to this particular server with a high probability. This practically prevents a collision of the ETag values from different servers in the same CoAP group and application group, which in turn allows the client to effectively validate a particular response of an origin server. This can be accomplished, for example, by embedding a compact ID (or hash) of the server within the ETag value, where the ID is unique (or unique with a high probability) in the scope of the CoAP/application groups.<a href="#section-3.2.2.1-3" class="pilcrow">¶</a></p>
-<p id="section-3.2.2.1-4">Note: a CoAP server implementation that is unaware of the updates to <span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span> made by this document will expect group requests to never contain an ETag Option (see <span><a href="https://rfc-editor.org/rfc/rfc7252#section-8.2.1" class="relref">Section 8.2.1</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>). Such a server treats an ETag Option in a group request as an unrecognized option per Sections <a href="https://rfc-editor.org/rfc/rfc7252#section-5.4" class="relref">5.4</a> and <a href="https://rfc-editor.org/rfc/rfc7252#section-8.2.1" class="relref">8.2.1</a> of <span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>, causing it to ignore this (elective) ETag Option regardless of its value, and process the request normally as if that ETag Option was not included.<a href="#section-3.2.2.1-4" class="pilcrow">¶</a></p>
+<p id="section-3.2.2.1-4">Note: a CoAP server implementation that is unaware of the updates to <span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span> made by this document will expect group requests to never contain an ETag Option (see <span><a href="https://rfc-editor.org/rfc/rfc7252#section-8.2.1" class="relref">Section 8.2.1</a> of [<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>). Such a server treats an ETag Option in a group request as an unrecognized option per Sections <a href="https://rfc-editor.org/rfc/rfc7252#section-5.4" class="relref">5.4</a> and <a href="https://rfc-editor.org/rfc/rfc7252#section-8.2.1" class="relref">8.2.1</a> of <span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>, causing it to ignore this (elective) ETag Option regardless of its value, and processes the request normally as if that ETag Option was not included.<a href="#section-3.2.2.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 </section>

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

@@ -1361,8 +1361,8 @@ Table of Contents
    contain an ETag Option (see Section 8.2.1 of [RFC7252]).  Such a
    server treats an ETag Option in a group request as an unrecognized
    option per Sections 5.4 and 8.2.1 of [RFC7252], causing it to ignore
-   this (elective) ETag Option regardless of its value, and process the
-   request normally as if that ETag Option was not included.
+   this (elective) ETag Option regardless of its value, and processes
+   the request normally as if that ETag Option was not included.
 
 3.3.  URI Path Selection