Script updating gh-pages from 766dd6d. [ci skip]

draft-ietf-core-groupcomm-proxy.html

@@ -1827,7 +1827,7 @@ <h4 id="name-response-processing-2">
 That is, the client simply specifies the URI for the individual request in the unicast request to the proxy. To this end, the client can specify the URI as a string in the Proxy-Uri Option, or by using the Proxy-Scheme Option together with the Uri-* options. Alternatively, the client can rely on the analogous options defined in <span>[<a href="#I-D.ietf-core-href" class="cite xref">I-D.ietf-core-href</a>]</span>, i.e., on the Proxy-Cri Option conveying a CRI equivalent to the URI, or on the Proxy-Scheme-Number Option together with the Uri-* options. In either case, the client uses the transport protocol that it supports, and has used before, to send the unicast request to the proxy.<a href="#section-5.5.1-2.3.4" class="pilcrow">¶</a></p>
 </li>
           </ol>
-<p id="section-5.5.1-3">As discussed in <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-11#section-3.1.6" class="relref">Section 3.1.6</a> of [<a href="#I-D.ietf-core-groupcomm-bis" class="cite xref">I-D.ietf-core-groupcomm-bis</a>]</span>, it is possible that the client receives multiple responses to the same group request, i.e., with the same Token, from the same origin server. The client normally processes at the CoAP layer each of those responses from the same origin server, and decides at the application layer how to exactly handle them depending on its available context information (see <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-11#section-3.1.6" class="relref">Section 3.1.6</a> of [<a href="#I-D.ietf-core-groupcomm-bis" class="cite xref">I-D.ietf-core-groupcomm-bis</a>]</span>).<a href="#section-5.5.1-3" class="pilcrow">¶</a></p>
+<p id="section-5.5.1-3">As discussed in <span><a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-11#section-3.1.6" class="relref">Section 3.1.6</a> of [<a href="#I-D.ietf-core-groupcomm-bis" class="cite xref">I-D.ietf-core-groupcomm-bis</a>]</span>, it is possible that the client receives multiple responses to the same group request, i.e., with the same Token, from the same origin server. The specific client implementation determines at which layer deduplication of responses is performed, or whether it is necessary in an application at all. If the processing of a response succeeds, then the client delivers the response to the application as usual. Depending on its available context information, the application itself can be in a good position to decide how to handle such responses.<a href="#section-5.5.1-3" class="pilcrow">¶</a></p>
 <p id="section-5.5.1-4">Upon the timeout expiration, i.e., T seconds after having sent the original unicast request to the proxy, the client frees up its local Token value associated with that request. Note that, upon this timeout expiration, the Token value is not eligible for possible reuse yet (see <a href="#ssec-req-send-steps" class="auto internal xref">Section 5.1.1</a>). Thus, until the actual amount of time before enabling Token reusage has elapsed, following late responses to the same request forwarded by the proxy will be discarded, as these are not matching (by Token) with any active request from the client.<a href="#section-5.5.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
@@ -3621,7 +3621,10 @@ <h3 id="name-version-02-to-03">
         </h3>
 <ul class="normal">
 <li class="normal" id="appendix-B.1-1.1">
-            <p id="appendix-B.1-1.1.1">Clarifications and editorial improvements.<a href="#appendix-B.1-1.1.1" class="pilcrow">¶</a></p>
+            <p id="appendix-B.1-1.1.1">Aligned handling of multiple responses with draft-ietf-core-groupcomm-bis.<a href="#appendix-B.1-1.1.1" class="pilcrow">¶</a></p>
+</li>
+          <li class="normal" id="appendix-B.1-1.2">
+            <p id="appendix-B.1-1.2.1">Clarifications and editorial improvements.<a href="#appendix-B.1-1.2.1" class="pilcrow">¶</a></p>
 </li>
         </ul>
 </section>

draft-ietf-core-groupcomm-proxy.txt

@@ -715,11 +715,13 @@ Table of Contents
    As discussed in Section 3.1.6 of [I-D.ietf-core-groupcomm-bis], it is
    possible that the client receives multiple responses to the same
    group request, i.e., with the same Token, from the same origin
-   server.  The client normally processes at the CoAP layer each of
-   those responses from the same origin server, and decides at the
-   application layer how to exactly handle them depending on its
-   available context information (see Section 3.1.6 of
-   [I-D.ietf-core-groupcomm-bis]).
+   server.  The specific client implementation determines at which layer
+   deduplication of responses is performed, or whether it is necessary
+   in an application at all.  If the processing of a response succeeds,
+   then the client delivers the response to the application as usual.
+   Depending on its available context information, the application
+   itself can be in a good position to decide how to handle such
+   responses.
 
    Upon the timeout expiration, i.e., T seconds after having sent the
    original unicast request to the proxy, the client frees up its local
@@ -2707,6 +2709,9 @@ Appendix B.  Document Updates
 
 B.1.  Version -02 to -03
 
+   *  Aligned handling of multiple responses with draft-ietf-core-
+      groupcomm-bis.
+
    *  Clarifications and editorial improvements.
 
 B.2.  Version -01 to -02