ID

Source

Description

Status

Disposition

1

Orton

Entity Bodies for Redirect References:

Clarify: Are there 2 resources, one that redirects and one that responds with its own entity body?

Clarify: What is the effect of PUT for a URI that currently maps to a redirect reference?

Closed

Redirect resource MUST NOT have a body.

See also issue 23.

1A

Orton, Reuter

In the definition of MKRESOURCE, "Body" needs to be defined or else terminology changed.

Closed

We will use MKREF instead of MKRESOURCE.

2

Orton

List only new status codes for MKRESOURCE. Don’t discuss previously-defined status codes.

Closed

Follow same practice as in binding spec: for existing status codes, describe new circumstances that might cause them. Make it clear that we are not redefining these codes.

3

Orton, Reuter

Saying that responses to MKRESOURCE SHOULD NOT be cached suggests that there are sometimes good reasons to cache responses. Is this the case?

Closed

Responses to MKREF MUST NOT be cached.

4

Orton

"Standard data container" needs to be defined in the context of MKRESOURCE

Closed

Not relevant once we switch to MKREF.

5

Orton

Inconsistency about whether a "standard data container" can be created with MKRESOURCE or not.

Closed

Not relevant once we switch to MKREF.

6

Orton

Why does the spec talk about relative URIs in DAV:reftarget in MKRESOURCE requests? Is the server required to resolve the relative URI and store it as absolute?

Is the server required to keep DAV:reftarget pointing to the target resource as the reference / target move, or is DAV:reftarget a dead property?

Closed

DAV:reftarget is readonly and present only on redirect references that are also WebDAV resources.

Add a method for setting the target. Change definition of Redirect-Ref header so that it has the target as its value (comes back on all 302 responses).

Server MUST store the target exactly as it is set. It MUST NOT resolve relatives to absolutes and MUST NOT update if target resource moves.

See also issue 17, 43, 50, 57.

7

Reuter

Abstract should discuss only redirect references, not bindings. Expand discussion of redirect references.

Closed

Abstract will discuss only redirect references.

See also issue 34.

8

Reuter

Get rid of cross-references to the binding spec: in the abstract, in the introduction, in the definition of Reference Resource

Closed

Cross-references to bindings will be removed.

See also issue 34.

9

Reuter

Move Notational Conventions after Introduction.

Closed

Section will be moved.

10

Reuter

Change the title of 16.4 so that it is not a sentence.

Closed

Change to "Revealing Private Locations".

11

Reuter

Don’t paginate the review draft.

Closed

We will paginate in accordance with IETF rules, but will try to produce a nicely formatted review spec as well.

12

Reuter

First 3 paragraphs of Introduction are identical to those in binding spec. Make sure that any changes made there are also incorporated here.

Closed

These paragraphs will change as necessary to make the redirect spec completely independent of the rest of WebDAV.

13

Reuter

Intro, para 4: Change "usually" to "possibly" in the sentence "A redirect reference resource is a resource in one collection whose purpose is to forward requests to another resource (its target), usually in a different collection."

Closed

Agreed.

14

Reuter

Limit the discussion of bindings to just what is needed to understand the differences from redirect references. Maybe the paragraph in the Intro that starts "By contrast, a BIND request . . ." is all that is needed.

Closed

Get rid of discussion of bindings altogether.

See also issue 34, 35.

15

Reuter

Don’t define Direct Reference Resource, since direct references are out of scope. (If you do keep the definition, say explicitly that a direct reference resource is a type of reference resource.)

Closed

Remove definition of Direct Reference Resource.

See also issue 39.

16

Reuter

Section 4, para 2: Change "It is also what insures" to "It is also what helps to insure".

Closed

Agreed.

17

Reuter

Section 4, para 3: Clients should use the Location header, not the DAV:reftarget property, to find the location of the target.

The purpose of the DAV:reftarget property should be to let the client update its value.

Closed

We need both Location (which is absolute) and target (which may be relative).

See also issue 6, 43.

18

Reuter

Need a registration procedure for resource types to insure interoperability.

Closed

