Subject: ID: draft-ietf-webdav-bind-05

From: Joe Hildebrand <[email-masked]>
Date: Tue, 22 Jun 2004 22:53:43 -0400

In the interest of trying to get things moving on BIND, I've got some 
review comments.  I'm unburdened by knowing where the WG has already 
achieved consensus, so please let me know if I step on something 
unintentionally.

Meta:
  - Who is maintaining the webdav.org site for specs?  The latest draft 
for bind there is -02.
  - Is the canonical issue list the one at webdav.org?  It looks like it 
was last updated almost a year ago.

1.1
  - 'DAV:' is a namespace URI, not a namespace name.
  - Path segment being the characters found *between* slashes is 
confusing, since the last piece  of a URL is also a segment.

1.3
  - Is the first paragraph meant to be an exhaustive list of error 
codes?  Wouldn't 404 be more appropriate for (DAV:bind-source-exists) 
failing, for example?
  - Second paragraph: how might I otherwise negotiate?  The DAV:bind 
header?

2.1
- I can't find a good reference for the 506 error code. It's not in 
2616 or 2518, and is not mentioned by any of the pointers at 
http://www.iana.org/assignments/http-status-codes.  Is this a candidate 
for the IANA considerations, or are we missing a normative reference?

2.2
  - first sentence doesn't parse.  I think it was supposed to be "to 
resource R *is* to be added"

2.3
  - last paragraph is a little confusing.  I'm not seeing the timeline 
of a COPY request that may have partially succeeded.  Perhaps this is 
just unclear pronoun references, and too may copies of "copy" in one 
sentence... :)

2.5
  - last paragraph is a repeat of text two paragraphs before
  - if I'm understanding this right, MOVE is the same as REBIND, except 
for atomicity guarantees.  since we've got the same sort of issue for 
UNBIND/DELETE, isn't it possible a client could figure out that the 
server supports bind (using the DAV: header), specify an 'Atomic: T' 
header, and save us from creating two HTTP methods?  I know that 
creating http methods doesn't have the same stigma in this group as in 
others, and I don't feel strongly about this one, just trying to 
understand the design choice, since it looks like this was tracked with 
the ATOMIC issue.

3.2 (and others)
  - Should all of the DTD be gathered into a single place in an appendix 
(like 23.1 of 2518)?  Is it time to think about schema, as well?

4 (and others)
  - (DAV:locked-update-allowed) what if the resource is locked?  I 
understand that this is a property of the resource, not the binding, 
but since 2518 doesn't say anything about bindings, I think we could 
use a paragraph at some point that spells this out explicitly.  Perhaps 
another sub-section in section 2?
  - Is this what 4_LOCK_BEHAVIOR refers to?  "Done" as the resolution 
doesn't give me quite enough to go on...	

7.1
  - IANA notification for 208?

7.1.1
  - I think this would be clearer if it included D:resource-id in the 
request and response, so you could tell where the loop happened.  Are 
resource-id's likely to be costly to return?

8.2
  - The DAV: request header only has peripheral importance to this spec. 
  This is just the first place it was needed.  Is it too late for this 
to go into 2518bis, instead?  Seems to be a layering problem.  No 
matter where it ends up, we ought to think about IANA registration of 
these compliance class names.

8.2.1
  - last paragraph "it's" -> "its"

11
  - Isn't there an IANA registry for HTTP methods and request headers?  
I don't see one.  If there was one I'd want to add BIND, UNBIND, 
REBIND, and DAV:.
  - the other IANA actions i've listed above

5.1_LOOP_STATUS
  - Is there anything left to do on this?

Sorry some of these are nit-picky.

-- 
Joe Hildebrand
Denver, CO, USA

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 09:51:33 +0200

> achieved consensus, so please let me know if I step on something 

Joe, thanks for doing the review. This is what we need to finally get 
back to make progress.

>  - Who is maintaining the webdav.org site for specs?  The latest draft 

