Ignore:
Timestamp:
06/05/14 16:20:31 (6 years ago)
Author:
julian.reschke@…
Message:

mainly grammatical fixes (#553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/auth48/rfc7231.abdiff.txt

    r2645 r2647  
    387387
    388388
    389 Section 1., paragraph 1:
    390 OLD:
    391 
    392     Each Hypertext Transfer Protocol (HTTP) message is either a request
    393     or a response.  A server listens on a connection for a request,
    394     parses each message received, interprets the message semantics in
    395     relation to the identified request target, and responds to that
    396     request with one or more response messages.  A client constructs
    397     request messages to communicate specific intentions, and examines
    398     received responses to see if the intentions were carried out, and
    399     determine how to interpret the results.  This document defines
    400     HTTP/1.1 request and response semantics in terms of the architecture
    401     defined in [RFC7230].
    402 
    403 NEW:
    404 
    405     Each Hypertext Transfer Protocol (HTTP) message is either a request
    406     or a response.  A server listens on a connection for a request,
    407     parses each message received, interprets the message semantics in
    408     relation to the identified request target, and responds to that
    409     request with one or more response messages.  A client constructs
    410     request messages to communicate specific intentions, examines
    411     received responses to see if the intentions were carried out, and
    412     determines how to interpret the results.  This document defines
    413     HTTP/1.1 request and response semantics in terms of the architecture
    414     defined in [RFC7230].
    415 
    416 
    417389Section 2., paragraph 1:
    418390OLD:
     
    431403    identified by a Uniform Resource Identifier (URI), as described in
    432404    Section 2.7 of [RFC7230].
    433 
    434 
    435 Section 3., paragraph 3:
    436 OLD:
    437 
    438     An origin server might be provided with, or capable of generating,
    439     multiple representations that are each intended to reflect the
    440     current state of a target resource.  In such cases, some algorithm is
    441     used by the origin server to select one of those representations as
    442     most applicable to a given request, usually based on content
    443     negotiation.  This "selected representation" is used to provide the
    444     data and metadata for evaluating conditional requests [RFC7232] and
    445     constructing the payload for 200 (OK) and 304 (Not Modified)
    446     responses to GET (Section 4.3.1).
    447 
    448 NEW:
    449 
    450     An origin server might be provided with, or be capable of generating,
    451     multiple representations that are each intended to reflect the
    452     current state of a target resource.  In such cases, some algorithm is
    453     used by the origin server to select one of those representations as
    454     most applicable to a given request, usually based on content
    455     negotiation.  This "selected representation" is used to provide the
    456     data and metadata for evaluating conditional requests [RFC7232] and
    457     constructing the payload for 200 (OK) and 304 (Not Modified)
    458     responses to GET (Section 4.3.1).
    459405
    460406
     
    497443
    498444
    499 Section 3.1.1.1., paragraph 6:
    500 OLD:
    501 
    502     A parameter value that matches the token production can be
    503     transmitted as either a token or within a quoted-string.  The quoted
    504     and unquoted values are equivalent.  For example, the following
    505     examples are all equivalent, but the first is preferred for
    506     consistency:
    507 
    508 NEW:
    509 
    510     A parameter value that matches the token production can be
    511     transmitted either as a token or within a quoted-string.  The quoted
    512     and unquoted values are equivalent.  For example, the following
    513     examples are all equivalent, but the first is preferred for
    514     consistency:
    515 
    516 
    517445Section 3.1.1.2., paragraph 3:
    518446OLD:
    519447
    520     Charset names ought to be registered in IANA Character Set registry
    521     (<http://www.iana.org/assignments/character-sets>) according to the
    522     procedures defined in [RFC2978].
     448    Charset names ought to be registered in the IANA Character Set
     449    registry (<http://www.iana.org/assignments/character-sets>) according
     450    to the procedures defined in [RFC2978].
    523451
    524452NEW:
     
    790718
    791719
    792 Section 4.3.4., paragraph 10:
    793 OLD:
    794 
    795     An origin server MUST NOT send a validator header field
    796     (Section 7.2), such as an ETag or Last-Modified field, in a
    797     successful response to PUT unless the request's representation data
    798     was saved without any transformation applied to the body (i.e., the
    799     resource's new representation data is identical to the representation
    800     data received in the PUT request) and the validator field value
    801     reflects the new representation.  This requirement allows a user
    802     agent to know when the representation body it has in memory remains
    803     current as a result of the PUT, thus not in need of retrieving again
    804     from the origin server, and that the new validator(s) received in the
    805     response can be used for future conditional requests in order to
    806     prevent accidental overwrites (Section 5.2).
    807 
    808 NEW:
    809 
    810     An origin server MUST NOT send a validator header field
    811     (Section 7.2), such as an ETag or Last-Modified field, in a
    812     successful response to PUT unless the request's representation data
    813     was saved without any transformation applied to the body (i.e., the
    814     resource's new representation data is identical to the representation
    815     data received in the PUT request) and the validator field value
    816     reflects the new representation.  This requirement allows a user
    817     agent to know when the representation body it has in memory remains
    818     current as a result of the PUT, thus not in need of being retrieved
    819     again from the origin server, and that the new validator(s) received
    820     in the response can be used for future conditional requests in order
    821     to prevent accidental overwrites (Section 5.2).
    822 
    823 
    824720Section 4.3.4., paragraph 13:
    825721OLD:
     
    862758    2xx (Successful) status code to indicate that a connection is
    863759    established.  However, most origin servers do not implement CONNECT.
    864 
    865 
    866 Section 4.3.7., paragraph 1:
    867 OLD:
    868 
    869     The OPTIONS method requests information about the communication
    870     options available for the target resource, either at the origin
    871     server or an intervening intermediary.  This method allows a client
    872     to determine the options and/or requirements associated with a
    873     resource, or the capabilities of a server, without implying a
    874     resource action.
    875 
    876 NEW:
    877 
    878     The OPTIONS method requests information about the communication
    879     options available for the target resource, at either the origin
    880     server or an intervening intermediary.  This method allows a client
    881     to determine the options and/or requirements associated with a
    882     resource, or the capabilities of a server, without implying a
    883     resource action.
    884760
    885761
     
    1069945    identifier.  A sender SHOULD NOT generate information in product-
    1070946    version that is not a version identifier (i.e., successive versions
    1071     of the same product name ought to only differ in the product-version
     947    of the same product name ought only to differ in the product-version
    1072948    portion of the product identifier).
    1073949
     
    12291105       Permanently) ([RFC7238]; however, it defines the status code 308
    12301106       (Permanent Redirect) for this purpose).
    1231 
    1232 
    1233 Section 6.5.1., paragraph 1:
    1234 OLD:
    1235 
    1236     The 400 (Bad Request) status code indicates that the server cannot or
    1237     will not process the request due to something which is perceived to
    1238     be a client error (e.g., malformed request syntax, invalid request
    1239     message framing, or deceptive request routing).
    1240 
    1241 NEW:
    1242 
    1243     The 400 (Bad Request) status code indicates that the server cannot or
    1244     will not process the request due to something that is perceived to be
    1245     a client error (e.g., malformed request syntax, invalid request
    1246     message framing, or deceptive request routing).
    12471107
    12481108
     
    13371197
    13381198
    1339 Section 7.1.2., paragraph 5:
    1340 OLD:
    1341 
    1342     If the Location value provided in a 3xx (Redirection) does not have a
    1343     fragment component, a user agent MUST process the redirection as if
    1344     the value inherits the fragment component of the URI reference used
    1345     to generate the request target (i.e., the redirection inherits the
    1346     original reference's fragment, if any).
    1347 
    1348 NEW:
    1349 
    1350     If the Location value provided in a 3xx (Redirection) response does
    1351     not have a fragment component, a user agent MUST process the
    1352     redirection as if the value inherits the fragment component of the
    1353     URI reference used to generate the request target (i.e., the
    1354     redirection inherits the original reference's fragment, if any).
    1355 
    1356 
    13571199Section 7.1.4., paragraph 1:
    13581200OLD:
     
    14841326
    14851327
    1486 Section 8.2., paragraph 2:
    1487 OLD:
    1488 
    1489     This Section replaces the registration procedure for HTTP Status
    1490     Codes previously defined in Section 7.1 of [RFC2817].
    1491 
    1492 NEW:
    1493 
    1494     This section replaces the registration procedure for HTTP Status
    1495     Codes previously defined in Section 7.1 of [RFC2817].
    1496 
    1497 
    14981328Section 8.2.3., paragraph 1:
    14991329OLD:
     
    15201350    registry located at <http://www.iana.org/assignments/message-headers>
    15211351    as defined by [BCP90].
    1522 
    1523 
    1524 Section 8.3.1., paragraph 3:
    1525 OLD:
    1526 
    1527     Authors of specifications defining new fields are advised to keep the
    1528     name as short as practical and to not prefix the name with "X-"
    1529     unless the header field will never be used on the Internet.  (The
    1530     "x-" prefix idiom has been extensively misused in practice; it was
    1531     intended to only be used as a mechanism for avoiding name collisions
    1532     inside proprietary software or intranet processing, since the prefix
    1533     would ensure that private names never collide with a newly registered
    1534     Internet name; see [BCP178] for further information)
    1535 
    1536 NEW:
    1537 
    1538     Authors of specifications defining new fields are advised to keep the
    1539     name as short as practical and not to prefix the name with "X-"
    1540     unless the header field will never be used on the Internet.  (The
    1541     "X-" prefix idiom has been extensively misused in practice; it was
    1542     intended to only be used as a mechanism for avoiding name collisions
    1543     inside proprietary software or intranet processing, since the prefix
    1544     would ensure that private names never collide with a newly registered
    1545     Internet name; see [BCP178] for further information).
    15461352
    15471353
     
    16501456
    16511457
    1652 Section 9.1., paragraph 2:
    1653 OLD:
    1654 
    1655     For example, UNIX, Microsoft Windows, and other operating systems use
    1656     ".." as a path component to indicate a directory level above the
    1657     current one, and use specially named paths or file names to send data
    1658     to system devices.  Similar naming conventions might exist within
    1659     other types of storage systems.  Likewise, local storage systems have
    1660     an annoying tendency to prefer user-friendliness over security when
    1661     handling invalid or unexpected characters, recomposition of
    1662     decomposed characters, and case-normalization of case-insensitive
    1663     names.
    1664 
    1665 NEW:
    1666 
    1667     For example, UNIX, Microsoft Windows, and other operating systems use
    1668     ".." as a path component to indicate a directory level above the
    1669     current one, and they use specially named paths or file names to send
    1670     data to system devices.  Similar naming conventions might exist
    1671     within other types of storage systems.  Likewise, local storage
    1672     systems have an annoying tendency to prefer user-friendliness over
    1673     security when handling invalid or unexpected characters,
    1674     recomposition of decomposed characters, and case-normalization of
    1675     case-insensitive names.
    1676 
    1677 
    16781458Section 9.1., paragraph 3:
    16791459OLD:
     
    17981578    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
    17991579               Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
    1800 
    1801 
    1802 Appendix A., paragraph 1:
    1803 OLD:
    1804 
    1805     HTTP/1.1 uses many of the constructs defined for the Internet Message
    1806     Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
    1807     [RFC2045] to allow a message body to be transmitted in an open
    1808     variety of representations and with extensible header fields.
    1809     However, RFC 2045 is focused only on email; applications of HTTP have
    1810     many characteristics that differ from email, and hence HTTP has
    1811     features that differ from MIME.  These differences were carefully
    1812     chosen to optimize performance over binary connections, to allow
    1813     greater freedom in the use of new media types, to make date
    1814     comparisons easier, and to acknowledge the practice of some early
    1815     HTTP servers and clients.
    1816 
    1817 NEW:
    1818 
    1819     HTTP/1.1 uses many of the constructs defined for the Internet Message
    1820     Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
    1821     [RFC2045] to allow a message body to be transmitted in an open
    1822     variety of representations and with extensible header fields.
    1823     However, RFC 2045 is focused only on email; applications of HTTP have
    1824     many characteristics that differ from email; hence, HTTP has features
    1825     that differ from MIME.  These differences were carefully chosen to
    1826     optimize performance over binary connections, to allow greater
    1827     freedom in the use of new media types, to make date comparisons
    1828     easier, and to acknowledge the practice of some early HTTP servers
    1829     and clients.
    18301580
    18311581
Note: See TracChangeset for help on using the changeset viewer.