We won’t hold up this spec to establish a registration procedure. We will mention in IANA considerations that as the number of resource types grows the need for a registration procedure increases, but that there is none at this time.

19

Reuter

Section 4, para 5 and Section 6, para 3 discussions of the Apply-to-Redirect-Ref header make it sound as if we are specifying direct reference behavior.

Closed

Change these passages so that the contrast is between applying the method to the redirect reference and responding with a 302.

20

Reuter

Section 5: Start with "The new MKRESOURCE method" to make it clear that it is being introduced for the first time here.

Closed

Say "The MKREF method defined normatively here . . ."

21

Reuter

Get rid of the binding-dependent language in the last para of Section 5.

Closed

Delete all but the first sentence in this paragraph.

22

Reuter

Inconsistency about whether collections can be created with MKRESOURCE.

Closed

Not relevant for MKREF.

23

Reuter

Section 5.1: Get rid of the statement that the body of the resource is empty (PostConditions). It would be good if the response to GET included a response body that could be shown to a user by a client that doesn’t do automatic redirection.

There is a related problem in Section 6 on PUT. It is wrong to assume that what is PUT to a resource is what GET will return. In Section 6, say "A PUT with Apply-To-RR MAY contain a request body. The semantics of the request body is out of scope for this specification…"

Also fix the discussion of example 6.2.

Closed

Redirect references cannot have bodies.

GET with Apply-To-RR MUST fail with 403.

PUT with Apply-To-RR MUST fail with 403.

See also issue 1.

24

Reuter

Section 5.1: Replace the sentence "The properties of the new resource are as specified by the DAV:propertyupdate request body, using PROPPATCH semantics" with the following:

"The MKRESOURCE request MAY contain a DAV:propertyupdate request body to initialize resource properties. Herein, the semantics is the same as when sending a MKRESOURCE request without a request body, followed by a PROPPATCH with the DAV:propertyupdate request body."

Closed

No longer relevant once we switch to MKREF with no request body.

25

Reuter

Is MKRESOURCE atomic as viewed by a client? Can another client access the new resource’s properties before they have been fully initialized?

Maybe the MKRESOURCE request should let the client ask for it to be atomic.

Closed

No longer relevant once we switch to MKREF with no request body.

26

Reuter

Change "is not created" to "was not created" in para 4 under Postconditions of MKRESOURCE.

Closed

Editor’s discretion

27

Reuter

Section 6: Change "non-referencing-aware clients" to "clients not aware of this protocol".

Closed

Editor’s discretion

28

Reuter

Section 6: Get rid of the sentence "A reference-aware WebDAV client can act on this response in one of two ways." A client can act on the response in any way it wants.

Closed

Agreed.

See also issue 48.

29

Reuter

Section 6, para 4: Obvious, doesn’t need to be stated. Maybe note in an example.

Closed

Agreed.

See also issue 48.

30

Reuter

Section 6, "When Apply-To-RR is used with GET or HEAD…" Either give a precise list of the headers that MUST be returned, or change MUST to SHOULD with the list of examples.

Closed

Delete "along with all HTTP headers that make sense for reference resources (for example, Cache-Control, Age, Etag, Expires, and Last-Modified)."

See also issue 48.

31

Reuter

Section 6, para on MKRESOURCE and MKCOL is obvious and doesn’t need to be stated. Maybe show in an example.

Closed

Agreed.

See also issue 48.

32

Reuter

Section 6. Don’t talk about ORDERPATCH, since it hasn’t been specified anywhere.

Closed

Agreed.

See also issue 48.

33

Yaron

Forwarding:

Replace "forward" with "redirect" throughout.

Closed

Use "redirect" for the behavior redirect resources do exhibit. Use "forward" for the contrasting behavior (passing a method on to the target with no client action needed). Define these two terms.

See also issue 40.

34

Yaron

NoBind:

Remove all cross-references to the binding spec. Prefer also removing all mention of bindings.

Closed

Agreed.

See also issues 7, 8, 14.

35

Yaron

ReallyNoBind:

Remove paras. 6 and 8 from Intro.

