Changeset 2054 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

17/12/12 03:09:16 (9 years ago)

Author:

fielding@…

Message:

improve definition of the From header field; partly addresses #419

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (6 diffs)

draft-ietf-httpbis/latest/p2-semantics.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires June 18, 2013"; 
+       content: "Expires June 19, 2013"; 
   } 
   @bottom-right {
@@ -495 +495 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-12-15">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-12-16">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
@@ -523 +523 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">December 15, 2012</td>
+               <td class="right">December 16, 2012</td>
             </tr>
             <tr>
-               <td class="left">Expires: June 18, 2013</td>
+               <td class="left">Expires: June 19, 2013</td>
                <td class="right"></td>
             </tr>
@@ -554 +554 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on June 18, 2013.</p>
+      <p>This Internet-Draft will expire on June 19, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -2041 +2041 @@
       <div id="rfc.iref.f.1"></div>
       <h3 id="rfc.section.5.5.1"><a href="#rfc.section.5.5.1">5.5.1</a>&nbsp;<a id="header.from" href="#header.from">From</a></h3>
-      <p id="rfc.section.5.5.1.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:
+      <p id="rfc.section.5.5.1.p.1">The "From" header field contains an Internet email address for a human user who controls the requesting user agent. The address
+         ought to be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:
       </p>
       <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#header.from" class="smpl">From</a>    = <a href="#header.from" class="smpl">mailbox</a>
@@ -2048 +2049 @@
 </pre><p id="rfc.section.5.5.1.p.3">An example is:</p>
       <div id="rfc.figure.u.35"></div><pre class="text">  From: webmaster@example.org
-</pre><p id="rfc.section.5.5.1.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
-         on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving
-         end.
-      </p>
-      <p id="rfc.section.5.5.1.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original
-         issuer's address <em class="bcp14">SHOULD</em> be used.
-      </p>
-      <p id="rfc.section.5.5.1.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's
-         security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at
-         any time prior to a request.
+</pre><p id="rfc.section.5.5.1.p.5">The From header field is rarely sent by non-robotic user agents. A user agent <em class="bcp14">SHOULD NOT</em> send a From header field without explicit configuration by the user, since that might conflict with the user's privacy interests
+         or their site's security policy.
+      </p>
+      <p id="rfc.section.5.5.1.p.6">Robotic user agents <em class="bcp14">SHOULD</em> send a valid From header field so that the person responsible for running the robot can be contacted if problems occur on
+         servers, such as if the robot is sending excessive, unwanted, or invalid requests.
+      </p>
+      <p id="rfc.section.5.5.1.p.7">Servers <em class="bcp14">SHOULD NOT</em> use the From header field for access control or authentication, since most recipients will assume that the field value is
+         public information.
       </p>
       <div id="rfc.iref.r.2"></div>