ID

Source

Description

Status

Resolution

1

Eric Sedlar

Weak Bindings:

Add support for weak bindings that are guaranteed not to dangle, but that do not affect reference count.

Closed

Declined.

2

Eric Sedlar

Security and the DAV:bindings property:

State that if the user doesn't have read access to the collection that contains the binding, the binding should not be included in the response to PROPFIND on DAV:bindings. Then 16.4 is not needed.

Closed

Add a note to section 16.4 that a server could implement the policy Eric describes.

3

Eric Sedlar

DAV:resourceid for versioned resources:

Say that if the URL is a versioned resource, and the currently selected revision is changed, the resourceid will not change.

Closed

A statement to this effect has been added to the versioning spec. It won't be added to the binding spec.

4

Yaron Goland

PublishBind:

Don't reference the redirect references spec from the binding spec.

Closed

We will say only that redirect references are specified elsewhere, without cross-referencing the redirect references spec.

5

Yaron Goland

WeScrewedUp:

Attempts to map the terminology of the binding spec to the terminology of WebDAV are difficult and detract from the spec.

Closed

We will move the definition of internal member URIs to an appendix.

Check for other mentions of internal member URIs and remove.

6

Yaron Goland

4Huh?

In section 4, the following sentence is incomprehensible:

"The URI segment associated with a resource by one of a collection's bindings is also the final segment of one or more of the collection's internal member URIs."

(See also WeScrewedUp)

Closed

Section 4:

Delete the first paragraph (which contains the problem sentence).

Move the second paragraph to the introduction.

Rename Section 4 to "Integrity of Bindings" and keep paragraphs 3 and 4 here.

7

Yaron Goland

5.3Huh?

Section 5.3 is incomprehensible. Rewrite it.

Roy agrees that this is obscure.

Closed

Use Geoff’s new language instead of 1^st paragraph.

8

Yaron Goland

5.4Huh?

Section 5.4 is incomprehensible. Rewrite it.

Closed

No change. We think the example will be easier to understand in light of the new language in 5.3.

9

Yaron Goland

507:

Whether the binding would be cross-server or not isn't really the issue. It could also be impossible to create a binding that crosses volumes of the same server.

Closed

We'll use 403.

Make sure it's clear that we're not redefining 403, but just describing a case where it will be returned.

10

Yaron Goland

Insulting2616:

Section 6 paragraph 1 makes statements about the intentions of RFC 2616 concerning the semantics of DELETE. Confirm with the authors of RFC 2616 that these statements are correct.

Closed

Replace the last 3 sentences of the paragraph with Roy's proposed language:

"DELETE in HTTP/1.1 now refers to deletion of any binding, including those created by BIND."

11

Yaron Goland

AtomicDelete:

The requirement that delete be atomic is not acceptable.

1. Interoperability problems with existing WebDAV servers.

2. File systems cannot implement atomic delete.

3. The suggestion that delete be implemented as move to get atomicity is not really feasible.

4. Too expensive to implement in a distributed context.

Open

Geoff send mail with new proposal.

11A

Roy Fielding, Reuter/Hunt

Single operations do not imply atomicity. Atomic implies that nothing else can happen during the processing of the request, which is false for any but the most trivial operations. DELETE is never trivial.

Open

12

Yaron Goland

AtomicMove:

Same as atomic delete.

In addition, many file systems implement move as copy + delete, which makes it yet more difficult for them to implement atomic move.

Open

13

Yaron Goland

NoSlash:

HTTP and WebDAV allow URLs to end in "/", and they allow /a/b/ and /a/b to map to different resources.

Section 5.1 of the binding spec says that the segment in a binding must have its final "/" removed. This conflicts with HTTP and WebDAV.

Open

Geoff sent mail asking whether anyone is depending upon the same URL with and without trailing slash identifying different resources.

IIS, Sharemation ok. Greg Stein and Jim Davis sent mail saying ok.

Jim Whitehead will test other servers before next meeting 3/7.

14

Yaron Goland, Roy Fielding

BindSyntax:

In a BIND, the Request-URI identifies the resource to be bound, and the Destination header identifies the collection / segment.

This will be a problem when weak bindings are added. You can't require the active participation of the target resource in the creation of a weak binding.

Roy objects to the syntax on the general principle that the request URI should identify the point of modification and should determine what server mechanism will handle that namespace – and that this should all be discoverable without interpreting the rest of the request.