Not me. I'd love to be able to update it, but I can't. In the meantime, 
the current edits are in

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html>

and the current issues lists lives at:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>.

> was last updated almost a year ago.

Nope. See above.

>  - 'DAV:' is a namespace URI, not a namespace name.

As far as I can tell, both terms are used interchamgeably. "namespace 
name" is the one defined in the XMLNS rec: 
<http://www.w3.org/TR/REC-xml-names/#dt-NSName>.

> confusing, since the last piece  of a URL is also a segment.

That term is defined that way in 
<http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.3.3>.

> codes?  Wouldn't 404 be more appropriate for (DAV:bind-source-exists) 

a) no, it's not exhaustive,

b) and no, 404 would be incorrect because it should only occur when 
there's a problem with the resource identified by the Request-URI 
(<http://greenbytes.de/tech/webdav/rfc2616.html#status.404>):

" The server has not found anything matching the Request-URI. No 
indication is given of whether the condition is temporary or permanent. 
The 410 (Gone) status code SHOULD be used if the server knows, through 
some internally configurable mechanism, that an old resource is 
permanently unavailable and has no forwarding address. This status code 
is commonly used when the server does not wish to reveal exactly why the 
request has been refused, or when no other response is applicable."

>  - Second paragraph: how might I otherwise negotiate?  The DAV:bind header?

Good point. As far as I can tell, this text was inherited from RFC3253 
(<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.6>). 
Geoff, do you remember what this is supposed to mean? Can/should we 
clarify that?

> 2.1
> - I can't find a good reference for the 506 error code. It's not in 2616 
> or 2518, and is not mentioned by any of the pointers at 

This is a new status code (it appears under "Additional Status Codes", 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.7.2>).

Last time I checked the IETF instructions for "IANA considerations", I 
got the impression that it's reserved for declaring *new* registries 
that the IANA needs to take care of, not adding new items to existing 
registries (such as HTTP method names, headers or status codes). Can you 
point to a normative document that clarifies?

> resource R *is* to be added"

Ok.

> 2.3
>  - last paragraph is a little confusing.  I'm not seeing the timeline of 
> a COPY request that may have partially succeeded.  Perhaps this is just 
> unclear pronoun references, and too may copies of "copy" in one 
> sentence... :)

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.3.p.5>:

"If a COPY request would cause a new resource to be created as a copy of 
an existing resource, and that COPY request has already created a copy 
of that existing resource, the COPY request instead creates another 
binding to the previous copy, instead of creating a new resource."

What this says is that while copying, the COPY request should try to 
preserve the source structure (like in a filesystem copy where an 
operation may want to try to preserve existing hard links rather than 
creating additional files). Any proposal how this can be made clearer?

>  - last paragraph is a repeat of text two paragraphs before

ok (it's just the first sentence, though).

> understand the design choice, since it looks like this was tracked with 

Almost. The issue here is that RFC2518 allows MOVE to be implemented as 
a COPY/DELETE sequence. That sequence wouldn't preserve for instance the 
DAV:resource-id property as required. So there are more differences, and 
as some people weren't happy with adding new requirements/restrictions 
to MOVE, the WG choose to add a separate method.

Note that a server can always do a "best effort" MOVE, but would have to 
reject the REBIND request when it can't do it "properly" (in particular, 
preserving (almost) all live properties).

> (like 23.1 of 2518)?  Is it time to think about schema, as well?

This is a permathread (I think last time we had that back last summer). 
My take:

- the DTD fragments are there as a short notation; however WebDAV 
messages never ever can be validated using a DTD, so it's unclear what 
we gain by repeating the information in a second place in the spec (for 
the same reason it was removed from RFC2518bis)

- *if* we change notation, I'd vote for one that (1) is easy to read and 
(2) can *indeed* validate WebDAV XML messages. XML Schema can't due to 
the extensibility model we use. RelaxNG could. See 
<http://greenbytes.de/tech/webdav/rfc3470.html#rfc.section.4.7> for more 
information on this topic.

