Script updating gh-pages from 2e01793. [ci skip]

draft-ietf-taps-impl.html

@@ -2177,12 +2177,20 @@ <h2 id="name-implementing-connection-man">
 Connection Properties. A Connection can also generate error events in the form of <code>SoftError</code> events.<a href="#section-7-1" class="pilcrow">¶</a></p>
 <p id="section-7-2">The set of Connection Properties that are supported for setting and getting on a Connection are described in <span>[<a href="#I-D.ietf-taps-interface" class="cite xref">I-D.ietf-taps-interface</a>]</span>. For
 any properties that are generic, and thus could apply to all protocols being used by a Connection, the Transport Services implementation should store the properties
-in storage common to all protocols, and notify all protocol instances in the Protocol Stack whenever the properties have been modified by the application. <span>[<a href="#RFC8303" class="cite xref">RFC8303</a>]</span> and <span>[<a href="#RFC8304" class="cite xref">RFC8304</a>]</span> offer guidance on how to do this for TCP, MPTCP, SCTP, UDP and UDP-Lite; see <a href="#specific-protocol-considerations" class="auto internal xref">Section 10</a> for a description of a back-tracking method to find the relevant protocol primitives using these documents.
+in storage common to all protocols, and notify the Protocol Stack as a whole whenever the properties have been modified by the application. <span>[<a href="#RFC8303" class="cite xref">RFC8303</a>]</span> and <span>[<a href="#RFC8304" class="cite xref">RFC8304</a>]</span> offer guidance on how to do this for TCP, MPTCP, SCTP, UDP and UDP-Lite; see <a href="#specific-protocol-considerations" class="auto internal xref">Section 10</a> for a description of a back-tracking method to find the relevant protocol primitives using these documents.
 For Protocol-specific Properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance.<a href="#section-7-2" class="pilcrow">¶</a></p>
-<p id="section-7-3">If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that is
-not using TCP), the action must fail gracefully. The application must be informed of the error, but the Connection itself must not be terminated.<a href="#section-7-3" class="pilcrow">¶</a></p>
-<p id="section-7-4">When protocol instances in the Protocol Stack report generic or protocol-specific
-errors, the API will deliver them to the application as <code>SoftError</code> events. These allow the application to be informed of ICMP errors, and other similar events.<a href="#section-7-4" class="pilcrow">¶</a></p>
+<p id="section-7-3">Some Connection Properties might apply to multiple protocols within a Protocol Stack. Depending on the specific property,
+it might be appropriate to apply the property across multiple protocols simultaneously, or else only apply it to one protocol.
+In general, the Transport Services implementation should allow the protocol closest to the application to interpret
+Connection Properties, and potentially modify the set of Connection Properties passed down to the next protocol in the
+stack. For example, if the application has requested to use keepalives with the <code>keepAlive</code> property, and the Protocol
+Stack contains both HTTP/2 and TCP, the HTTP/2 protocol can choose to enable its own keepalives to satisfy the application
+request, and disable TCP-level keepalives. For cases where the application needs to have fine-grained per-protocol control,
+the Transport Services implementation can expose Protocol-specific Properties.<a href="#section-7-3" class="pilcrow">¶</a></p>
+<p id="section-7-4">If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that is
+not using TCP), the action must fail gracefully. The application must be informed of the error, but the Connection itself must not be terminated.<a href="#section-7-4" class="pilcrow">¶</a></p>
+<p id="section-7-5">When protocol instances in the Protocol Stack report generic or protocol-specific
+errors, the API will deliver them to the application as <code>SoftError</code> events. These allow the application to be informed of ICMP errors, and other similar events.<a href="#section-7-5" class="pilcrow">¶</a></p>
 <div id="pooled-connections">
 <section id="section-7.1">
         <h3 id="name-pooled-connection">

draft-ietf-taps-impl.txt

@@ -1471,15 +1471,31 @@ MessageFramer.Deliver(connection, messageContext, messageData, endOfMessage)
    For any properties that are generic, and thus could apply to all
    protocols being used by a Connection, the Transport Services
    implementation should store the properties in storage common to all