Yaron's proposal:

Add a Source header that could be used instead of the Destination header.

Or add language that would leave the door open for a Source header in the future.

Closed

Let the request uri be the collection being operated on, add Binding-Name header, Target header (or Ref-Target) identifies the resource being bound.

Any change to DAV:bindings property doesn't affect etag.

Revise Section 15 on OPTIONS to say that it gets submitted collection, which responds according to whether it allows bindings to be created in it or not.

15

Yaron Goland, Roy Fielding

403:

403 is too vague a response for the case where a BIND is refused because it would create a loop.

Closed

We'll define a new 4xx response code for this case.

16

Yaron Goland, Roy Fielding

ApplePie:

In section 5.1, "After successful processing of a BIND request, it MUST be possible for clients to use the URI in the Destination header to submit requests to the resource identified by the Request-URI."

This doesn't say anything useful. Delete it.

Closed

Remove this sentence.

17

Yaron Goland, Roy Fielding

ApplePieToo:

Don't try to distinguish between static and dynamic resources. There's nothing that can usefully be said in Section 9 beyond the statement that bindings add no new complexity to these methods.

OK to say that when there are multiple bindings to the same resource, requests may be sensitive to which URL is used to access the resource; but don't talk about static/dynamic.

Closed

Use Judy's proposal 1

18

Yaron Goland

ApplePie3:

Section 11 on DAV:bindings appears to be self-contradictory. It says that DAV:bindings must contain a complete list of the bindings, but also that PROPFIND on it returns only the bindings the client is authorized to see.

Closed

Use something like Yaron's proposed language. This means that the property is live and has a different value depending on who is asking.

The property definition in 13.1 also needs revision.

We will not try to make provision for future addition of weak bindings.

Yaron's proposal: something like "A client can rely upon the contents of the DAV:bindings property specifying all bindings for that resource that the client is authorized to know about." Also some qualification that will allow this requirement to be weakened when weak bindings are defined.

19

Yaron Goland

MrIntegrity:

"Integrity" is never defined, so it's impossible to know whether you are complying with the requirement that the integrity of bindings be guaranteed.

Open

Yaron's proposal:

Don't use the word "integrity." Instead, give a series of MUST statements that express the exact requirements we are trying to capture with "integrity."

Won't use "integrity:

Individual constraints on DELETE, MOVE, other operations that overwrite (and so implicitly delete). Say the constraints on what delete, move, etc. are allowed to do (affect only the binding in the request-uri). When create binding, must guarantee these semantics – delete, move, and overwrite.

While a binding in a coll exists, it will always return the same resourceid, won't be affected by delete to another collection

Language about dangling bindings.

Geoff draft new language.

(See his new language for atomic delete – issue 11.)

20

Yaron Goland

BindingsProperty:

It's possible that the DAV:bindings property might be accessible through one URL, but not through another. Say so.

Closed

No changes to spec.

21

Roy Fielding

Integrity:

There should be no requirement that the integrity of bindings be guaranteed.

Open

Discuss further with Roy / mailing list.

See Geoff’s new language for issue 11 atomic delete.

22

Roy Fielding

DELETE on nonempty collection:

Need a status code for use if a request attempts to remove the last binding to a nonempty collection, but the server requires that the collection be emptied before the last binding to it can be removed.

Closed

Will add status code.

23

Roy Fielding

Don't paginate the review draft.

Closed

We will format as required by IETF.

We'll try to produce a nicely formatted draft in addition to the one that meets IETF requirements.

24

Roy Fielding

Don't mention the redirect references spec in the Abstract.

Closed

Will remove cross-reference.

25

Roy Fielding

Move the Notational Conventions section after the Introduction.

Closed

Will move section.

26

Roy Fielding

Don't cross-reference the Redirect References spec from the introduction. Delete the paragraphs that compare bindings with redirect references.

Closed

Get rid of cross-ref.

Won’t explcitly define redirect ref to insure redirect spec is the sole place for that. Use Roy’s language pointing to another unspecified spec.

27

Roy Fielding

The rationale in the Introduction treats resources as storage objects. This is wrong.

It should just try to motivate creation of aliases in one namespace to identifiers in another namespace.

Closed

Do change language so that it doesn’t imply anything about implementation or mention storage.

28