Specs that extend RFC2518 (such as earlier ACL and ORDERED-COLLECTIONS) 
should stick with RFC2518's format. If we want to change this, we should 
  do this while upgrading RFC2518 itself.

> understand that this is a property of the resource, not the binding, but 
> since 2518 doesn't say anything about bindings, I think we could use a 
> paragraph at some point that spells this out explicitly.  Perhaps 

That's incorrect. In particular, 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3> says:

"A resource may be made available through more than one URI. However 
locks apply to resources, not URIs. Therefore a LOCK request on a 
resource MUST NOT succeed if can not be honored by all the URIs through 
which the resource is addressable."

That being said, a large amount of the open issues raised against 
RFC2518 are about locking semantics. The authors of the BIND spec feel 
that it's a bad idea to try to clarify locking semantics in a document 
that's completely independant and optional. Locking semantics should be 
fully defined in a single place.

One way to do this is to wait for RFC2518bis. Another one is to factor 
out locking from the base protocol, and publish this as "update" to 
RFC2518 (at "proposed" level), and let the BIND spec refer to that. This 
is what I'm currently working on (and I'm planning to submit a complete 
rewrite in time before the IETF meeting).

I've summarized the issue at 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html>. 
   So far, I've seen many people agree, and it would be really good if 
the working group would come to a decision on this matter.

> doesn't give me quite enough to go on...

No, I think that was a separate issue. We may want to go through the 
original message 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0200.html>) 
and make sure all things are indeed answered.

>  - IANA notification for 208?

See dicussion above (same for 506).

> resource-id's likely to be costly to return?

No, they should be cheap. I think we should update the example accordingly.

>  This is just the first place it was needed.  Is it too late for this to 
> go into 2518bis, instead?  Seems to be a layering problem.  No matter 
> where it ends up, we ought to think about IANA registration of these 
> compliance class names.

It is in RFC2518bis, but the authors of RFC2518bis have repeatedly made 
clear that they don't have any estimate about when RFC2518bis will be 
done, and thus BIND should not rely in any way on RFC2518bis' contents.

>  - last paragraph "it's" -> "its"

Ok.

> 11
>  - Isn't there an IANA registry for HTTP methods and request headers?  I 
> don't see one.  If there was one I'd want to add BIND, UNBIND, REBIND, 
> and DAV:.

I think this is work-in-progress.

>  - the other IANA actions i've listed above

Yes, we need to clarify those.

>  - Is there anything left to do on this?

No, see latest issues list.

> Sorry some of these are nit-picky.

No reason to. As a matter of fact, this kind of review is what we need. 
Let's try to get things moving so that we can get back on track (BIND 
was supposed to be last-called in May according to the just updated 
working group charter).

Best regards. Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 13:05:20 +0200

Hi,

I have updated
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
and <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>
with some of Joe's issues.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 23 Jun 2004 07:11:54 -0400

> > for bind there is -02.

That would be me ... it should be up-to-date now (with the latest 
information
from Julian's site).  In particular, I've linked the issues list directly
to Julian's issues list, since he's maintaining that document.  Also, I've
made a copy of Julian's "latest" and made it version 05.1.

header?
> Geoff, do you remember what this is supposed to mean? Can/should we 

This is just a placeholder for our deciding to marshal things differently.
In particular, suppose we had a request header that specified "return 
error
information in html format" (that was contemplated at one time).  Then the
error info would be marshalled as html in the response body, rather than 
in the xml format that is used by default.

> No, they should be cheap. I think we should update the example 
accordingly.

I agree.

> No reason to. As a matter of fact, this kind of review is what we need. 

Definitely.  Since we are (or should be) at last call, now's the time
to nit-pick.

> was supposed to be last-called in May according to the just updated 

Yes!

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 13:33:19 +0200

Geoffrey M Clemm wrote:

> ...
> In particular, suppose we had a request header that specified "return error

So should we change anything here to clarify?

>  > No, they should be cheap. I think we should update the example 

-> 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.7.1.1_add_resource_id>

> ..

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 23 Jun 2004 07:49:24 -0400

error
> So should we change anything here to clarify?

I can't think of anything very sensible to add here, without speculating 
about what these other marshalling mechanisms might be (which doesn't seem
like something that should appear in the spec).

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 16:21:59 +0200

> like something that should appear in the spec).