-   protocols, and notify all protocol instances in the Protocol Stack
-   whenever the properties have been modified by the application.
-   [RFC8303] and [RFC8304] offer guidance on how to do this for TCP,
-   MPTCP, SCTP, UDP and UDP-Lite; see Section 10 for a description of a
-   back-tracking method to find the relevant protocol primitives using
-   these documents.  For Protocol-specific Properties, such as the User
+   protocols, and notify the Protocol Stack as a whole whenever the
+   properties have been modified by the application.  [RFC8303] and
+   [RFC8304] offer guidance on how to do this for TCP, MPTCP, SCTP, UDP
+   and UDP-Lite; see Section 10 for a description of a back-tracking
+   method to find the relevant protocol primitives using these
+   documents.  For Protocol-specific Properties, such as the User
    Timeout that applies to TCP, the Transport Services implementation
    only needs to update the relevant protocol instance.
 
+   Some Connection Properties might apply to multiple protocols within a
+   Protocol Stack.  Depending on the specific property, it might be
+   appropriate to apply the property across multiple protocols
+   simultaneously, or else only apply it to one protocol.  In general,
+   the Transport Services implementation should allow the protocol
+   closest to the application to interpret Connection Properties, and
+   potentially modify the set of Connection Properties passed down to
+   the next protocol in the stack.  For example, if the application has
+   requested to use keepalives with the keepAlive property, and the
+   Protocol Stack contains both HTTP/2 and TCP, the HTTP/2 protocol can
+   choose to enable its own keepalives to satisfy the application
+   request, and disable TCP-level keepalives.  For cases where the
+   application needs to have fine-grained per-protocol control, the
+   Transport Services implementation can expose Protocol-specific
+   Properties.
+
    If an error is encountered in setting a property (for example, if the
    application tries to set a TCP-specific property on a Connection that
    is not using TCP), the action must fail gracefully.  The application

draft-ietf-taps-interface.html

@@ -1223,7 +1223,7 @@ <h2 id="name-copyright-notice">
                     <p id="section-toc.1-1.6.2.1.2.2.1"><a href="#section-6.1.2" class="auto internal xref">6.1.2</a>.  <a href="#name-constraining-interfaces-for" class="internal xref">Constraining Interfaces for Endpoints</a></p>
 </li>
                   <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1.2.3">
-                    <p id="section-toc.1-1.6.2.1.2.3.1"><a href="#section-6.1.3" class="auto internal xref">6.1.3</a>.  <a href="#name-endpoint-aliases" class="internal xref">Endpoint Aliases</a></p>
+                    <p id="section-toc.1-1.6.2.1.2.3.1"><a href="#section-6.1.3" class="auto internal xref">6.1.3</a>.  <a href="#name-protocol-specific-endpoints" class="internal xref">Protocol-Specific Endpoints</a></p>
 </li>
                   <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1.2.4">
                     <p id="section-toc.1-1.6.2.1.2.4.1"><a href="#section-6.1.4" class="auto internal xref">6.1.4</a>.  <a href="#name-endpoint-examples" class="internal xref">Endpoint Examples</a></p>
@@ -2403,36 +2403,30 @@ <h4 id="name-constraining-interfaces-for">
 <p id="section-6.1.2-3">While specifying an Interface on an Endpoint restricts the candidates available for Connection establishment in the Pre-Establishment Phase, the Selection Properties prioritize and constrain the Connection establishment.<a href="#section-6.1.2-3" class="pilcrow">¶</a></p>
 </section>
 </div>
-<div id="endpoint-aliases">
+<div id="protocol-specific-endpoints">
 <section id="section-6.1.3">
-          <h4 id="name-endpoint-aliases">
-<a href="#section-6.1.3" class="section-number selfRef">6.1.3. </a><a href="#name-endpoint-aliases" class="section-name selfRef">Endpoint Aliases</a>
+          <h4 id="name-protocol-specific-endpoints">
+<a href="#section-6.1.3" class="section-number selfRef">6.1.3. </a><a href="#name-protocol-specific-endpoints" class="section-name selfRef">Protocol-Specific Endpoints</a>
           </h4>
 <p id="section-6.1.3-1">An Endpoint can have an alternative definition when using different protocols.
 For example, a server that supports both TLS/TCP and QUIC could be accessible
 on two different port numbers depending on which protocol is used.<a href="#section-6.1.3-1" class="pilcrow">¶</a></p>
