Changeset 311 for draft-ietf-httpbis/orig/rfc2617.xml

Timestamp:

22/08/08 11:56:21 (14 years ago)

Author:

julian.reschke@…

Message:

Update orig RFCs, also add 2145 and 5234

File:

• draft-ietf-httpbis/orig/rfc2617.xml (modified) (10 diffs)

draft-ietf-httpbis/orig/rfc2617.xml

@@ -1 @@
-<?xml version="1.0" encoding="utf-8"?>
+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes"?>
 <?rfc symrefs="no"?>
@@ -20 +21 @@
   <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
 ]>
-<rfc number="2617" category="std" obsoletes="2069" xmlns:x='http://purl.org/net/xml2rfc/ext'>
+<rfc number="2617" category="std" obsoletes="2069" xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:grddl='http://www.w3.org/2003/g/data-view#' grddl:transformation='rfc2629grddl.xslt'>
   <front>
     <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
@@ -147 +148 @@
   <middle>
   
-<section title="Access Authentication" anchor="access.authentication">
+<section title="Access Authentication">
 
 <section title="Reliance on the HTTP/1.1 Specification">
 <t>
    This specification is a companion to the HTTP/1.1 specification <xref target="RFC2616"/>.
-   It uses the augmented BNF section <xref target="RFC2616" x:fmt="number" x:sec="2.1"/> of that document, and relies on
+   It uses the augmented BNF section <xref target="RFC2616" x:fmt="number" x:rel="#notation.abnf"/> of that document, and relies on
    both the non-terminals defined in that document and other aspects of
    the HTTP/1.1 specification.
@@ -206 +207 @@
    authentication schemes that issue a challenge. The realm value
    (case-sensitive), in combination with the canonical root URL (the
-   absoluteURI for the server whose abs_path is empty; see section <xref target="RFC2616" x:fmt="number" x:sec="5.1.2"/>
+   absoluteURI for the server whose abs_path is empty; see section <xref target="RFC2616" x:fmt="number" x:rel="#request-uri"/>
    of <xref target="RFC2616"/>) of the server being accessed, defines the protection space.
    These realms allow the protected resources on a server to be
@@ -273 +274 @@
    authentication by origin servers. That is, they must forward the
    WWW-Authenticate and Authorization headers untouched, and follow the
-   rules found in section <xref target="RFC2616" x:fmt="number" x:sec="14.8"/> of <xref target="RFC2616"/>. Both the Proxy-Authenticate and
+   rules found in section <xref target="RFC2616" x:fmt="number" x:rel="#header.authorization"/> of <xref target="RFC2616"/>. Both the Proxy-Authenticate and
    the Proxy-Authorization header fields are hop-by-hop headers (see
-   section <xref target="RFC2616" x:fmt="number" x:sec="13.5.1"/> of <xref target="RFC2616"/>).
+   section <xref target="RFC2616" x:fmt="number" x:rel="#end-to-end.and.hop-by-hop.headers"/> of <xref target="RFC2616"/>).
 </t>
 </section>
@@ -895 +896 @@
 <t>
    The "Method" value is the HTTP request method as specified in section
-   <xref target="RFC2616" x:fmt="number" x:sec="5.1.1"/> of <xref target="RFC2616"/>. The "request-uri" value is the Request-URI from the
-   request line as specified in section <xref target="RFC2616" x:fmt="number" x:sec="5.1.2"/> of <xref target="RFC2616"/>. This may be "*",
-   an "absoluteURL" or an "abs_path" as specified in section <xref target="RFC2616" x:fmt="number" x:sec="5.1.2"/> of
+   <xref target="RFC2616" x:fmt="number" x:rel="#method"/> of <xref target="RFC2616"/>. The "request-uri" value is the Request-URI from the
+   request line as specified in section <xref target="RFC2616" x:fmt="number" x:rel="#request-uri"/> of <xref target="RFC2616"/>. This may be "*",
+   an "absoluteURL" or an "abs_path" as specified in section <xref target="RFC2616" x:fmt="number" x:rel="#request-uri"/> of
    <xref target="RFC2616"/>, but it &MUST; agree with the Request-URI. In particular, it &MUST;
    be an "absoluteURL" if the Request-URI is an "absoluteURL". The
@@ -918 +919 @@
    Implementers should be aware of how authenticated transactions
    interact with shared caches. The HTTP/1.1 protocol specifies that
-   when a shared cache (see section <xref target="RFC2616" x:fmt="number" x:sec="13.7"/> of <xref target="RFC2616"/>) has received a request
+   when a shared cache (see section <xref target="RFC2616" x:fmt="number" x:rel="#shared.and.non-shared.caches"/> of <xref target="RFC2616"/>) has received a request
    containing an Authorization header and a response from relaying that
    request, it &MUST-NOT; return that response as a reply to any other
-   request, unless one of two Cache-Control (see section <xref target="RFC2616" x:fmt="number" x:sec="14.9"/> of <xref target="RFC2616"/>)
+   request, unless one of two Cache-Control (see section <xref target="RFC2616" x:fmt="number" x:rel="#header.cache-control"/> of <xref target="RFC2616"/>)
    directives was present in the response. If the original response
    included the "must-revalidate" Cache-Control directive, the cache &MAY;
@@ -1270 +1271 @@
    period of time or number of uses, or any other restrictions.  Doing
    so strengthens the protection provided against, for example, replay
-   attacks (see 4.5).  However, it should be noted that the method
+   attacks (see <xref target="replay.attacks" format="counter"/>).  However, it should be noted that the method
    chosen for generating and checking the nonce also has performance and
    resource implications.  For example, a server may choose to allow
@@ -1313 +1314 @@
 </section>
 
-<section title="Replay Attacks">
+<section title="Replay Attacks" anchor="replay.attacks">
 <t>
    A replay attack against Digest authentication would usually be
@@ -1905 +1906 @@
 </front>
 <seriesInfo name="RFC" value="2616"/>
+
+  <x:source href="rfc2616.xml"/>
 </reference>