Closed

Agreed.

See also issue 14.

36

Yaron

Servers:

Replace "server" with "unrelated system" throughout.

Closed

Try replacing "server" with "host" in some contexts, rephrasing in passive voice in others.

See also issue 40.

37

Yaron

Integrity:

Intro, para 7 "Servers are not required to enforce the integrity of redirect references." Integrity is not defined. Replace with something clearer.

Closed

Rewrite to say that the server MUST NOT update the target

See also issue 6.

38

Yaron

Not Hierarchical:

The first sentence of the second paragraph of the introduction of the redirect spec asserts that the URIs of WebDAV compliant resources match to collections. The WebDAV standard makes no such requirement. I therefore move that this sentence be stricken.

Closed

State the more general HTTP rationale first (alternative names for the same resource), then introduce the collection hierarchy rationale, which applies only if you are in a WebDAV-compliant space.

39

Yaron

NoReferenceOrDirectResource:

Remove the definitions of "Reference" and "Direct Reference Resource."

Change the definition of "Redirect Reference Resource" to be:

Redirect Resource: A resource created to redirect all requests made to it, using 302 (Found), to a defined target resource.

Closed

Agreed.

See also issue 15.

40

Yaron

4^th2nd:

Assorted changes to Section 4, para 2 to get rid of the word "forward" and the word "server" and remove comparison with direct references.

Closed

See also issue 33 (forward).

See also issue 36 (server).

Remove discussion of direct references.

41

Yaron

NoWebdav#1:

Make redirect references independent of the rest of WebDAV. The creation method for redirect references shouldn’t require an XML request body.

Closed

We will make redirect references independent of the rest of WebDAV.

MKREF will not have an XML request body.

42

Yaron

NoWebDAV#2:

Use a creation method that creates only redirect references.

The MKRESOURCE method hinders experiment because a user of a server who wishes to add support for the creation of a new resource type can't simply throw in another Apache module and allow it to provide the code for the new resource type. They have to find the code used for MKRESOURCE and change it to support the new resource type.

Closed

We will replace MKRESOURCE with MKREF, which creates only redirect reference resources.

43

Yaron

NoWebDAV#3:

Get rid of the DAV:reftarget property.

Closed

DAV:reftarget is readonly and is present only for redirect references that are also WebDAV resources.

We’ll also have a method for setting target; Redirect-Ref header (returned on all 302 responses) will have the target as its value.

See also issue 6, 17, 50.

44

Yaron

NoPropsIn207:

Instead of adding an optional prop XML element to the response element in 207 responses, define a new location XML element and a new refresource XML element.

Open

Agree to define new XML elements that are not pseudo-properties.

Disagreement about whether refresource is needed.

See issue 61.

45

Yaron

Sec4LastPar:

Suggested replacement text for this paragraph, which briefly introduces Apply-To-Redirect-Ref.

Includes a note that even with this header, the response may be a 302.

Closed

See issue 19 for replacement text.

Disagree. Redirect reference will never respond to Apply-To-RR with 302.

46

Yaron

S5P2S23:

Remove dependency on bindings from second paragraph of section 5.

Closed

Agreed.

47

Yaron

Errors:

In line with his wish to get rid of the request message body of MKRESOURCE, 207 would not be an appropriate response code.

The description of 409 might lead someone to believe that you can’t create redirect references outside of WebDAV namespaces. Suggests a different description.

Closed

No longer relevant – MKREF can’t get a 207 response.

Revise to make it clear that the first condition will only occur in WebDAV-compliant namespaces.

48

Yaron

S6:

Replace all of section 6 with just this:

A redirect resource, upon receiving a request without an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found) response. The 302 (Found) response MUST include a location header identifying the target and a Redirect-Ref header.

If a redirect resource receives a request with an Apply-To-Redirect-Ref header then the redirect reference resource MUST apply the method to itself rather than blindly returning a 302 (Found) response.

Closed

Keep a summary along the lines of Yaron’s proposal (don’t use the word "blindly").

Keep the bullets detailing the headers to be returned.

