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

Out of curiosity, is this something most servers do or something that most
people have not implemented?


On 10/15/05 12:35 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> 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>

Received on Monday, 17 October 2005 21:25:17 UTC