Ignore:
Timestamp:
25/05/14 13:57:58 (6 years ago)
Author:
julian.reschke@…
Message:

editorial fixes (#553)

File:
1 edited

Legend:

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

    r2678 r2692  
    77 Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
    88 Updates: 2617 (if approved)                                   greenbytes
    9  Intended status: Standards Track                            May 16, 2014
    10  Expires: November 17, 2014
     9 Intended status: Standards Track                            May 25, 2014
     10 Expires: November 26, 2014
    1111
    1212NEW:
     
    9191OLD:
    9292
    93     This Internet-Draft will expire on November 17, 2014.
     93    This Internet-Draft will expire on November 26, 2014.
    9494
    9595NEW:
     
    196196
    197197
    198 Section 2.1., paragraph 1:
    199 OLD:
    200 
    201     HTTP provides a simple challenge-response authentication framework
    202     that can be used by a server to challenge a client request and by a
    203     client to provide authentication information.  It uses a case-
    204     insensitive token as a means to identify the authentication scheme,
    205     followed by additional information necessary for achieving
    206     authentication via that scheme.  The latter can either be a comma-
    207     separated list of parameters or a single sequence of characters
    208     capable of holding base64-encoded information.
    209 
    210 NEW:
    211 
    212     HTTP provides a simple challenge-response authentication framework
    213     that can be used by a server to challenge a client request and by a
    214     client to provide authentication information.  It uses a case-
    215     insensitive token as a means to identify the authentication scheme,
    216     followed by additional information necessary for achieving
    217     authentication via that scheme.  The latter can be either a comma-
    218     separated list of parameters or a single sequence of characters
    219     capable of holding base64-encoded information.
    220 
    221 
    222 Section 2.1., paragraph 17:
    223 OLD:
    224 
    225     A server that receives valid credentials which are not adequate to
    226     gain access ought to respond with the 403 (Forbidden) status code
    227     (Section 6.5.3 of [RFC7231]).
    228 
    229 NEW:
    230 
    231     A server that receives valid credentials that are not adequate to
    232     gain access ought to respond with the 403 (Forbidden) status code
    233     (Section 6.5.3 of [RFC7231]).
    234 
    235 
    236 Section 5.5, paragraph 0:
    237 OLD:
    238 
    239     A protection space is defined by the canonical root URI (the scheme
    240     and authority components of the effective request URI; see Section
    241     5.5 of [RFC7230]) of the server being accessed, in combination with
    242     the realm value if present.  These realms allow the protected
    243     resources on a server to be partitioned into a set of protection
    244     spaces, each with its own authentication scheme and/or authorization
    245     database.  The realm value is a string, generally assigned by the
    246     origin server, which can have additional semantics specific to the
    247     authentication scheme.  Note that a response can have multiple
    248     challenges with the same auth-scheme but different realms.
    249 
    250 NEW:
    251 
    252     A protection space is defined by the canonical root URI (the scheme
    253     and authority components of the effective request URI; see Section
    254     5.5 of [RFC7230]) of the server being accessed, in combination with
    255     the realm value if present.  These realms allow the protected
    256     resources on a server to be partitioned into a set of protection
    257     spaces, each with its own authentication scheme and/or authorization
    258     database.  The realm value is a string, generally assigned by the
    259     origin server, that can have additional semantics specific to the
    260     authentication scheme.  Note that a response can have multiple
    261     challenges with the same auth-scheme but with different realms.
    262 
    263 
    264 Section 3.2., paragraph 1:
    265 OLD:
    266 
    267     The 407 (Proxy Authentication Required) status code is similar to 401
    268     (Unauthorized), but indicates that the client needs to authenticate
    269     itself in order to use a proxy.  The proxy MUST send a Proxy-
    270     Authenticate header field (Section 4.3) containing a challenge
    271     applicable to that proxy for the target resource.  The client MAY
    272     repeat the request with a new or replaced Proxy-Authorization header
    273     field (Section 4.4).
    274 
    275 NEW:
    276 
    277     The 407 (Proxy Authentication Required) status code is similar to 401
    278     (Unauthorized), but it indicates that the client needs to
    279     authenticate itself in order to use a proxy.  The proxy MUST send a
    280     Proxy-Authenticate header field (Section 4.3) containing a challenge
    281     applicable to that proxy for the target resource.  The client MAY
    282     repeat the request with a new or replaced Proxy-Authorization header
    283     field (Section 4.4).
    284 
    285 
    286198Section 5.1., paragraph 1:
    287199OLD:
    288200
    289     The HTTP Authentication Scheme Registry defines the namespace for the
    290     authentication schemes in challenges and credentials.  It will be
    291     created and maintained at (the suggested URI)
    292     <http://www.iana.org/assignments/http-authschemes>.
     201    The "Hypertext Transfer Protocol (HTTP) Authentication Scheme
     202    Registry" defines the namespace for the authentication schemes in
     203    challenges and credentials.  It will has been created and is now
     204    maintained at <http://www.iana.org/assignments/http-authschemes>.
    293205
    294206NEW:
     
    298210    registry has been created and is now maintained at
    299211    <http://www.iana.org/assignments/http-authschemes>.
    300 
    301 
    302 Section 5.1.2., paragraph 3:
    303 OLD:
    304 
    305     o  The authentication parameter "realm" is reserved for defining
    306        Protection Spaces as defined in Section 2.2.  New schemes MUST NOT
    307        use it in a way incompatible with that definition.
    308 
    309 NEW:
    310 
    311     o  The authentication parameter "realm" is reserved for defining
    312        protection spaces as described in Section 2.2.  New schemes MUST
    313        NOT use it in a way incompatible with that definition.
    314 
    315 
    316 Section 5.1.2., paragraph 4:
    317 OLD:
    318 
    319     o  The "token68" notation was introduced for compatibility with
    320        existing authentication schemes and can only be used once per
    321        challenge or credential.  New schemes thus ought to use the "auth-
    322        param" syntax instead, because otherwise future extensions will be
    323        impossible.
    324 
    325 NEW:
    326 
    327     o  The "token68" notation was introduced for compatibility with
    328        existing authentication schemes and can only be used once per
    329        challenge or credential.  Thus, new schemes ought to use the auth-
    330        param syntax instead, because otherwise future extensions will be
    331        impossible.
    332 
    333 
    334 Section 5.1.2., paragraph 5:
    335 OLD:
    336 
    337     o  The parsing of challenges and credentials is defined by this
    338        specification, and cannot be modified by new authentication
    339        schemes.  When the auth-param syntax is used, all parameters ought
    340        to support both token and quoted-string syntax, and syntactical
    341        constraints ought to be defined on the field value after parsing
    342        (i.e., quoted-string processing).  This is necessary so that
    343        recipients can use a generic parser that applies to all
    344        authentication schemes.
    345 
    346 NEW:
    347 
    348     o  The parsing of challenges and credentials is defined by this
    349        specification and cannot be modified by new authentication
    350        schemes.  When the auth-param syntax is used, all parameters ought
    351        to support both token and quoted-string syntax, and syntactical
    352        constraints ought to be defined on the field value after parsing
    353        (i.e., quoted-string processing).  This is necessary so that
    354        recipients can use a generic parser that applies to all
    355        authentication schemes.
    356 
    357 
    358 Section 5.1.2., paragraph 7:
    359 OLD:
    360 
    361     o  Definitions of new schemes ought to define the treatment of
    362        unknown extension parameters.  In general, a "must-ignore" rule is
    363        preferable over "must-understand", because otherwise it will be
    364        hard to introduce new parameters in the presence of legacy
    365        recipients.  Furthermore, it's good to describe the policy for
    366        defining new parameters (such as "update the specification", or
    367        "use this registry").
    368 
    369 NEW:
    370 
    371     o  Definitions of new schemes ought to define the treatment of
    372        unknown extension parameters.  In general, a "must-ignore" rule is
    373        preferable to a "must-understand" rule, because otherwise it will
    374        be hard to introduce new parameters in the presence of legacy
    375        recipients.  Furthermore, it's good to describe the policy for
    376        defining new parameters (such as "update the specification" or
    377        "use this registry").
    378 
    379 
    380 Section 5.1.2., paragraph 9:
    381 OLD:
    382 
    383     o  The credentials carried in an Authorization header field are
    384        specific to the User Agent, and therefore have the same effect on
    385        HTTP caches as the "private" Cache-Control response directive
    386        (Section 5.2.2.6 of [RFC7234]), within the scope of the request
    387        they appear in.
    388 
    389 NEW:
    390 
    391     o  The credentials carried in an Authorization header field are
    392        specific to the user agent and, therefore, have the same effect on
    393        HTTP caches as the "private" Cache-Control response directive
    394        (Section 5.2.2.6 of [RFC7234]), within the scope of the request in
    395        which they appear.
    396212
    397213
Note: See TracChangeset for help on using the changeset viewer.