Delete the rest, including the examples.

See also issue 28, 29, 30, 31, 32.

49

Yaron

PUT:

Remove the last sentence of Example 6.2, which says that PUT replaces the reference with a different resource.

Closed

No longer relevant. Deleted this example in response to issue 48.

50

Yaron

BlindRedirect:

Replace current language explaining the purpose of the Redirect-Ref header with language that simply states that it marks blind 302 responses from redirect resources. (Section 6.3, 11.1)

Closed

Section 6.3 was removed in response to issue 48.

In 11.1, change the definition of the Redirect-Ref header to have the value of the target (relative URI) as its value. Then we don’t need a method for retrieving the target’s relative URI. Presence of the Redirect-Ref header lets the client know that the resource accepts Apply-To-RR header and the new method for updating target.

Reject Yaron’s suggested language, but make the above changes.

51

Yaron

S7P1:

The first sentence of this paragraph says only what’s clear from RFC 2518, so will cause confusion by its presence. Delete it.

The last sentence of this paragraph lists methods. That’s a bad idea. Remove it.

Closed

Delete entire paragraph.

52

Yaron

NoRelative:

Don’t allow relative URIs. Delete section 9.

Closed

Declined. Some applications need relative URI.

53

Yaron

S10:

The behavior described in this section would have a very serious impact on the efficiency of mapping Request-URIs to resources in HTTP request processing.

Also specify another type of redirect resource that does not behave as in section 10, but instead would "expose the behavior we see today in various HTTP servers that allow their users to create 300 resources." Be sure we know what behavior will be if the redirect location is not an HTTP URL, but, say ftp.

Closed

We won’t define 2 sorts of redirect references here.

Servers SHOULD respond with 302 as described here, but if they can’t do that, respond with 404 Not Found.

(It’s hard to modularize the behavior specified – it impacts processing Not Found cases of all methods, so you can’t just add it to an HTTP server in a redirect ref module.)

54

Yaron

S10:

The Note: in section 10 has the same problem pointed out in Bindings.NoSlash and needs to be fixed. It contradicts RFC 2518 and 2616, which both assume that a URL and the same URL + "/" may map to different resources.

Closed

Agreed in mailing list discussions that no change is needed.

55

Yaron

BeKindToIANA:

Expand the IANA section to list all methods, headers, XML elements, MIME types, URL schemes, etc., defined by the spec.

Closed

Agreed.

56

Yaron

NotJustHTTP:

Make it clear in examples and text that the redirection URI could be non-HTTP.

Closed

We agree that it is possible to create redirect references to non-HTTP resources.

Add example.

57

Yaron

NoAutoUpdate:

Add language to forbid servers from automatically updating redirect resources when their targets move.

Closed

Agreed.

See also issue 6.

58

Yaron

ClientUpdate:

There needs to be a way to update the target of a redirect reference.

Closed

Agreed.

See also issues 6, 43.

59

Reuter

Section 7: When a method is being applied to a collection with Depth > 0, let Apply-To-Redirect-Ref contain a list of URIs. This way you could have it apply to some subset of the redirect references in the collection.

Closed

Declined.

Too complex, no use case for it.

60

Reuter

Section 7, para 3: Make it clear that these are just examples of client behavior, and are not meant to limit the client’s behavior to these options.

Open

Agreed to delete this paragraph.

Continue discussion of what information should be returned with 302 in multistatus. Just location? Also redirectref?

61

Reuter

Section 7: It doesn’t make sense to ask future editors of RFC 2518 to define DAV:location with the semantics it has here.

RFC 2518 should provide the information in the Location header somehow in multistatus responses, but not by using properties.

Closed

Define an XML element for location that is not a pseudo-property.

We’ll keep the recommendation that RFC 2518 add this for 302 responses.

See also issue 44.

62

Reuter

Section 7: It’s too strong to claim that non-referencing clients can’t process 302 responses occurring in Multi-Status responses. They just have an extra round trip for each 302.

Closed

Remove last sentence of the paragraph that recommends changes to RFC 2518.

63

Reuter

