Changeset 1488 for draft-ietf-httpbis

Timestamp:

Dec 5, 2011, 2:51:33 PM (8 years ago)

Author:

julian.reschke@…

Message:

clarify user agent (see #166)

Location:

draft-ietf-httpbis/latest

Files:

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

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

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires June 3, 2012"; 
+       content: "Expires June 7, 2012"; 
   } 
   @bottom-right {
@@ -409 +409 @@
       <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="2011-12-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-12-05">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -441 +441 @@
             </tr>
             <tr>
-               <td class="left">Expires: June 3, 2012</td>
+               <td class="left">Expires: June 7, 2012</td>
                <td class="right">HP</td>
             </tr>
@@ -494 +494 @@
             <tr>
                <td class="left"></td>
-               <td class="right">December 1, 2011</td>
+               <td class="right">December 5, 2011</td>
             </tr>
          </tbody>
@@ -527 +527 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on June 3, 2012.</p>
+      <p>This Internet-Draft will expire on June 7, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -879 +879 @@
          "<dfn>sender</dfn>" to refer to whichever component sent a given message and the term "<dfn>recipient</dfn>" to refer to any component that receives the message.
       </p>
-      <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
+      <div class="note" id="rfc.section.2.1.p.3"> 
+         <p> <b>Note:</b> The term 'user agent' covers both those situations where there is a user (human) interacting with the software agent (and
+            for which user interface or interactive suggestions might be made, e.g., warning the user or given the user an option in the
+            case of security or privacy options) and also those where the software agent may act autonomously.
+         </p> 
+      </div>
+      <p id="rfc.section.2.1.p.4">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
          the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and
          the origin server (O).
@@ -889 +895 @@
       <div id="rfc.iref.r.2"></div>
       <div id="rfc.iref.r.3"></div>
-      <p id="rfc.section.2.1.p.5">A client sends an HTTP request to the server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request-Line">Section&nbsp;3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, and payload metadata (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
-      </p>
-      <p id="rfc.section.2.1.p.6">A server responds to the client's request by sending an HTTP <dfn>response</dfn> message, beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase
+      <p id="rfc.section.2.1.p.6">A client sends an HTTP request to the server in the form of a <dfn>request</dfn> message, beginning with a request-line that includes a method, URI, and protocol version (<a href="#request.line" title="Request-Line">Section&nbsp;3.1.1</a>), followed by MIME-like header fields containing request modifiers, client information, and payload metadata (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
+      </p>
+      <p id="rfc.section.2.1.p.7">A server responds to the client's request by sending an HTTP <dfn>response</dfn> message, beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase
          (<a href="#status.line" title="Response Status-Line">Section&nbsp;3.1.2</a>), followed by MIME-like header fields containing server information, resource metadata, and payload metadata (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>), an empty line to indicate the end of the header section, and finally a message body containing the payload body (if any, <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>).
       </p>
-      <p id="rfc.section.2.1.p.7">Note that 1xx responses (<a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) are not final; therefore, a server can send zero or more 1xx responses, followed by exactly one final response (with any
+      <p id="rfc.section.2.1.p.8">Note that 1xx responses (<a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) are not final; therefore, a server can send zero or more 1xx responses, followed by exactly one final response (with any
          other status code).
       </p>
-      <p id="rfc.section.2.1.p.8">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p>
+      <p id="rfc.section.2.1.p.9">The following example illustrates a typical message exchange for a GET request on the URI "http://www.example.com/hello.txt":</p>
       <div id="rfc.figure.u.10"></div>
       <p>client request:</p><pre class="text2">GET /hello.txt HTTP/1.1
@@ -3479 +3485 @@
       <p id="rfc.section.C.19.p.1">Closed issues: </p>
       <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/166">http://tools.ietf.org/wg/httpbis/trac/ticket/166</a>&gt;: "Clarify 'User Agent'"
+         </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/300">http://tools.ietf.org/wg/httpbis/trac/ticket/300</a>&gt;: "Define non-final responses"
          </li>

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

@@ -536 +536 @@
    message.
 </t>
+<x:note>
+  <t>
+    <x:h>Note:</x:h> The term 'user agent' covers both those situations where
+    there is a user (human) interacting with the software agent (and for which
+    user interface or interactive suggestions might be made, e.g., warning the
+    user or given the user an option in the case of security or privacy
+    options) and also those where the software agent may act autonomously.
+  </t>
+</x:note>
 <t>
    Most HTTP communication consists of a retrieval request (GET) for
@@ -5866 +5875 @@
   <list style="symbols">
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/166"/>:
+      "Clarify 'User Agent'"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/300"/>:
       "Define non-final responses"