Joe, is that explanation sufficient, or do you think we need to rewrite 
that statement in some way?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 18:09:47 +0200

Geoff,

looking at 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.5_language>...

Can we remove the first sentence from the last paragraph 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.5.p.6>) 
without losing semantics?

Or is there another simple way to avoid the repeating "Although 
[RFC2518] allows a MOVE on a collection to be a non-atomic operation, a 
MOVE implemented as a REBIND MUST be atomic."? (the same statement was 
already made in a more general way two paragraphs earlier).

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 Jun 2004 10:11:33 -0700

>  - 'DAV:' is a namespace URI, not a namespace name.

I think it might be more accurate to say that dav: is a URI
scheme.  See http://www.iana.org/assignments/uri-schemes.
So the following statement in 1.1: "all XML elements defined by this
specification use the XML namespace name "DAV:" might be
re-written as "The XML namespaces used in this document all
use the DAV: uri scheme".

Just my personal opinion,
			regards,
				Ted Hardie

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 23 Jun 2004 13:35:11 -0400

Yes, we can simplify that.  In particular, I would just move
the second sentence of the last paragraph to the end of the second 
paragraph,
and then delete the rest of the last paragraph. 

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 20:16:56 +0200

> Just my personal opinion,

Ted,

as a matter of fact, "DAV:" isn't a URI at all (as RFC2396 doesn't allow 
empty scheme-specific parts). Only RFC2396bis will actually make "DAV:" 
a legal URI.

You're proposed change however is inaccurate -- the specification itself 
  uses a single namespace, and that namespace has the name "DAV:". So I 
think there's really nothing that needs to change.

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 Jun 2004 11:23:44 -0700

Julian,
	I didn't say "dav:" was a URI, I said it was a URI
_scheme_; see the URI scheme assignments maintained by
IANA I referenced below.  The namespaces used in the bind
draft fall into the DAV: uri scheme if you require
they begin "dav:".
			regards,
				Ted Hardie

At 8:16 PM +0200 6/23/04, Julian Reschke wrote:
>as a matter of fact, "DAV:" isn't a URI at all (as RFC2396 doesn't 
>allow empty scheme-specific parts). Only RFC2396bis will actually 
>make "DAV:" a legal URI.
>
>You're proposed change however is inaccurate -- the specification 
>itself  uses a single namespace, and that namespace has the name 
>"DAV:". So I think there's really nothing that needs to change.
>
>Best regards, Julian
>
>
>--

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 20:27:36 +0200

> and then delete the rest of the last paragraph.  

OK, here's the section after the simplification:

