Changeset 2101 for draft-ietf-httpbis/latest

Timestamp:

08/01/13 18:31:02 (10 years ago)

Author:

julian.reschke@…

Message:

avoid a MUST in a test following "For example" (see ​http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0013.html)

Location:

draft-ietf-httpbis/latest

Files:

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

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires July 9, 2013"; 
+       content: "Expires July 12, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-01-05">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-01-08">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -520 +520 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">January 5, 2013</td>
+               <td class="right">January 8, 2013</td>
             </tr>
             <tr>
-               <td class="left">Expires: July 9, 2013</td>
+               <td class="left">Expires: July 12, 2013</td>
                <td class="right"></td>
             </tr>
@@ -551 +551 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 9, 2013.</p>
+      <p>This Internet-Draft will expire on July 12, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -2085 +2085 @@
          although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request that contained the Upgrade header field.
       </p>
-      <p id="rfc.section.6.7.p.7">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, then it <em class="bcp14">MUST</em> first respond with a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> message in HTTP/1.1 and then immediately follow that with the new protocol's equivalent of a response to a GET on the target
+      <p id="rfc.section.6.7.p.7">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, then it
+         first responds with a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> message in HTTP/1.1 and then immediately follows that with the new protocol's equivalent of a response to a GET on the target
          resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of
          an additional round-trip. A server <em class="bcp14">MUST NOT</em> switch protocols unless the received message semantics can be honored by the new protocol; an OPTIONS request can be honored

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

@@ -3059 +3059 @@
 <t>
    For example, if the Upgrade header field is received in a GET request
-   and the server decides to switch protocols, then it &MUST; first respond
+   and the server decides to switch protocols, then it first responds
    with a <x:ref>101 (Switching Protocols)</x:ref> message in HTTP/1.1 and
-   then immediately follow that with the new protocol's equivalent of a
+   then immediately follows that with the new protocol's equivalent of a
    response to a GET on the target resource.  This allows a connection to be
    upgraded to protocols with the same semantics as HTTP without the