Section 7.1: Is MOVE atomic from the perspective of a client?

Agrees that there should be no 302s for member redirect references, but finds the rationale dubious.

Closed

Remove 7.1.

Reword 7.2 to avoid concerns with "poses special problems" and "due to atomicity".

64

Reuter

Perhaps make DAV:location a real property, instead of DAV:reftarget, and require it to be an absolute URI.

Closed

Declined. Some applications need relative URI.

See also issue 52.

65

Reuter

"In the case of a redirect reference resource, I think the intended meaning of WebDAV is that the resource itself is the internal member to be locked, not the target resource. In so far, I think, the Apply-To-Redirect-Ref header should implicitly always be set, and a LOCK request for a collection MUST fail if in the hierarchy of collections there is an ordinary redirect reference as internal member."

Closed

Declined.

Behavior will be the same for all methods. No exceptions. Consistency / simplicity override other considerations.

66

Reuter

7.3, 7.4: Change "Depth=infinity" to "Depth: infinity".

Closed

Agreed.

67

Reuter

7.4: The explanation should not contrast displaying the properties of the redirect ref with displaying the properties of its target, but with returning a 302.

Closed

Revise as recommended.

68

Reuter

7.6:

The LOCK example responds with 207, as does the example in RFC 2518, but section 8.10.4 of RFC 2518 says if the lock cannot be granted to all resources the response MUST be 409 conflict.

Closed

We’ll keep 207 and encourage RFC 2518 to say the same.

(This inconsistency in RFC 2518 is on the WebDAV issues list.)

69

Reuter

7.6:

Thinks there should not be 424 returned for diary.html because it is not an ancestor of a member that caused the lock to fail.

Closed

No change needed. The interpretation of "dependency" in the example is correct. It doesn’t have to do with ancestor relationship, only with what caused operation to fail.

70

Reuter

Section 9, para 1:

Maybe say that the resulting absolute URI could be any of a number of URIs, depending on which URI is used in the request to identify the redirect reference.

Closed

No change needed.

71

Reuter

Section 9:

Base URI should be the Request-URI or href minus its final segment.

Closed

Fix this.

72

Reuter

Section 10:

Forbid DAV:reftarget from ending in "/"

Closed

Make the note warn about the possibility of two slashes in a row, recommend against ending target with a slash, since that could result in two slashes in a row.

73

Reuter

Section 10:

Replace the ascii art with Juergen’s suggestion (see his message).

Open

74

Reuter

Section 11.1:

"plain HTTP/1.1 redirect" – find some good name for this an use it consistently

Open

75

Reuter

11.2:

"If the Apply-To-Redirect-Ref header is used on a request to any other sort of resource besides a redirect reference resource, the server SHOULD ignore it."

Don’t need to say this since HTP already says that any header that is not understood should be ignored.

Open

76

Reuter

12.2:

Make DAV:location a real (live) property, get rid of the DAV:reftarget property

Open

77

Reuter

Section 16:

Change "WebDAV applications" to "applications that implement this protocol".

Open

78

Reuter

Section 16.4:

Change "directory" to "collection".

Not new to this protocol. Holds for any protocol that has hierarchical access paths.

Open

79

Reuter

Section 16.4:

"In some environments, the owner of a resource might be able to use access control to prevent others from creating references to that resource."

That would not be consistent with the concept of redirect references as weak links (e.g. think of moving a resource to a different locationo that is already the target of some redirection reference.

Open

80

Reuter

Section 17:

Could get rid of a lot of this section, since this protocol extends WebDAV. Just reference [WebDAV].

Open

81

Reuter

Section 17:

Typo "As in [WebDAV}"

Open

82

Reuter

Section 18:

Just reference [WebDAV] and say this protocol does not introduce any new considerations.

Open

83

Reuter

References:

Get rid of the reference to the bindings spec.

Open

84

Reuter

Appendix 24.1:

This is not an extension but a replacement for the WebDAV definition of the response element.

Open

85

Jim Whitehead

3/1/2000 teleconf

Support creation of other than 302 redirects, especially 301.

Open