Changeset 2312

Timestamp:

27/07/13 13:13:33 (9 years ago)

Author:

julian.reschke@…

Message:

add gateway/via requirement change to the changes list (see #460)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (2 diffs)
• p1-messaging.xml (modified) (1 diff)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -2960 +2960 @@
       <p id="rfc.section.A.2.p.25">The asterisk form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>)
       </p>
-      <p id="rfc.section.A.2.p.26">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;6.1</a>)
-      </p>
-      <p id="rfc.section.A.2.p.27">"hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop
+      <p id="rfc.section.A.2.p.26">Gateways do not need to generate <a href="#header.via" class="smpl">Via</a> header fields anymore. (<a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;5.7.1</a>)
+      </p>
+      <p id="rfc.section.A.2.p.27">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;6.1</a>)
+      </p>
+      <p id="rfc.section.A.2.p.28">"hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop
          in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>)
       </p>
-      <p id="rfc.section.A.2.p.28">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
-      </p>
-      <p id="rfc.section.A.2.p.29">An idempotent sequence of requests is no longer required to be retried. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
-      </p>
-      <p id="rfc.section.A.2.p.30">The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed.
+      <p id="rfc.section.A.2.p.29">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
+      </p>
+      <p id="rfc.section.A.2.p.30">An idempotent sequence of requests is no longer required to be retried. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
+      </p>
+      <p id="rfc.section.A.2.p.31">The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed.
          (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
       </p>
-      <p id="rfc.section.A.2.p.31">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
-      </p>
-      <p id="rfc.section.A.2.p.32">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). Furthermore, the ordering in the field value is now significant. (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;6.7</a>)
-      </p>
-      <p id="rfc.section.A.2.p.33">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>)
-      </p>
-      <p id="rfc.section.A.2.p.34">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section&nbsp;4.2.2</a>)
-      </p>
-      <p id="rfc.section.A.2.p.35">This specification now defines the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.5</a>)
-      </p>
-      <p id="rfc.section.A.2.p.36">Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged
+      <p id="rfc.section.A.2.p.32">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
+      </p>
+      <p id="rfc.section.A.2.p.33">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). Furthermore, the ordering in the field value is now significant. (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;6.7</a>)
+      </p>
+      <p id="rfc.section.A.2.p.34">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>)
+      </p>
+      <p id="rfc.section.A.2.p.35">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section&nbsp;4.2.2</a>)
+      </p>
+      <p id="rfc.section.A.2.p.36">This specification now defines the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.5</a>)
+      </p>
+      <p id="rfc.section.A.2.p.37">Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged
          altogether. (<a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a>)
       </p>
-      <p id="rfc.section.A.2.p.37">Empty list elements in list productions (e.g., a list header field containing ", ,") have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Appendix&nbsp;B</a>)
+      <p id="rfc.section.A.2.p.38">Empty list elements in list productions (e.g., a list header field containing ", ,") have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Appendix&nbsp;B</a>)
       </p>
       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="abnf.extension" href="#abnf.extension">ABNF list extension: #rule</a></h1>
@@ -3554 +3556 @@
             </li>
             <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
-                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.iref.v.1"><b>5.7.1</b></a>, <a href="#rfc.xref.header.via.1">7.1</a></li>
+                  <li>Via header field&nbsp;&nbsp;<a href="#rfc.iref.v.1"><b>5.7.1</b></a>, <a href="#rfc.xref.header.via.1">7.1</a>, <a href="#rfc.xref.header.via.2">A.2</a></li>
                </ul>
             </li>

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -5007 +5007 @@
 </t>
 <t>
+  Gateways do not need to generate <x:ref>Via</x:ref> header fields anymore.
+  (<xref target="header.via"/>)
+</t>
+<t>
   Exactly when "close" connection options have to be sent has been clarified.
   (<xref target="header.connection"/>)