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/p7-auth.xml

    r2667 r2692  
    179179   token as a means to identify the authentication scheme, followed
    180180   by additional information necessary for achieving authentication via that
    181    scheme. The latter can either be a comma-separated list of parameters or a
     181   scheme. The latter can be either a comma-separated list of parameters or a
    182182   single sequence of characters capable of holding base64-encoded
    183183   information.
     
    271271</t>
    272272<t>
    273    A server that receives valid credentials which are not adequate to gain
     273   A server that receives valid credentials that are not adequate to gain
    274274   access ought to respond with the <x:ref>403 (Forbidden)</x:ref> status
    275275   code (&status.403;).
     
    300300   partitioned into a set of protection spaces, each with its own
    301301   authentication scheme and/or authorization database. The realm value
    302    is a string, generally assigned by the origin server, which can have
     302   is a string, generally assigned by the origin server, that can have
    303303   additional semantics specific to the authentication scheme. Note that a
    304304   response can have multiple challenges with the same auth-scheme but
    305    different realms.
     305   with different realms.
    306306</t>
    307307<t>
     
    355355<t>
    356356   The <x:dfn>407 (Proxy Authentication Required)</x:dfn> status code is
    357    similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the client
     357   similar to <x:ref>401 (Unauthorized)</x:ref>, but it indicates that the client
    358358   needs to authenticate itself in order to use a proxy.
    359359   The proxy &MUST; send a <x:ref>Proxy-Authenticate</x:ref> header field
     
    516516<section title="Authentication Scheme Registry" anchor="authentication.scheme.registry">
    517517<t>
    518    The HTTP Authentication Scheme Registry defines the namespace for the
    519    authentication schemes in challenges and credentials. It will be created and
    520    maintained at (the suggested URI) <eref target="http://www.iana.org/assignments/http-authschemes"/>.
     518   The "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defines the namespace for the
     519   authentication schemes in challenges and credentials. It will has been created
     520   and is now maintained at <eref target="http://www.iana.org/assignments/http-authschemes"/>.
    521521</t>
    522522
     
    557557    <x:lt>
    558558    <t>
    559       The authentication parameter "realm" is reserved for defining Protection
    560       Spaces as defined in <xref target="protection.space"/>. New schemes
     559      The authentication parameter "realm" is reserved for defining protection
     560      spaces as described in <xref target="protection.space"/>. New schemes
    561561      &MUST-NOT; use it in a way incompatible with that definition.
    562562    </t>
     
    566566      The "token68" notation was introduced for compatibility with existing
    567567      authentication schemes and can only be used once per challenge or credential.
    568       New schemes thus ought to use the "auth-param" syntax instead, because
     568      Thus, new schemes ought to use the auth-param syntax instead, because
    569569      otherwise future extensions will be impossible.
    570570    </t>
     
    572572    <x:lt>
    573573    <t>
    574       The parsing of challenges and credentials is defined by this specification,
     574      The parsing of challenges and credentials is defined by this specification
    575575      and cannot be modified by new authentication schemes. When the auth-param
    576576      syntax is used, all parameters ought to support both token and
     
    590590      Definitions of new schemes ought to define the treatment of unknown
    591591      extension parameters. In general, a "must-ignore" rule is preferable
    592       over "must-understand", because otherwise it will be hard to introduce
     592      to a "must-understand" rule, because otherwise it will be hard to introduce
    593593      new parameters in the presence of legacy recipients. Furthermore,
    594594      it's good to describe the policy for defining new parameters (such
    595       as "update the specification", or "use this registry").
     595      as "update the specification" or "use this registry").
    596596    </t>
    597597    </x:lt>
     
    606606    <t>
    607607      The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
    608       the User Agent, and therefore have the same effect on HTTP caches as the
     608      the user agent and, therefore, have the same effect on HTTP caches as the
    609609      "private" Cache-Control response directive (&caching-rsd-private;),
    610       within the scope of the request they appear in.
     610      within the scope of the request in which they appear.
    611611    </t>
    612612    <t>
Note: See TracChangeset for help on using the changeset viewer.