Changeset 2005

Timestamp:

28/11/12 08:21:03 (8 years ago)

Author:

fielding@…

Message:

remove bogus (non-interop) requirement on being able to recover from asynchronous close events

Location:

draft-ietf-httpbis/latest

Files:

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

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

@@ -2028 +2028 @@
       </p>
       <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h4>
-      <p id="rfc.section.6.2.2.2.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
-         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding
-         of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
+      <p id="rfc.section.6.2.2.2.p.1">Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover
+         from asynchronous close events. A client <em class="bcp14">MAY</em> open a new connection and retransmit an aborted sequence of requests without user interaction so long as the request sequence
+         is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A client <em class="bcp14">MUST NOT</em> automatically retry non-idempotent request sequences, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user agent software with semantic understanding
+         of the application <em class="bcp14">MAY</em> substitute for user confirmation. An automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if a second sequence of requests fails.
       </p>
       <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<a id="persistent.concurrency" href="#persistent.concurrency">Concurrency</a></h3>

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

@@ -2903 +2903 @@
 <section title="Retrying Requests" anchor="persistent.retrying.requests">
 <t>
-   Senders can close the transport connection at any time. Therefore, 
-   clients, servers, and proxies &MUST; be able to recover
-   from asynchronous close events. Client software &MAY; reopen the
-   transport connection and retransmit the aborted sequence of requests
-   without user interaction so long as the request sequence is
-   idempotent (see &idempotent-methods;). Non-idempotent request methods or sequences
-   &MUST-NOT; be automatically retried, although user agents &MAY; offer a
-   human operator the choice of retrying the request(s). Confirmation by
+   Connections can be closed at any time, with or without intention.
+   Implementations ought to anticipate the need to recover
+   from asynchronous close events.
+   A client &MAY; open a new connection and retransmit an aborted sequence
+   of requests without user interaction so long as the request sequence is
+   idempotent (see &idempotent-methods;).
+   A client &MUST-NOT; automatically retry non-idempotent request sequences,
+   although user agents &MAY; offer a human operator the choice of retrying
+   the request(s). Confirmation by
    user agent software with semantic understanding of the application
-   &MAY; substitute for user confirmation. The automatic retry &SHOULD-NOT; 
-   be repeated if the second sequence of requests fails.
+   &MAY; substitute for user confirmation. An automatic retry &SHOULD-NOT; 
+   be repeated if a second sequence of requests fails.
 </t>
 </section>