2.5  MOVE and Bindings

    When MOVE is applied to a resource, the other bindings to that
    resource MUST be unaffected, and if the resource being moved is a
    collection, the bindings to any members of that collection MUST be
    unaffected.  Also, if MOVE is used with Overwrite:T to delete an
    existing resource, the constraints specified for DELETE apply.

    If the destination collection of a MOVE request supports the REBIND
    method (see Section 6), a MOVE of a resource into that collection MAY
    be implemented as a REBIND request.  Although [RFC2518] allows a MOVE
    to be a non-atomic operation, when the MOVE operation is implemented
    as a REBIND, the operation is atomic.  In particular, applying a MOVE
    to a Request-URI and a Destination URI has the effect of removing a
    binding to a resource (at the Request-URI), and creating a new
    binding to that resource (at the Destination URI).

    As an example, suppose that a MOVE is issued to URI-3 for resource R
    below (which is also mapped to URI-1 and URI-2), with the Destination
    header set to URI-X.  After successful completion of the MOVE
    operation, a new binding has been created which creates the URI
    mapping between URI-X and resource R.  The binding corresponding to
    the final segment of URI-3 has been removed, which also causes the
    URI mapping between URI-3 and R to be removed.  If resource R were a
    collection, old URI-3 based mappings to members of R would have been
    removed, and new URI-X based mappings to members of R would have been
    created.  Even when the Request-URI identifies a collection, the MOVE
    operation involves only removing one binding to that collection and
    adding another.

    >> Before Request:

     URI-1   URI-2    URI-3
       |       |        |
       |       |        |      <---- URI Mappings
       |       |        |
    +---------------------+
    |     Resource R      |
    +---------------------+

    >> After Request:

     URI-1   URI-2    URI-X
       |       |        |
       |       |        |      <---- URI Mappings
       |       |        |
    +---------------------+
    |     Resource R      |
    +---------------------+

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 20:31:19 +0200

>     I didn't say "dav:" was a URI, I said it was a URI

I know you didn't say that. I just wanted to point out, that, in order 
to be a legal namespace name, "DAV:" would *need* to be a legal URI. 
Unfortunately it isn't.

> draft fall into the DAV: uri scheme if you require

But the BIND spec isn't defining any new namespaces, and the only XML 
namespace is uses is just the one named "DAV:" (defined in RFC2518).

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 Jun 2004 12:37:11 -0700

At 8:31 PM +0200 6/23/04, Julian Reschke wrote:
>I know you didn't say that. I just wanted to point out, that, in 
>order to be a legal namespace name, "DAV:" would *need* to be a 
>legal URI. Unfortunately it isn't.

That's not my reading of http://www.w3.org/TR/1999/REC-xml-names-19990114;
you seem to believe that a URI reference used as namespace cannot be the
bare scheme.  The "qualified names" discussion seems to contradict this
view, at least in my reading.

			regards,
				Ted Hardie

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 21:41:48 +0200

> view, at least in my reading.

"DAV:" isn't a RFC2396-compliant URI reference either, because it starts 
with a scheme name.

This issue has been discussed extensively in autumn 2002, the result 
being that RFC2396bis will change the grammar to allow empty scheme 
names, thus (finally) making "DAV:" a valid URI and thus a legal 
namespace name.

See: 
<http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html#014-empty-opaque_part>

Best regards,

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 23 Jun 2004 12:44:27 -0700

This has a little problem with terminology:

>    be implemented as a REBIND request.

The "destination collection" seems here to refer to the collection 
named in the Request-URI, not the collection named in the Destination 
header.  Since destination collection is ambiguous, this could be the 
"target collection", the "collection named in the Request-URI", or "the 
collection named in the Destination header".  Those aren't all the same 
thing obviously.

The rest is a good addition to the spec.

thanks,
Lisa

> Although [RFC2518] allows a MOVE

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 21:57:40 +0200

Lisa Dusseault wrote:

> The "destination collection" seems here to refer to the collection named 
> in the Request-URI, not the collection named in the Destination header.  

Can't follow. When talking about a MOVE request, why would you ever 
understand "destination collection" as the thing identified by the 
Reuqest-URI (which is clearly the source), not the thing identified by 
the "Destination" header?

Please explain.

Best regards, Julian

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 Jun 2004 13:04:06 -0700

At 9:41 PM +0200 6/23/04, Julian Reschke wrote:
>"DAV:" isn't a RFC2396-compliant URI reference either, because it 
>starts with a scheme name.