Roy Fielding

The Introduction says that BIND creates new access paths to existing WebDAV resources. It should be to any Web resources, whether they are WebDAV resources or HTTP resources or something else.

Closed

Declined.

We meant just WebDAV resources. RFC 2518 Collection semantics and namespace consistency requirement motivate this.

Check language about PUT etc creating bindings. It does so only if in WebDAv collections.

29

Roy Fielding

Definitions of URI Mapping and Binding are unsatisfactory because:

They depend on a mistaken notion of what a resource is.

They are not sufficiently operational. Focus on what differences a client can see between a URI Mapping and a Binding.

Open

Agreed not to say that a binding is not a resource.

Agreed DAV:resourceid will be replaced by DAV:urn, which will be an optional (SHOULD) property.

Agreed to add a comparison method that determines whether two URIs map to the same resource.

Open till we check whether replacing DAV:resourceid with DAV:urn is acceptable to Roy.

30

Roy Fielding

In Section 4 the discussion of the identity of bindings is not implementable. Definitions should be operational.

Closed

Delete the paragraph on identity of bindings.

31

Roy Fielding

In the absence of the Overwrite header, BIND should fail if the Destination header identifies an existing binding.

Closed

Keep Overwrite header, change default as Roy requests.

32

Roy Fielding

Delete all but the first paragraph of Section 5.2. It's more confusing than helpful. People will figure it out for themselves.

Closed

Declined.

Example is important aid to understanding the first paragraph. We’ll keep it.

33

Roy Fielding

Roy interprets the text after response codes as definitions of the response codes, whereas they are intended as descriptions of circumstances that might cause the server to respond with that code. How to fix this.

Closed

We’ll clarify.

34

Roy Fielding

DELETE and WebDAV:

Don't discuss conflicts with WebDAV in the main body of the spec. Move this to an appendix that discusses how and why bindings differs from WebDAV.

Closed

agreed. We’ll have an appendix devoted to "Reconciliation with the WebDAV Spec."

35

Roy Fielding

DAV:resourceid is not needed for bindings.

If you need a way to determine whether 2 bindings are to the same resource, define a method applied to the collection, not to the individual bindings.

Closed

Declined.

We’ll keep DAV:resourceid.

36

Roy Fielding

There is no need for the resourceid URI scheme. A URI scheme defines a namespace, not a purpose for a namespace. Defining a new URI scheme for each new way that a URI can be used is contrary to the design goals of URI.

Closed

Get rid of section 10.1. We will not propose a new URI Scheme, just reference UUID as one way of generating unique ids that would satisfy the definition of DAV:resourceid.

37

Roy Fielding

Section 16.3 is not describing a denial of service, and is not needed in any case.

Closed

We’ll remove section 16.3.

38

Reuter/Hunt

Don't try to redefine internal member URI. Just state the requirements for what will come back in a PROPFIND request ( a single URI for each resource in its scope).

Closed

Discussion of internal member URI moves to appendix.

We won’t make any requirements about implementation.

We won’t make any statement about whether PROPFIND is allowed to return multiple hrefs for the same resource.

39

Reuter/Hunt

Maybe introduce a header for use with PROPFIND that would ask it to return an href for every URI mapped to each resource in its scope.

Closed

Declined.

40

Reuter/Hunt

Thoroughly specify all server-to-server behavior needed to support cross-server bindings.

Closed

Declined.

WebDAV protocols are client-server, not server-server.

41

Reuter/Hunt

Specify how BIND interacts with a write lock.

Closed

Declined

Locking semantics is in too confused a state currently to be able to make any reliable statements. Don’t want to hold up binding spec till lock settles down.

42

Yaron Goland

NTFS only implements bindings to files, not to collections because of the cost of loop detection. It's likely that if they support WebDAV bindings, they will support them only for files and fail any attempt to create a binding to a collection.

Closed

No changes needed.

43

Geoff Clemm

3/1/2000 teleconf

Rename the DAV:bindings property. We may someday want a property on collections that lists the bindings that are part of their state. Consider names for both properties.

Open

44

Tim Ellison

Provide enough information with a 506 Loop Detected in a multistatus to allow the client to reconstruct the graph.

Example in 12.1 shows only propnames returned for the 506 resource. This is not enough.

Open

45

Tim Ellison

Loops can still result in denial of service even if require detection.

Open