Re: I-D ACTION:draft-ietf-webdav-redirectref-protocol-11.txt

This draft revision assembles a set of mainly editorial changes and was 
made so that there's an up-to-date version online in time before the 
next IETF.

Changes are:

    Add and resolve issues "13_allprop" and "rfc2396bis".  Use the term
    "Request-URI" throughout (this is what RFC2616 defines).  Center some
    of the artwork.  Add and resolve issue "abnf".

Closed Issues:

C.1  abnf

    Type: change

    julian.reschke@greenbytes.de (2005-02-09): Use ABNF syntax from
    RFC2234.

    Resolution (2005-02-09): Done.


C.2  rfc2396bis

    Type: change

    julian.reschke@greenbytes.de (2004-10-22): Update to RFC2396bis (this
    needs to be done carefully because we are using the term "relative
    URI reference" which does not exist in RFC2396bis anymore).

    Resolution (2005-01-25): Agreed (draft-rfc2396bis has been published
    as RFC3986).

C.3  13_allprop

    Type: change

    <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/
    0051.html>

    julian.reschke@greenbytes.de (2004-11-13): Make the spec consistent
    with RFC3253, RFC3648 and RFC3744 (new properties not returned upon
    PROPFIND/allprop requests).

    Resolution (2004-11-13): Add statement about PROPFIND/allprop
    behaviour.


Open Issues remaining:

D.1  edit

    Type: edit

    julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for
    editorial changes.

D.2  old_clients

    Type: change

    <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/
    0180.html>

    julian.reschke@greenbytes.de (2003-11-10): There are (at least) two
    major design goals, but unfortunately both are in direct
    contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616).  This
    means that any request that addresses a redirect reference resource
    MUST result in a 3xx status code (obviously the whole point is that
    GET MUST result in a redirection, and if it does, it's hard to say
    why other methods such as PUT or DELETE should behave differently).
    Therefore, the redirect reference protocol introduces a new request
    header ("Apply-To-Redirect-Ref") through which a client can indicate
    that the request indeed should be applied to the redirect reference
    resource itself. #2: Maximum usability with existing clients.  For
    instance, the Microsoft Webfolder client will not be able to DELETE a
    redirect reference resource unless the server deviates from #1.
    Right now I'm not sure about the best way to resolve this.  Currently
    the spec chooses #1 (back when this decision was made, there was
    probably the assumption that existing clients would quickly be
    updated -- something that probably isn't true today).  However this
    may result in implementers either just ignoring these rules, or
    adding special workarounds based on "User Agent" detection.


Best regards, Julian

Received on Thursday, 10 February 2005 21:25:54 UTC