I think you're mistaking an ABNF change between 2396 and 2396bis for
an architectural point.  If you go back to 1738, the predecessor to 2396,
the schemepart's inclusion of *xchar clearly allows zero according
to the rules of the BNF syntax it references from 822 (see 2.4 in
RFC 822).
			regards,
				Ted Hardie

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 23 Jun 2004 13:09:58 -0700

Because the sentence talked only about one collection supporting 
REBIND, and I would think that the most important collection to support 
REBIND in this case would be the source collection.  I think that was a 
reasonable and careful read of the text.

Perhaps my assumption would not have held up if the sentence had said 
"if the destination collection and the source resource of a MOVE 
request both support the REBIND method ..." etc.

Lisa

On Jun 23, 2004, at 12:57 PM, Julian Reschke wrote:

>> header.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 22:17:48 +0200

Ted,

I was only mentioning that in 2001 (not 2002 as I realized) we found 
that the bare string "DAV:" isn't a legal URI according to RFC2396. This 
was discussed with Roy Fielding, and as a consequence RFC2396bis changes 
this.

Anyway, this is really not relevant for BIND. BIND doesn't define any 
new namespaces in the "DAV:" scheme, it just puts more elements into the 
  XML namespace named "DAV:", which is already defined in RFC2518. Thus 
there's IMHO nothing that needs to change in BIND.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 23 Jun 2004 22:43:02 +0200

Lisa Dusseault wrote:

> Because the sentence talked only about one collection supporting REBIND, 
> and I would think that the most important collection to support REBIND 
> in this case would be the source collection.  I think that was a 

Well, no:

"If the destination collection of a MOVE request supports the REBIND 
method (see Section 6), a MOVE of a resource into that collection MAY be 
implemented as a REBIND request."

The text clearly talks about the destination collection, and as far as I 
can tell, it's doing that on purpose.

> "if the destination collection and the source resource of a MOVE request 
> both support the REBIND method ..." etc.

The source resource doesn't need to support REBIND - REBIND is a method 
where the Request-URI is the target collection into which the new 
binding is added.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 23 Jun 2004 14:02:52 -0700

Well, I certainly read it wrong although I read it carefully, because I 
forgot that REBIND is defined differently than MOVE so that the 
Request-URI is the target collection.  And it's not obvious to me that 
the source collection doesn't need to implement REBIND for this to 
work.  But if everybody else who reads the spec is clear on this, then 
I'll write it off as an anomaly.

Lisa

On Jun 23, 2004, at 1:43 PM, Julian Reschke wrote:

>> REBIND, and I would think that the most important collection to 
>> support REBIND in this case would be the source collection.  I think 
>> that was a reasonable and careful read of the text.
>
> Well, no:
>
> be implemented as a REBIND request."
>
> The text clearly talks about the destination collection, and as far as 
> I can tell, it's doing that on purpose.
>
> The source resource doesn't need to support REBIND - REBIND is a 
> method where the Request-URI is the target collection into which the 
> new binding is added.
>
> Best regards, Julian
>
> --

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 23 Jun 2004 18:13:13 -0400

I noticed that you moved the sentence to the end of the third
paragraph instead of to the end of the second paragraph.
I'd prefer it to be at the end of the second paragraph, but
either way is OK.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jun 2004 00:19:46 +0200

> I'd prefer it to be at the end of the second paragraph, but

That makes more sense -- thanks for checking. New text below:

2.5  MOVE and Bindings

    If the destination collection of a MOVE request supports the REBIND
    method (see Section 6), a MOVE of a resource into that collection MAY
    be implemented as a REBIND request.  Although [RFC2518] allows a MOVE
    to be a non-atomic operation, when the MOVE operation is implemented
    as a REBIND, the operation is atomic.  In particular, applying a MOVE
    to a Request-URI and a Destination URI has the effect of removing a
    binding to a resource (at the Request-URI), and creating a new
    binding to that resource (at the Destination URI).  Even when the
    Request-URI identifies a collection, the MOVE operation involves only
    removing one binding to that collection and adding another.

    created.

     URI-1   URI-2    URI-3
       |       |        |
       |       |        |      <---- URI Mappings
       |       |        |
    +---------------------+
    |     Resource R      |
    +---------------------+

     URI-1   URI-2    URI-X
       |       |        |
       |       |        |      <---- URI Mappings
       |       |        |
    +---------------------+
    |     Resource R      |
    +---------------------+