-<p id="section-6.1.3-2">To support this, Endpoint objects can specify "aliases". An Endpoint can have
-multiple aliases set.<a href="#section-6.1.3-2" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-6.1.3-3">
-<pre>
-RemoteSpecifier.AddAlias(AlternateRemoteSpecifier)
-</pre><a href="#section-6.1.3-3" class="pilcrow">¶</a>
-</div>
-<p id="section-6.1.3-4">To scope an alias to apply conditionally to a specific transport
+<p id="section-6.1.3-2">To scope an Endpoint to apply conditionally to a specific transport
 protocol (such as defining an alternate port to use when QUIC
-is selected, as opposed to TCP), an alias Endpoint can be
+is selected, as opposed to TCP), an Endpoint can be
 associated with a protocol identifier. Protocol identifiers are
 objects or enumeration values provided by the Transport
 Services API, which will vary based on which protocols are
-implemented in a particular system.<a href="#section-6.1.3-4" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-6.1.3-5">
+implemented in a particular system.<a href="#section-6.1.3-2" class="pilcrow">¶</a></p>
+<div class="alignLeft art-text artwork" id="section-6.1.3-3">
 <pre>
 AlternateRemoteSpecifier.WithProtocol(QUIC)
-</pre><a href="#section-6.1.3-5" class="pilcrow">¶</a>
+</pre><a href="#section-6.1.3-3" class="pilcrow">¶</a>
 </div>
-<p id="section-6.1.3-6">The following example shows a case where <code>example.com</code> has a server
-running on port 443, with an alternate port of 8443 for QUIC.<a href="#section-6.1.3-6" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-6.1.3-7">
+<p id="section-6.1.3-4">The following example shows a case where <code>example.com</code> has a server
+running on port 443, with an alternate port of 8443 for QUIC. Both
+endpoints can be passed when creating a Preconnection.<a href="#section-6.1.3-4" class="pilcrow">¶</a></p>
+<div class="alignLeft art-text artwork" id="section-6.1.3-5">
 <pre>
 RemoteSpecifier := NewRemoteEndpoint()
 RemoteSpecifier.WithHostName("example.com")
@@ -2443,8 +2437,8 @@ <h4 id="name-endpoint-aliases">
 QUICRemoteSpecifier.WithPort(8443)
 QUICRemoteSpecifier.WithProtocol(QUIC)
 
-RemoteSpecifier.AddAlias(QUICRemoteSpecifier)
-</pre><a href="#section-6.1.3-7" class="pilcrow">¶</a>
+RemoteSpecifiers := [ RemoteSpecifier, QUICRemoteSpecifier ]
+</pre><a href="#section-6.1.3-5" class="pilcrow">¶</a>
 </div>
 </section>
 </div>

draft-ietf-taps-interface.txt

@@ -87,7 +87,7 @@ Table of Contents
      6.1.  Specifying Endpoints
        6.1.1.  Using Multicast Endpoints
        6.1.2.  Constraining Interfaces for Endpoints
-       6.1.3.  Endpoint Aliases
+       6.1.3.  Protocol-Specific Endpoints
        6.1.4.  Endpoint Examples
        6.1.5.  Multicast Examples
      6.2.  Specifying Transport Properties
@@ -989,29 +989,25 @@ Table of Contents
    Phase, the Selection Properties prioritize and constrain the
    Connection establishment.
 
-6.1.3.  Endpoint Aliases
+6.1.3.  Protocol-Specific Endpoints
 
    An Endpoint can have an alternative definition when using different
    protocols.  For example, a server that supports both TLS/TCP and QUIC
    could be accessible on two different port numbers depending on which
    protocol is used.
 
-   To support this, Endpoint objects can specify "aliases".  An Endpoint
-   can have multiple aliases set.
-
-   RemoteSpecifier.AddAlias(AlternateRemoteSpecifier)
-
-   To scope an alias to apply conditionally to a specific transport
+   To scope an Endpoint to apply conditionally to a specific transport
    protocol (such as defining an alternate port to use when QUIC is
-   selected, as opposed to TCP), an alias Endpoint can be associated
-   with a protocol identifier.  Protocol identifiers are objects or
-   enumeration values provided by the Transport Services API, which will
-   vary based on which protocols are implemented in a particular system.
+   selected, as opposed to TCP), an Endpoint can be associated with a
+   protocol identifier.  Protocol identifiers are objects or enumeration
+   values provided by the Transport Services API, which will vary based
+   on which protocols are implemented in a particular system.
 
    AlternateRemoteSpecifier.WithProtocol(QUIC)
 
    The following example shows a case where example.com has a server
