Changeset 2054


Ignore:
Timestamp:
Dec 16, 2012, 7:09:16 PM (7 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2052 r2054  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 18, 2013";
     451       content: "Expires June 19, 2013";
    452452  }
    453453  @bottom-right {
     
    495495      <meta name="dct.creator" content="Reschke, J. F.">
    496496      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    497       <meta name="dct.issued" scheme="ISO8601" content="2012-12-15">
     497      <meta name="dct.issued" scheme="ISO8601" content="2012-12-16">
    498498      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    499499      <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.">
     
    523523            <tr>
    524524               <td class="left">Intended status: Standards Track</td>
    525                <td class="right">December 15, 2012</td>
     525               <td class="right">December 16, 2012</td>
    526526            </tr>
    527527            <tr>
    528                <td class="left">Expires: June 18, 2013</td>
     528               <td class="left">Expires: June 19, 2013</td>
    529529               <td class="right"></td>
    530530            </tr>
     
    554554         in progress”.
    555555      </p>
    556       <p>This Internet-Draft will expire on June 18, 2013.</p>
     556      <p>This Internet-Draft will expire on June 19, 2013.</p>
    557557      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    558558      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    20412041      <div id="rfc.iref.f.1"></div>
    20422042      <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>
    2043       <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>:
     2043      <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
     2044         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>:
    20442045      </p>
    20452046      <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>
     
    20482049</pre><p id="rfc.section.5.5.1.p.3">An example is:</p>
    20492050      <div id="rfc.figure.u.35"></div><pre class="text">  From: webmaster@example.org
    2050 </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
    2051          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
    2052          end.
    2053       </p>
    2054       <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
    2055          issuer's address <em class="bcp14">SHOULD</em> be used.
    2056       </p>
    2057       <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
    2058          security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at
    2059          any time prior to a request.
     2051</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
     2052         or their site's security policy.
     2053      </p>
     2054      <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
     2055         servers, such as if the robot is sending excessive, unwanted, or invalid requests.
     2056      </p>
     2057      <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
     2058         public information.
    20602059      </p>
    20612060      <div id="rfc.iref.r.2"></div>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2052 r2054  
    23272327  <x:anchor-alias value="mailbox"/>
    23282328<t>
    2329    The "From" header field, if given, &SHOULD; contain an Internet
    2330    e-mail address for the human user who controls the requesting user
    2331    agent. The address &SHOULD; be machine-usable, as defined by "mailbox"
     2329   The "From" header field contains an Internet email address for a human
     2330   user who controls the requesting user agent. The address ought to be
     2331   machine-usable, as defined by "mailbox"
    23322332   in <xref x:sec="3.4" x:fmt="of" target="RFC5322"/>:
    23332333</t>
     
    23442344</artwork></figure>
    23452345<t>
    2346    This header field &MAY; be used for logging purposes and as a means for
    2347    identifying the source of invalid or unwanted requests. It &SHOULD-NOT;
    2348    be used as an insecure form of access protection. The interpretation
    2349    of this field is that the request is being performed on behalf of the
    2350    person given, who accepts responsibility for the method performed. In
    2351    particular, robot agents &SHOULD; include this header field so that the
     2346   The From header field is rarely sent by non-robotic user agents.
     2347   A user agent &SHOULD-NOT; send a From header field without explicit
     2348   configuration by the user, since that might conflict with the user's
     2349   privacy interests or their site's security policy.
     2350</t>
     2351<t>
     2352   Robotic user agents &SHOULD; send a valid From header field so that the
    23522353   person responsible for running the robot can be contacted if problems
    2353    occur on the receiving end.
    2354 </t>
    2355 <t>
    2356    The Internet e-mail address in this field &MAY; be separate from the
    2357    Internet host which issued the request. For example, when a request
    2358    is passed through a proxy the original issuer's address &SHOULD; be
    2359    used.
    2360 </t>
    2361 <t>
    2362    The client &SHOULD-NOT;  send the From header field without the user's
    2363    approval, as it might conflict with the user's privacy interests or
    2364    their site's security policy. It is strongly recommended that the
    2365    user be able to disable, enable, and modify the value of this field
    2366    at any time prior to a request.
     2354   occur on servers, such as if the robot is sending excessive, unwanted,
     2355   or invalid requests.
     2356</t>
     2357<t>
     2358   Servers &SHOULD-NOT; use the From header field for access control or
     2359   authentication, since most recipients will assume that the field value is
     2360   public information.
    23672361</t>
    23682362</section>
Note: See TracChangeset for help on using the changeset viewer.