Best regards, Julian

---

From: "Basavaraj" <[email-masked]>
Date: Thu, 24 Jun 2004 14:36:28 +0530

Hi ,
I am Working with WebDav.
I got Struck in Access Tables Fields Through XML
Can you let me know how to access it dynamically.
As of now i have had coded (Sample code Pasted below in color)and making it
work for particular User Only.
Now i want to Dynamically Access Fields from a Table for any user.
        ExUser *userInfo = new ExUser();
        userInfo->Domain = "JPM";// Domain Name
        userInfo->Login = "ikon5"; // User
        userInfo->mailboxId = "ikon5";// Alias to User
        userInfo->mailServer = "JPSERV5";//Exchange Server
        userInfo->Password = "ikon5"; //Password
It would be pleasure if answed.
Thanks in Advance.
-Basavaraj Prabha

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jun 2004 11:48:21 +0200

Hi,

it seems that your question relates to the Exchange API, not WebDAV per 
se. It's unlikely that somebody on this list will be able to help you -- 
you probably should post to a MS-Exchange related mailing list or 
newsgroup instead.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 26 Jun 2004 14:37:05 +0200

> like something that should appear in the spec).

OK. I'll mark that issue closed with a pointer to this mailing list posting:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.1.3_error_negotiation>

Joe, is this ok for you, or would you like to suggest actual replacement 
text?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jun 2004 10:23:21 +0200

Hi,

I have updated the latest draft text (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
and 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>) 
as follows:

1) Recorded and resolved those issues for which we agreed upon a 
resolution 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.5_language> 
and 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.7.1.1_add_resource_id>).

2) Recorded and resolved as "no change" the issue where the consensus 
seemed to be that we don't need a change 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.1.3_error_negotiation>).

3) Re-added issue 4_LOCK_BEHAVIOUR from the old issues list as 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.4_LOCK_BEHAVIOR> 
(with status "closed").

4) No changes at all where it seems that the explanations provided by 
Geoff and myself seem to have been sufficient.

This leaves us with the perma-issue of locking vs binds:

> ...
>> 4 (and others)
>>  - (DAV:locked-update-allowed) what if the resource is locked?  I understand that this is a property of the resource, not the binding, but since 2518 doesn't say anything about bindings, I think we could use a paragraph at some point that spells this out explicitly.  Perhaps another sub-section in section 2?
> 
> 
> That's incorrect. In particular, <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3> says:
> 
> "A resource may be made available through more than one URI. However locks apply to resources, not URIs. Therefore a LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable."
> 
> That being said, a large amount of the open issues raised against RFC2518 are about locking semantics. The authors of the BIND spec feel that it's a bad idea to try to clarify locking semantics in a document that's completely independant and optional. Locking semantics should be fully defined in a single place.
> 
> One way to do this is to wait for RFC2518bis. Another one is to factor out locking from the base protocol, and publish this as "update" to RFC2518 (at "proposed" level), and let the BIND spec refer to that. This is what I'm currently working on (and I'm planning to submit a complete rewrite in time before the IETF meeting).
> 
> I've summarized the issue at <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html>.   So far, I've seen many people agree, and it would be really good if the working group would come to a decision on this matter. 
> ...

It would be nice if we could make some progress on that discussion which 
has now been going on for half a year...

Anyway, unless I people feel there's a problem with that, I'll be 
submitting the latest edits as draft 06 so we have an up-to-date 
published version in due time before the IETF meeting.

Best regards, Julian