-   running on port 443, with an alternate port of 8443 for QUIC.
+   running on port 443, with an alternate port of 8443 for QUIC.  Both
+   endpoints can be passed when creating a Preconnection.
 
    RemoteSpecifier := NewRemoteEndpoint()
    RemoteSpecifier.WithHostName("example.com")
@@ -1022,7 +1018,7 @@ Table of Contents
    QUICRemoteSpecifier.WithPort(8443)
    QUICRemoteSpecifier.WithProtocol(QUIC)
 
-   RemoteSpecifier.AddAlias(QUICRemoteSpecifier)
+   RemoteSpecifiers := [ RemoteSpecifier, QUICRemoteSpecifier ]
 
 6.1.4.  Endpoint Examples
 

index.html

@@ -714,7 +714,7 @@ <h2>Preview for branch <a href="tfpauly-patch-43">tfpauly-patch-43</a></h2>
       <tr>
         <td><a href="tfpauly-patch-43/draft-ietf-taps-interface.html" class="html draft-ietf-taps-interface" title="An Abstract Application Layer Interface to Transport Services (HTML)">TAPS Interface</a></td>
         <td><a href="tfpauly-patch-43/draft-ietf-taps-interface.txt" class="txt draft-ietf-taps-interface" title="An Abstract Application Layer Interface to Transport Services (Text)">plain text</a></td>
-        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-interface.txt&amp;url_2=https://ietf-tapswg.github.io/api-drafts/tfpauly-patch-43/draft-ietf-taps-interface.txt" class="diff draft-ietf-taps-interface">diff with master</a></td>
+        <td>same as master</td>
       </tr>
       <tr>
         <td><a href="tfpauly-patch-43/draft-ietf-taps-impl.html" class="html draft-ietf-taps-impl" title="Implementing Interfaces to Transport Services (HTML)">TAPS Implementation</a></td>
@@ -858,12 +858,12 @@ <h2>Preview for branch <a href="tfpauly-patch-44">tfpauly-patch-44</a></h2>
       <tr>
         <td><a href="tfpauly-patch-44/draft-ietf-taps-interface.html" class="html draft-ietf-taps-interface" title="An Abstract Application Layer Interface to Transport Services (HTML)">TAPS Interface</a></td>
         <td><a href="tfpauly-patch-44/draft-ietf-taps-interface.txt" class="txt draft-ietf-taps-interface" title="An Abstract Application Layer Interface to Transport Services (Text)">plain text</a></td>
-        <td>same as master</td>
+        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-interface.txt&amp;url_2=https://ietf-tapswg.github.io/api-drafts/tfpauly-patch-44/draft-ietf-taps-interface.txt" class="diff draft-ietf-taps-interface">diff with master</a></td>
       </tr>
       <tr>
         <td><a href="tfpauly-patch-44/draft-ietf-taps-impl.html" class="html draft-ietf-taps-impl" title="Implementing Interfaces to Transport Services (HTML)">TAPS Implementation</a></td>
         <td><a href="tfpauly-patch-44/draft-ietf-taps-impl.txt" class="txt draft-ietf-taps-impl" title="Implementing Interfaces to Transport Services (Text)">plain text</a></td>
-        <td><a href="https://author-tools.ietf.org/api/iddiff?url_1=https://ietf-tapswg.github.io/api-drafts/draft-ietf-taps-impl.txt&amp;url_2=https://ietf-tapswg.github.io/api-drafts/tfpauly-patch-44/draft-ietf-taps-impl.txt" class="diff draft-ietf-taps-impl">diff with master</a></td>
+        <td>same as master</td>
       </tr>
     </table>
     <h2>Preview for branch <a href="draft-ietf-taps-arch-19">draft-ietf-taps-arch-19</a></h2>