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

From: [email-masked]
Date: Thu, 10 Feb 2005 15:53:14 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title		: Web Distributed Authoring and Versioning (WebDAV) 
			  Redirect Reference Resources
	Author(s)	: J. Whitehead, et al.
	Filename	: draft-ietf-webdav-redirectref-protocol-11.txt
	Pages		: 34
	Date		: 2005-2-10
	
This specification defines redirect reference resources.  A redirect
   reference resource is a resource whose default response is an HTTP/
   1.1 3xx (Redirection) status code (see RFC2616, Section 10.3),
   redirecting the client to a different resource, the target resource.
   A redirect reference makes it possible to access the target resource
   indirectly, through any URI mapped to the redirect reference
   resource.  There are no integrity guarantees associated with redirect
   reference resources.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-11.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-redirectref-protocol-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Feb 2005 22:25:14 +0100

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

    [email-masked] (2005-02-09): Use ABNF syntax from
    RFC2234.

    Resolution (2005-02-09): Done.

C.2  rfc2396bis

    Type: change

    [email-masked] (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>

    [email-masked] (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

    [email-masked] (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>

    [email-masked] (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