Re: [Bug 18] no record of consensus for force-authenticate

Proposed resolution for 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=18>:

History:

The "force-authenticate" request header was initially proposed by Ilya 
Kirnos, and we had a discussion about this back three years ago 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/thread.html#291>). 
As far as I can tell, the consensus back then was not to define a new 
header, but to make use of an "If" request header that was known to 
alway evaluate to false instead.

In January 2003, the WG had an interim meeting hosted by Apple, during 
which the problem was discussed again. Unfortunately, there doesn't seem 
to be any public record of what was discussed on the second day (which 
AFAIR was the day we discussed this topic). (Minutes for day one in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0075.html>).

The "Force-Authentication" header was then introduced in draft 03 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-03.txt>), 
but I can't find any record of a consensus reached on the mailing list.

I therefore propose to remove the header from the spec, encouraging 
those who feel that this feature is needed to solve a real-world problem 
to restart the discussion on the mailing list (containing a precise 
problem statement, and an analysis why the current spec isn't sufficient 
in this regard).

In addition to removing section 9.4, further changes would be:

Section 17., para. 11:
OLD:

    A resource can explicitly advertise its support for the revisions to
    RFC2518 made in this document.  In particular, this allows clients to
    use the Force-Authentication header on requests.  Class 1 must be
    supported as well.  Class 2 MAY be supported.

NEW:

    A resource can explicitly advertise its support for the revisions to
    RFC2518 made in this document.  Class 1 must be supported as well.
    Class 2 MAY be supported.


Section 17., para. 13:
OLD:

    o  the Force-Authentication header.

    o  Any behavior that it supports, in the manner specified in this
       document, rather than in the manner specified in RFC2518, for all
       client requests.  A server MAY use an older behavior for specific
       clients that are discovered to have interoperability problems with
       the requirements of this specification, but MUST NOT use an older
       behavior indiscriminately.

NEW:

    o  Any behavior that it supports, in the manner specified in this
       document, rather than in the manner specified in RFC2518, for all
       client requests.  A server MAY use an older behavior for specific
       clients that are discovered to have interoperability problems with
       the requirements of this specification, but MUST NOT use an older
       behavior indiscriminately.


Section 21., para. 8:
OLD:

    Valuable contributions to RFC2518 bis came from some already named.
    New contributors must also be gratefully acknowledged.  Julian
    Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out
    specific text on the list or in meetings.  Ilya Kirnos supplied text
    for Force-Authentication header.  Joe Hildebrand contributed as co-
    chair.

NEW:

    Valuable contributions to RFC2518 bis came from some already named.
    New contributors must also be gratefully acknowledged.  Julian
    Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out
    specific text on the list or in meetings.  Joe Hildebrand contributed
    as co-chair.


Best regards, Julian

--- draft-ietf-webdav-rfc2518bis-07.xml	2005-10-15 19:19:46.000000000 +0100
+++ rfc2518bis-08-bug18.xml	2005-10-15 20:29:23.000000000 +0100
@@ -3112,23 +3112,7 @@
    to the remote server using PUT/PROPPATCH or another mechanism. 
     </t>
   </section>
-  
-  <section title="Force-Authentication Header">
-    <t>
-   Force-Authentication = "Force-Authentication" ":" Method 
-    </t>
-    <t>
-   The Force-Authentication request header is used with the OPTIONS method to 
-   specify that the client wants to be challenged for authentication 
-   credentials to the resource identified by the Request-URI.  If 
-   present on a request to a WebDAV-compliant resource, the server MUST 
-   respond with either 401 (Unauthorized) or 501 (Not Implemented) 
-   status code. The Method value is used for the client to indicate 
-   what method it intends to use first on the resource identified in 
-   the Request-URI.  
-    </t>
-  </section>
-  
+    
   <section title="If Header">
     <figure>
       <artwork>
@@ -4832,15 +4816,13 @@
   <section title="Class 'bis'">
     <t>
    A resource can explicitly advertise its support for the revisions to 
-   RFC2518 made in this document. In particular, this allows clients to 
-   use the Force-Authentication header on requests.  Class 1 must be 
+   RFC2518 made in this document.  Class 1 must be 
    supported as well. Class 2 MAY be supported.   
     </t>
     <t>
    A resource that supports bis MUST support: 
     </t>
     <t><list style="symbols">
-      <t>the Force-Authentication header.  </t>
       <t>Any behavior that it supports, in the manner specified in this 
    document, rather than in the manner specified in RFC2518, for all 
    client requests.  A server MAY use an older behavior for specific 
@@ -5200,8 +5182,7 @@
    Valuable contributions to RFC2518 bis came from some already named. 
    New contributors must also be gratefully acknowledged. Julian 
    Reschke, Geoff Clemm, Joel Soderberg, and Dan Brotsky hashed out 
-   specific text on the list or in meetings. Ilya Kirnos supplied text 
-   for Force-Authentication header.  Joe Hildebrand contributed as 
+   specific text on the list or in meetings.  Joe Hildebrand contributed as 
    co-chair.
   </t>
 </section>