Subject: RE: Comments on bind-08

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 1 Dec 2004 12:01:26 -0800

Julian writes:

> >>>* Section 4. Need a new condition to cover the case where the BIND 
> >>>half-succeeded, and then needed to be rewound. This 
> condition would 
> >>>address the case where Overwrite is true, the destination
> >>
> >>binding has
> >>
> >>>been removed, but the new binding couldn't be created.
> >>
> >>But then it wouldn't be atomic, right?
> > 
> > 
> > Well, what status element would you return in the case where the 
> > method half-succeeded, and then needed to re rewound?
> 
> That depends on why the new binding couldn't be created....?

Say, for the sake of argument, that there is a disk full condition, such
that the database holding bindings could delete a binding, but couldn't
create the new binding. In this internal server error condition, what status
code/element would be returned?

> I'm not seeing a problem (yet). C1 would be removed, while C2 
> wouldn't. 
> It's the server's job to ensure that resource R isn't 
> negatively affected.

OK, I'll let this one go.

> Could you be more specific about which case you think would 
> need to be clarified? Is this about the specific marshalling 
> of REBIND, or about locking semantics in face of multiple bindings?

It's about the problems clients have with correctly marshalling needed
information into the If header.

> It's way "everybody" does it (WebDAV lock tokens, WebDAV 
> ordering, Atom IDs, XML namespaces). Also, UUIDs may not 
> always be the best identifier available. For instance, for 
> lock tokens a server may be using a single UUID + a counter 
> (as allowed in the opaquelockoken syntax) -- why shouldn't it 
> do the same for resource IDs?

OK, I'll let this one go.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 01 Dec 2004 21:11:40 +0100

> code/element would be returned?

OK.

I think the answer would be: none specific. The status would be just 
506. There are many potential error conditions for which BIND doesn't 
define specific names. As a matter of fact, I'd say it's not possible to 
enumerate them all.

> information into the If header.

OK, just to clarify: you'd like to see an example for lock tokens being 
submitted in a non-trivial namespace operation such as MOVE/REBIND 
between locked collections? I'm not strongly opposed to that; I just 
like to understand the motivation (which in this case would be: we don't 
have an example like that in RFC2518, so this may be an action item for 
RFC2518bis as well).

> OK, I'll let this one go.

Thanks :-)

Julian

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

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 1 Dec 2004 12:18:10 -0800

> I think the answer would be: none specific. The status would 
> be just 506. There are many potential error conditions for 
> which BIND doesn't define specific names. As a matter of 
> fact, I'd say it's not possible to enumerate them all.

OK, then I'm fine with letting this issue go.

> OK, just to clarify: you'd like to see an example for lock 
> tokens being submitted in a non-trivial namespace operation 
> such as MOVE/REBIND between locked collections? I'm not 
> strongly opposed to that; I just like to understand the 
> motivation (which in this case would be: we don't have an 
> example like that in RFC2518, so this may be an action item 
> for RFC2518bis as well).

Yes, that's correct. I'm fine with this being added as an action item for
2518bis as well.

- Jim

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 1 Dec 2004 17:28:49 -0800

> Yes, that's correct. I'm fine with this being added as an action item 
Sounds good... getting such an example into RFC sooner as well as later 
makes sense to me.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Dec 2004 09:50:37 +0100

> Sounds good... getting such an example into RFC sooner as well as later 

Actually, and with all due respect, to me this seems to be lame.

Are we supposed to put examples that having nothing whatsover to do with 
BIND per se into the BIND spec just because it happens to be the next 
spec that's supposed to get finished? I fear that is an open-ended set 
of possible clarifications, and doing all of them certainly is not the 
right way to finish the spec.

Speaking of which, what is the status of RFC2518bis?

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 2 Dec 2004 09:01:26 -0500

I agree with Julian.  The conclusion that I believe Jim, Julian, and I
reached was that this material should appear in RFC2518bis, not that it
should appear in both (for the reasons stated by Julian below).

Cheers,
Geoff

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 2 Dec 2004 09:02:38 -0800

Julian writes:

> Are we supposed to put examples that having nothing whatsover 
> to do with BIND per se into the BIND spec just because it 
> happens to be the next spec that's supposed to get finished? 
> I fear that is an open-ended set of possible clarifications, 
> and doing all of them certainly is not the right way to 
> finish the spec.

I think there should be examples of If header use in the BIND specification,
and also in RFC 2518bis. Though quite related, this repetition is
worthwhile. It is worthwhile in 2518bis because of the observed problems
with client implementations of the If header. Interoperability errors are
expensive to identify and fix, and tend to have negative impacts on users
before they are fixed. Examples often help reduce interoperability errors,
and are less costly to produce than it is to identify and fix an
interoperability problem.

The bind specification introduces some new wrinkles for If header passing
and processing, especially the existence of loopback bindings. Additionally,
a diligent, careful specification reader could still find it useful to have
an example that confirms their understanding of how to apply the If header
processing described in RFC 2518 to collections using bindings. For these
two reasons it also makes sense to have an example of If header passing in
the bind specification.

- Jim

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 2 Dec 2004 09:05:32 -0800

> Speaking of which, what is the status of RFC2518bis?

I'll pile on here, and second Julian's question. Who currently has the edit
token for 2518bis, and when have they committed to producing a new
specification draft?

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Dec 2004 18:16:54 +0100

> two reasons it also makes sense to have an example of If header passing in

As I said before, I'm not completely opposed to add examples; it's just 
that we should make sure we don't get carried away (because it's 
RFC2518bis, or, may I say, a separate locking spec's ([1]) role to add 
these).

So, could you please specify exactly which situation you'd like the 
example to be for? My understanding was:

- Method: REBIND
- Locks on: source and target collection

Correct?

Julian

[1] 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 2 Dec 2004 09:51:33 -0800

I have the edit token.  I have been unable to produce a new draft for a 
while because of unresolved issues.  Now that we've got issue tracking 
up, we can either continue focusing on bindings and finish it, or split 
our focus.

lisa

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 2 Dec 2004 10:16:01 -0800

> So, could you please specify exactly which situation you'd 
> like the example to be for? My understanding was:
> 
> - Method: REBIND

I'd like the example to be the following.

Given the following collection hierarchy, the example should cover a REBIND
of C3:(CollZ->C1) to C3:(CollZ->C2).

+------------------+
| Root Collection  |
|  bindings:       |
|  CollW           |
+------------------+
    |
    |
    |
+-------------------------------+
| Collection C1                 |<--------+
| bindings:                     |         |
| CollX               CollY     |         |
+-------------------------------+         |
    |                  |                  |
    |                  |   (creates loop) |
    |                  |                  |
+-----------------+  +------------------+ |
| Collection C2   |  | Collection C3    | |
| LOCKED infinity |  | LOCKED infinity  | |
| bindings:       |  | bindings:        | |
|  {none}         |  | y.gif     CollZ  | |
+-----------------+  +------------------+ |
                      |            |      |
                      |            +------+
                      |
                  +---------------------------+
                  | Resource R2               |
                  | (lock inhereited from C3) | 
                  +---------------------------+

Note that it's fine with me if we don't discuss exactly how the lock state
in the example came to be -- just take it as a given, and go from there.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Dec 2004 22:02:37 +0100

> of C3:(CollZ->C1) to C3:(CollZ->C2).

Wow.

Just to make sure, we're talking about

MOVE /CollW/CollY/CollZ HTTP/1.1
Destination: /CollW/CollX
Overwrite: T

?

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 2 Dec 2004 13:22:24 -0800

> Destination: /CollW/CollX

I was thinking it would be:

REBIND /CollW/CollY/ HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset=utf-8
Content-Length: xxx
If: <http://www.example.com/CollW/CollY/> 
    (<opaquelocktoken:e5f41359-d00d-f00f-3ef5-50cb4c3a215f>)
If: <http://www.example.com/CollW/CollX/>
    (<opaquelocktoken:b749a327-75ef-ba64-82db-b63ac56721b4>)

<?xml version="1.0" encoding="utf-8" ?>
<rebind>
  <segment>CollZ</segment>
  <href>/CollW/CollX/</href>
</rebind>

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Dec 2004 22:30:00 +0100

> Destination: /CollW/CollX

OK,

given the lock tokens L2 for C2 and L3 for C3, I'd say the REBIND 
request would be:

REBIND /CollW HTTP/1.1
If: <http://example.com/CollW/CollY/CollZ> (<L3>) 
<http://example.com/CollW/CollX> (<L2>)
Overwrite: T

<rebind xmlns="DAV:">
   <segment>CollX</segment>
   <href>/CollW/CollY/CollZ</href>
</rebind>

Reason: we need to supply both lock tokens as we're removing a binding 
to C3 that is protected by the lock L3, and we're removing the target 
binding /CollW/CollY which is protected by the lock L2.

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 2 Dec 2004 13:45:04 -0800

> binding /CollW/CollY which is protected by the lock L2.

This doesn't sound right to me. I'd say that we're removing the binding
C3:(CollZ->C1), and hence we need the lock token L3. We're then creating the
binding C3:(CollZ->C2), which requires the lock tokens L3 and L2, since C3's
state is being modified (hence L3), and C2 is the destination (hence L2).
I'm pretty confident of all except the final statement.

> we're removing the target 

Isn't binding /CollW/CollY/ -- that is, C1:(CollY->C3) -- covered by lock
L3?

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Dec 2004 23:27:14 +0100

> I'm pretty confident of all except the final statement.

I missed the bind loop... This causes L2 and L3 to protect overlapping 
sets of URIs, so they must be shared locks, correct?

> Isn't binding /CollW/CollY/ -- that is, C1:(CollY->C3) -- covered by lock

I guess we should stick with diagrams until we agree on the operation 
we're performing...:

Before:

+------------------+
| Root Collection  |
|  bindings:       |
|  CollW           |
+------------------+
     |
     |
     |

After:

+------------------+
| Root Collection  |
|  bindings:       |
|  CollW           |
+------------------+
     |
     |
     |
+-------------------------------+
| Collection C1                 |
| bindings:                     |
| CollX               CollY     |
+-------------------------------+
     | ^                |
     +-+                |
                        |
+-----------------+  +------------------+
| Collection C2   |  | Collection C3    |
|                 | LOCKED infinity  |
| bindings:       |  | bindings:        |
|  {none}         |  | y.gif            |
+-----------------+  +------------------+
                       |
                       |
                       |
                   +---------------------------+
                   | Resource R2               |
                   | (lock inhereited from C3) |
                   +---------------------------+

So C2 doesn't have any bindings in scope anymore (and thus no lock), and 
C1's new binding CollX identifies C1 itself, creating a new bind loop.

I have the nagging feeling that this wasn't what you intended to do :-)

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 2 Dec 2004 22:33:40 -0500

I'm not following this.  What is lock L3 and what is lock L2?
(the locks in the picture are not named).  In any case,
I suggest that the example be modified to have exclusive locks
(as Julian indicates, this example must have shared locks which
is not as commonly implemented).

Cheers,
Geoff

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 3 Dec 2004 09:13:56 +0100

Lisa,

please focus on 2518bis.

//Stefan

Am 02.12.2004 um 18:51 schrieb Lisa Dusseault:

>
> I have the edit token.  I have been unable to produce a new draft for 
> a while because of unresolved issues.  Now that we've got issue 
> tracking up, we can either continue focusing on bindings and finish 
> it, or split our focus.
>
> lisa
>

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 3 Dec 2004 09:32:19 -0800

> I guess we should stick with diagrams until we agree on the operation 

Yes, good point. Hmm, the figures you drew weren't quite right.

Before (this is OK, I added lock token identifiers for clarity):

+------------------+
| Root Collection  |
|  bindings:       |
|  CollW           |
+------------------+
     |
     |
     |
| (lock token L2) |  | (lock token L3)  | |
                       |            +-----+
                   | (lock token L3)           |

After (this is changed -- CollZ now points to C2, not C1)

+------------------+
| Root Collection  |
|  bindings:       |
|  CollW           |
+------------------+
     |
     |
     |
+-------------------------------+
| Collection C1                 |
| bindings:                     |
| CollX               CollY     |
+-------------------------------+
     |                  |
     |                  |
     |                  |
+-----------------+  +------------------+
| Collection C2   |  | Collection C3    |
| LOCKED infinity |  | LOCKED infinity  |
| (lock token L2) |  | (lock token L3)  |
| bindings:       |  | bindings:        |
|  {none}         |  | CollZ     y.gif  |
+-----------------+  +------------------+
       ^                |           |
       +----------------+           |
                                    |
                   +---------------------------+
                   | Resource R2               |
                   | (lock inhereited from C3) |
                   | (lock token L3)           |
                   +---------------------------+

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Dec 2004 20:12:06 +0100

> Before (this is OK, I added lock token identifiers for clarity):

I guess this explains the confusion. The operation that you're showing 
here keeps the binding name (CollZ), but changes the resource to which 
it refers (from C1 to C2). This is neither a MOVE nor a REBIND operation.

You can express this as

1) UNBIND /collW/CollY/
    <unbind xmlns="DAV:">
      <segment>CollZ</segment>
    </unbind>

followed by

2) BIND /collW/CollY/
    <bind xmlns="DAV:">
      <segment>CollZ</segment>
      <href>/CollW/CollX</href>
    </bind>

The other obviously open question was whether bind loops need special 
treatment regarding depth:infinity locks. I wasn't under the impression 
they do. Is there a specific problem that needs to be solved?

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 3 Dec 2004 12:21:59 -0800

> I guess this explains the confusion. The operation that 
> you're showing here keeps the binding name (CollZ), but 
> changes the resource to which it refers (from C1 to C2). This 
> is neither a MOVE nor a REBIND operation.
> 

Ah! Thanks for figuring this out. So, REBIND really moves the head of the
binding from one place to another. I was assuming it moved the tail from one
place to another.

I'll have to rethink the desired example.

> The other obviously open question was whether bind loops need 
> special treatment regarding depth:infinity locks. I wasn't 
> under the impression they do. Is there a specific problem 
> that needs to be solved?

Well, there are two issues. One is the handling of If headers for loopback
bindings. The other is the semantics of the lock operation in the presence
of loopback bindings. I think the handling of If headers is relatively
straightforward. The semantics of locking are not.

Consider the following collection hierarchy:

+------------------+
| Root Collection  |
|  bindings:       |<---------------------+
|  CollW           |                      |
+------------------+                      |
     |                                    |
     |                                    |
     |                                    |
| Collection C1                 |         |

What is the outcome of an exclusive LOCK, depth infinity, submitted to
/CollW/CollY/ ?

Seems to me, the desired outcome is that only C3 and R2 are locked. 

However, if you read 2518, section 8.10.4 (Depth and Locking), it says:

"If the Depth header is set to infinity then the resoruce specified in the
Request-URI along with all its internal members, all the way down the
hierarchy, are to be locked." 

In the binding specification, we define an Internal Member URI as 

"The URI that identifies an internal member of a collection, and that
consists of the URI for the collection, followed by a slash character ('/'),
followed by the path segment of the binding for that internal member." 

So, following these two definitions, one would interpret CollZ as an
internal member URI, and then have the lock request apply to it, in this
case locking the root collection, and all of its internal members, etc. What
happens next is unclear. Either the lock fails (because /CollW/CollY/ is
already locked), or the entire URL hierarchy on the server is added to the
lock. 

In both cases, this seems like undesirable semantics. Lock really should
ignore any loopback binding. While loopback bindings could theoretically
have existed in the 2518 world, it really is only the introduction of the
BIND specification that starts raising these issues with any urgency.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Dec 2004 21:44:41 +0100

> I'll have to rethink the desired example.

Great....

> Consider the following collection hierarchy:

Well, I would expect the lock to behave as defined by RFC2518, 
effectively locking the whole namespace.

> hierarchy, are to be locked." 

Why is that a problem? A bind loop that includes the namespace root 
seems like an edge case to me that doesn't require changing the base 
semantics. If it hurts to have a bind loop including the namespace root, 
don't do it.

> BIND specification that starts raising these issues with any urgency.

Well, there are good reasons not to implement bind loops at all (this is 
why the spec explicitly allows servers to reject requests creating them, 
see DAV:cycle-allowed precondition for BIND). The presence of bind loops 
creates all kinds of issues, including those what to do with 
PROPFIND/depth:infinity and code that walks hierarchies and gets into 
infinite loops. I'm not surprised that Depth:infinity locks in bind 
loops are hard to handle, but IMHO that only means that one should avoid 
bind loops :-)

I remember that Geoff was actually defending the ability to have bind 
loops, so maybe he can offer some opinion about how locks should behave. 
Personally, I'd say: "the way they are defined by RFC2518, and if this 
hurts, don't do it".

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 3 Dec 2004 13:56:48 -0800

> Why is that a problem? A bind loop that includes the 
> namespace root seems like an edge case to me that doesn't 
> require changing the base semantics. If it hurts to have a 
> bind loop including the namespace root, don't do it.

The reason I think this is an issue is that I can't envision a scenario
where you would ever want the lock to follow a loopback binding. That is,
the reason it is a problem is the locks-follow-the-loopback-binding
semantics are never what a client would want.

You can make consistent semantics here, by saying that locks always
propagate down a hierarchy, but never up. Yes, this is changing the base
lock semantics somewhat, but in my opinion it doesn't violate the intent of
2518. This is essentially adapting the COPY depth infinity semantics for
locks.

> > In both cases, this seems like undesirable semantics. Lock really 
> > should ignore any loopback binding. While loopback bindings could 
> > theoretically have existed in the 2518 world, it really is only the 
> > introduction of the BIND specification that starts raising 
> these issues with any urgency.
> 
> Well, there are good reasons not to implement bind loops at 
> all (this is why the spec explicitly allows servers to reject 
> requests creating them, see DAV:cycle-allowed precondition 
> for BIND). The presence of bind loops creates all kinds of 
> issues, including those what to do with 
> PROPFIND/depth:infinity and code that walks hierarchies and 
> gets into infinite loops. I'm not surprised that 
> Depth:infinity locks in bind loops are hard to handle, but 
> IMHO that only means that one should avoid bind loops :-)

Saying "tut-tut" doesn't make the problems of the interactions of loopback
bindings and depth locks go away.

> Personally, I'd say: "the way they are defined by RFC2518, 
> and if this hurts, don't do it".

We can be more nuanced than this.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Dec 2004 23:26:56 +0100

> semantics are never what a client would want.

I'll not argue with that. But to me this means that if you don't want 
that, don't do it. The fact that depth:infinity locks have interestings 
results for bind loops doesn't necessarily mean that the base semantics 
need to be changed; not doing it if you don't want to certainly is an 
option as well (and a much simpler one spec-wise).

> 2518. This is essentially adapting the COPY depth infinity semantics for

Sounds interesting; but as I'd like to hear feedback from those who 
actually see bind loops being used in practice. Geoff??

> We can be more nuanced than this.

We *could*. The question is: do we want to complicate the spec for 
something that seems to be an edge case? As far as I am concerned, bind 
loops are something that most implementers won't implement anyway. Let's 
hear from those who actually want bind loops about what they think about 
how they should behave with locking.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 5 Dec 2004 22:18:15 -0500

The problem here is that Julian is using the intended marshalling
of REBIND (which is like BIND, i.e. the request-URI identifies the
collection into which the new binding will be created), while Jim
is using the incorrectly updated definition in the current spec,
which inverts the intended meaning (i.e. in the current draft,
the syntax has been incorrectly "clarified" as having the request-URI
identify the existing binding).

I've submitted a bug on this.

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 5 Dec 2004 22:36:42 -0500

> > is neither a MOVE nor a REBIND operation.

Actually, it is a REBIND operation, but in the opposite direction.

> binding from one place to another. I was assuming it moved the tail from 
one

Hmmm.  That's an even more obscure way of saying it (:-).

You were doing:
  BIND source-collection <source-segment, destination-URI>
which is what the spec was incorrectly updated to say, while Julian was 
doing:
  BIND destination-collection <destination-segment, source-URI>
which is what the spec originally was intended to say (to be like BIND).

OK. 

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 5 Dec 2004 22:52:26 -0500

Julian wrote on 12/03/2004 03:44:41 PM:
 
> > Lock really should

> bind loops :-)

Bind loops are fine.  Depth:infinity applied to bind loops is what
causes the problem.  As Julian indicates, how a particular server decides
to handle Depth:infinity locks in the presence of bind loops (for those
very rare servers, if any, that actually support this) will be very
idiosyncratic to that particular server.  It may decide to fail 
a Depth:infinity lock applied to a loop, or it may decide to lock all
the resources included in the loop.  Or it may decide to do something
totally bizarre(:-) such as Jim's suggestion, that it lock only resources
that aren't parents of the resource being locked.  We need to maintain
a discrete silence here, since we really can't predict what a server
will need to do, or be able to do, in a case like this.  But this is
a very unlikely edge case, and therefore I believe doesn't merit any
spec space devoted to it.

> loops, so maybe he can offer some opinion about how locks should behave. 

We will not be supporting depth locks in our loop-supporting repostories.

> Personally, I'd say: "the way they are defined by RFC2518, and if this 

I agree, where by "don't do it", I assume you mean "fail an attempt to 
create the lock", and it's got a well-defined error code (506) it it
decides to do so.

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 5 Dec 2004 23:05:07 -0500

> option as well (and a much simpler one spec-wise).

I completely agree.  Throw a 506 if you don't want to follow the base
semantics.

> actually see bind loops being used in practice. Geoff??

I don't believe any server would actually maintain a depth:Infinity 
lock only on the "non-ancestor" members, since it would have to perform
expensive recomputations on all involved locks every time a binding
was changed.  It will either do the base semantics (and bind everything)
or fail the depth:lock or the attempt to loop-back under a depth-lock
(with a 506).  We just won't support depth locks on our loop-backing
repositories.

> > bindings and depth locks go away.

Pragmatically, a server will do some combination of:
- support the base semantics,
- fail attempts to create loops,
- fail attempts to do depth locks,
- fail attempts to create a loop under a depth lock, or
- fail attempts to depth lock over a loop

None of these require additional statements in the specification,
and we really cannot (and should not) try to dictate which of these
it does.  And we certainly should dictate it do something computationally
infeasible instead (:-).

> how they should behave with locking.

I agree we should not try to be more nuanced.
The current definitions give the servers all the alternatives they are 
likely
to pick.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Dec 2004 11:48:02 +0100

OK,

to summarize: as far as Geoff and I (as most recent editors of the spec 
is concerned), the intent indeed is that RFC2518 semantics apply, and 
this is the reason why the spec is silent on it.

Jim, does this settle the question, or should I add this to the 
document's issues list?

Regarding the process, I'd like to submit a new draft this week, and I 
think that one should be WG-last-called. If we do a 4-week last call, 
people of plenty of time to review it until mid of January.

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 6 Dec 2004 09:21:06 -0800

Geoff Clemm writes:

> idiosyncratic to that particular server.

My assertion is the semantics of Depth infinity locks and loopback bindings
will be very consistent -- servers will ignore loopback edges when computing
the closure of the containment graph of a collection for the purpose of
locking.  This is a very consistent semantics, one that is easy to specify,
and easy to understand. 

Furthermore, I also assert that there is no reasonable scenario under which
a server would ever want to follow the loopback bindings when computing
Depth infinity closure. Given this, we would be acting responsibly as
specification writers to clarify the semantics of this situation, and to
close off undesirable semantics.

> We need to maintain 

I don't think we can reasonably predict how many servers will implement both
loopback bindings and depth locks. 

We do know there is a feature interaction issue here. We also have
sufficient experience to be able to analytically determine that allowing
locks to follow loopback bindings can cause an operation to have unexpected
scope of impact from a user-directing-a-client perspective. We need some
SHOULD-level guidance for servers that decide to support both depth locks
and loopback bindings. (I personally think it could be MUST-level, but would
be happy with at least SHOULD).

It is negligent to duck this feature interaction. All servers that currently
implement depth locks and plan on implementing the BIND specification will
need to make decisions about how to handle this interaction, whether by
disallowing loopback bindings, depth locks of loopbacked collectioned, etc.
At the very least we need an implementation note outlining Geoff's options
so implementors can make reasoned decisions about how to duck the issue.
Even better would be supplementing this with feedback on how to do a good
job of providing both features simultaneously.

- Jim

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 6 Dec 2004 18:40:34 +0100

May I ask what the definition of a "loopback binding" is and how it 
differs from other bindings?

In my concept, all bindings are created equal and which binding "loops 
back" to where depends on the path you take when traversing collection 
"trees", as I see it. From mathematical perspective, bindings transform 
the well known *tree* into a directed graph. Some servers will require 
acyclic graphs while others will allow cycles.

The set of deep-locked nodes is the set of nodes reachable from the 
starting point. We could provide an algorithm for server implementors, 
and even more important for clients, on how to find this set and not 
get lost in possible cycles.

Stefan

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 6 Dec 2004 09:51:06 -0800

> May I ask what the definition of a "loopback binding" is and 
> how it differs from other bindings?

A rough definition is any binding that converts an acyclic containment graph
into a cyclic graph. This is also how it differs from other bindings. 

> Some servers will require 

Right. In the case where servers support cycles, and also support depth
locks, they'll need to develop semantics for the interaction of these two
features. At present, the bind specification provides no guidance for this
situation.

> The set of deep-locked nodes is the set of nodes reachable 
> from the starting point. We could provide an algorithm for 
> server implementors, and even more important for clients, on 
> how to find this set and not get lost in possible cycles.

We could do this, although I'd rather not get into specifying which kind of
traversal algorithm servers should use (depth first vs breadth first, etc.),
since that's implementation detail. 

I'd rather point out that, no matter which kind of traversal you use to
compute closure, there are certain edges (loopback edges) that should not be
followed in computing the closure.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Dec 2004 23:10:53 +0100

> into a cyclic graph. This is also how it differs from other bindings. 

So, for a set of bindings that are part of that cyclic graph, which one 
is "causing" it?

> features. At present, the bind specification provides no guidance for this

IMHO it doesn't because it doesn't need to. As far as I can tell, until 
we say something else, the standard semantics apply (and as far as I can 
tell, it's clear what they define in this case).

> since that's implementation detail. 

As long as a server stops descending into a collection when it detects 
that it has visited that collection before, there doesn't seem to be an 
issue.

> followed in computing the closure.

IMHO deep locks on bind loops are an edge case, in particular if the 
bind loop includes the namespare root (as in the example we discussed). 
Is there anybody how already supports both or plans to support both and 
will *not* implement the standard RFC2518 deep lock semantics?

BTW, another thing to keep in mind is that you don't need the BIND spec 
to create bind loops. Once you accept the existence of multiple URIs to 
the same resource, and the fact that these resources can be collections, 
a simple MOVE operation can create a BIND loop.

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 6 Dec 2004 15:11:01 -0800

Julian writes:

> So, for a set of bindings that are part of that cyclic graph, 
> which one is "causing" it?

Ah, now I see what you and Stefan are getting at. The binding "causing" a
loop can depend on the traversal through the graph.

For a given DAV operation, there is an out, though, in that you have a
starting node for the operation. Given this, the binding causing a loop is
one that either:
A) points to a resource already traversed (child loop)
or
B) points to a resource that is both on the path of the starting node, and
has shorter pathlength than the starting node (parent loop)

(Let's see how this flies -- I have a sneaking suspicion I'm forgetting some
edge case). 

> IMHO it doesn't because it doesn't need to. As far as I can 
> tell, until we say something else, the standard semantics 
> apply (and as far as I can tell, it's clear what they define 
> in this case).

But because of the existence of loopback bindings, and their ability to have
an operation bleed out to the entire resource space of a server, its not
clear that the standard semantics should apply here, and hence saying
nothing is ambiguous.

> As long as a server stops descending into a collection when 
> it detects that it has visited that collection before, there 
> doesn't seem to be an issue.

We agree here. The problem comes when you visit a parent collection of the
starting point of a Depth infinity lock.

> IMHO deep locks on bind loops are an edge case, in particular 
> if the bind loop includes the namespare root (as in the 
> example we discussed). 

So, how do we distinguish between edge cases we should address in the
specification, and edge cases we shouldn't? Being an "edge case" doesn't
immediately translate to "don't have to deal with this."

> Is there anybody how already supports both or plans to 
> support both and will *not* implement the standard RFC2518 
> deep lock semantics?

I could say that the Catacomb server plans on doing this, though frankly I
still haven't made up my mind yet.
 
> BTW, another thing to keep in mind is that you don't need the 
> BIND spec to create bind loops. Once you accept the existence 
> of multiple URIs to the same resource, and the fact that 
> these resources can be collections, a simple MOVE operation 
> can create a BIND loop.

You seem to roughly have the following criteria for whether to include
language in the bind specification:

* specifically addresses behavior defined in the bind specification
* is not behavior explicitly defined in another specification

These are reasonable. I feel I've addressed them by noting:

* The ability to create bind loops is made much easier by the existence of
the BIND and REBIND operations.

* The interaction of bind loops and locking is hence raised far more
forcefully by the bind specification. Furthermore, there is some difference
of opinion over what this interaction should be among people who are experts
in the area (you, me, and Geoff).

* It's not clear that the authors of 2518 clearly knew whether their
containment model was broadly inclusion-containment-like, or
referential-containment-like. Certainly the amount of thought we put into
this particular case was close to zero, and 2518 reflects this.

Since I feel I've made this case pretty well, I'd prefer that we focus our
attention on the technical issue, that is, developing appropriate language
for handling this feature interaction. We're writing essays over the
inclusion of a page of text, tops.

- Jim

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 6 Dec 2004 22:38:47 -0500

Jim wrote on 12/06/2004 06:11:01 PM:
> > As far as I can 

I fail to understand your concern here.  If a user places a lock on
the root of the resource space, standard semantics apply and the whole
resource tree is locked.  If a user places a lock on a resource that
has a binding path to the root of the resource space, standard semantics
apply and the whole resource tree is locked.  Why is the first OK and
the second a problem that needs to be fixed?

One can make just a good a case that the standard semantics is what
is intended, so I see no compelling case for defining exceptional behavior
here.  In particular, the alternative semantics you describe are more
complex, and likely to be computationally impractical to maintain as
bindings are added and removed under a depth locked resource.

> starting point of a Depth infinity lock.

I don't see why this is a problem.

> immediately translate to "don't have to deal with this."

If we decide that the standard semantics should apply to this case,
then I believe that we should not single it out, just to say "the standard
semantics apply here as well as everywhere else".

> still haven't made up my mind yet.

I'd be interested in the combinatorics/cost of maintaining the semantics
you are suggesting when adding or removing bindings under a depth lock.
In particular, turning an UNBIND/REBIND/BIND into an operation that takes
time proportional to the number of members of the resource would be a
bad thing.
 
> the BIND and REBIND operations.

Just because a spec makes an operation easier doesn't decrease the 
conflicts
that arise when the spec defining that feature modifies the semantics, and 
the
spec that "makes that feature easier" are not being maintained/released in
lock step.

> in the area (you, me, and Geoff).

Same response to "raising more forcefully".  Doesn't change the spec
interconnection problem introduced by defining the semantics of a feature
in a different spec from the one that introduces it.

> this particular case was close to zero, and 2518 reflects this.

Good thing that we're working on 2518bis then (:-).

> inclusion of a page of text, tops.

I agree.  But I believe the standard semantics should apply in this case,
so I believe no addition to the text is needed for it.

Cheers,
Geoff

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 7 Dec 2004 08:27:47 +0100

If we can get a rough consensus on the expected behaviour of locks on 
circular binds, I'm all for putting it in the spec. If not, I think the 
spec should remain silent on the issue.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Dec 2004 12:12:32 +0100

> loop can depend on the traversal through the graph.

I'd rephrase slighty differently: given a cyclic graph caused by a set 
of bindings, there is no single binding "causing" it. Remove any of 
them, and the loop will be broken.

> ...

> clear that the standard semantics should apply here, and hence saying

If a bind loop bleeds out to the entire resource space, it's because it 
includes the root collection. IMHO, this is definitively an edge case, 
and the base locking semantics should not be made more complex to take 
care of edge cases like this.

With the removal of lock-null resources and the work on GULP 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0177.html>), 
we have achieved a really simple set of rules that fully define locks. 
Adding special cases here just for edge cases IMHO would be a step into 
the wrong direction.

> starting point of a Depth infinity lock.

I'm still not sure why you call that a "problem". As far as I can tell, 
it works exactly as designed.

> immediately translate to "don't have to deal with this."

I'm not saying we're not dealing with it; what I'm saying is that 
because it is an edge case it doesn't need *special* treatment. Adding 
special treatment for this case makes the base locking semantics 
significanly more complex, and it's still unclear what that would buy us.

>...

That's fine and why we are discussing it. As far as I can tell, Geoff 
and I argue that the base semantics are just fine, and that's why we 
don't need to say anything about ut. If you argue that we need special 
semantics, that's a change to the base locking semantics (no matter 
where we write those down), and thus certainly needs working group 
consensus.

> this particular case was close to zero, and 2518 reflects this.

Yes. So let's fix it in RFC2518bis.

> inclusion of a page of text, tops.

As far as I can tell, we currently disagree fundamentally about what the 
desired semantics are. You seem to ask for a change of the locking 
semantics, while Geoff and I say that the base semantics are just fine. 
I think it's up to you to (a) make a proposal what the intended 
semantics should be (did I miss that?) and (b) try to get support in the 
working group for that change.

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 7 Dec 2004 16:32:47 -0800

> I'm still not sure why you call that a "problem". As far as I 
> can tell, it works exactly as designed.

Here is a plausible scenario that outlines why I think this is a problem.

Assume there is a collection hierarchy rooted at a collection with
non-unique pathname /collA/collB/collC/collD. Within this hierarchy there is
one loopback binding to /collB/, one of approximately 500 bindings within
the collD hierarchy. There is only the one loopback binding in the entire
collD hierarchy.

Alice wants to work on the /collA/collB/collC/collD hierarchy, and wants to
ensure she can make changes to multiple documents to ensure their contents
are consistent with one another. (Alice should probably be using DeltaV
workspaces for this, but that's another matter). So, Alice depth locks the
entire hierarchy, by submitting her lock request to
/collA/collB/collC/collD.

Bob knows that Alice is working on /collA/collB/collC/collD because they
talked about her doing so at their staff meeting in the morning. So, he was
surprised to discover that the area where he was supposed to work,
/collA/collB/collE/collF, is locked by Alice. Bob phoned Alice and asked her
why she had locked his work area, and Alice replied that she hadn't, and was
confused as to why Bob thought this. Bob replied that his authoring tool
reported her as owning the locks on those resources, and that she had locked
his entire resource space.

Alice uses WebDAV Explorer to unlock /collA/collB/collE/collF (good thing
DAV Explorer automatically retrieves and applies the lock token it finds in
the lockdiscovery header, otherwise Bob and Alice would really have a hard
time :-) However, she's then confused as to why the locks on her resource
space have disappeared. So she locks /collA/collB/collC/collD, only to find
out that she can't take out the lock anymore. Frustrating. She asks Bob if
he was able to take out a lock. Yes, he says, now I'm able to take out the
lock and work.

Strange, thinks Alice, it's as if the system only allows one of us to work
at a time. Not understanding what is going on, and have received no error
messages from her software that would lead her to think that a loopback
binding is causing the problem, she calls her firm's technical support.
Since most existing hierarchy browsers for WebDAV do not give any visibility
into loopback bindings, it's anyone's guess as to how long it will take
technical support to determine the root cause of the problem.

- Jim

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 7 Dec 2004 21:57:24 -0500

The major reason to not change standard behavior in the way Jim suggests
is that this will break existing clients.  In particular, if a user depth
locks a collection, a standard depth locking client will assume that the
lock token will apply to all the members of that collection, and will pass
that lock token in any edit request the user makes to a member of that
collection.

But with the semantics that Jim suggests, some of those members will 
remain
mysteriously unlocked, and the editor just fails with "unexpectedly 
missing
lock" when the user attempts to edit (or even worse, allows the user to 
edit
an unlocked resource, without overwrite protection). 

Now let's contrast this with the scenario Jim describes.  Surely any 
server
that is bold enough to support both binding loops and depth locking would
support the DAV:lockroot property introduced a while ago to solve exactly
this problem of not knowing where a lock comes from.  This means that
neither Bob nor Alice is ever surprised or mystified about an "unexpected
lock", because the DAV:lockroot says exactly where it came from.  And if
they want to discover the path back to the lock root, they just use the 
parent-bindings property to walk back through the locked parents until 
they
find the root (or if they have a civilized client, their client will do 
this
walk for them, and report the path from the lock root to the locked 
resource).

So "overlocking" is always easily explained, and is the expected behavior 
for existing clients, while "underlocking" is both mysterious (how does a
user use a standard client to discover why the member isn't locked?) and 
more
significantly, will break existing clients that expect the standard depth
locking behavior.

Cheers,
Geoff

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 8 Dec 2004 16:00:01 -0800

remain 
missing 
edit 
> an unlocked resource, without overwrite protection). 

and
	
> Surely any server 
> this problem of not knowing where a lock comes from. 

These are good points.

That, plus the fact that I'm getting nowhere in convincing anyone else to
change the semantics of loopback bindings, leads me to concede this point.

It's now fine with me not to include any additional language in the BIND
specification about locks and lookback bindings.

- Jim

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 8 Dec 2004 16:20:10 -0800

Sorry I've been a spectator on this one as well.  I am uncomfortable 
about allowing loopback bindings at all, but I'm not sure what would 
improve the situation -- forbidding loopback bindings, fixing the lock 
interactions, or just letting server implementors sort things out.

lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Dec 2004 20:55:39 +0100

> specification about locks and lookback bindings.

OK, for purposes of tracking, I've added both issue and resolution to 
the document, see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.1.1_bind_loops_vs_locks>.

As far I can tell, the only other open discussion we have is about the 
behaviour of properties for multiple bindings on one resource. It seems 
that we're still far from consensus, so I'd like to submit this draft 
(undoing the broken REBIND description) ASAP.

Best regards, Julian

---

From: Frank Lowney <[email-masked]>
Date: Thu, 9 Dec 2004 15:28:40 -0500

I am caught in the middle of a "he said - she said"
kind of discussion about what constitutes a valid URI/URL for WebDAV
and am posting here in the hope of getting an authoritative answer as
to which statement is truer: use "+" or use "%20"
Here's the story:

There is a Learning Management System called WebCT Vista.
It uses an Oracle DB back end and a java-based webserver called
"WebLogic" from a company called BEA.  The problem at
hand is confined to Windows clients.  Mac clients seems to work
as well with this system as they do with Apache and WebSTAR V,
The way WebCT Vista enables the use of WebDAV is that it generates a
URI that the client copies and pastes into a WebDAV client
application.  Here's an example:

http://vista.gsu.edu:8000/webct/webdav/131.96.160.58-1044482159055-3283261001.flowney/University+System+of+Georgia/Georgia+College+and+State+University/Documentation/Vista+3.0+Documentation/Vista+3.0+Dox.01/Section+Content

WebCT Vista puts a "+" char in place of those spaces
but this causes Windows clients to gag and report that "The
folder you are trying to access is invalid" or words to that
effect.  Microsoft has published work around strategies for this
(see below the dotted line). This problem manifests itself only where
there are spaces in the path and only with the more recent Microsoft
clients.  Older clients don't seem to be bothered by this.

The engineers at WebCT Inc say that the "+" is kosher
citing authorities such as:

If you look at this page:

http://www.w3.org/International/O-URL-code.html

It provides some java classes that does URI
encoding.

When you get the program running and entered a space, you
will get a + in return.

If you take a look at the source code, you can find this
comment:

"The space character ' ' is converted into a plus
sign '+'."

Others suggest that spaces should be encoded as %20 in order to
be valid.

Is this a peculiarity of Java code, an Oracke requirement or just
idiosyncratic for WebCT Inc.  More importantly, which encoding
strategy is more valid, more robust?

Has Microsoft gone and broken WebDAV on Windows?

------------------ Microsoft on WebDAV Issues
----------------------------

Some more information for anyone troubleshooting Windows WebDAV
connections

http://support.microsoft.com/default.aspx?scid=kb;en-us;269681

Error:

You attempt to add a Web folder to the My Network Places folder, but
you are unsuccessful and you receive the following error message:

¡§The folder you entered does not appear to be valid ¡§

Cause:

This behavior may occur if you have a system policy that redirects the
user's Application Data folder and prevents the creation of the
Msdaipp folder that the Web Folders feature uses. The Msdaipp folder
is normally located under the user's Userprofile\Application
Data\Microsoft folder.

When you do not use this system policy, the first time you create a
Web folder in the My Network Places folder with the Add Network Place
Wizard, a subdirectory is created. If you set a system policy to
change the Userprofile\Application Data folder to a universal naming
convention (UNC) on a network server, this wizard does not create the
Msdaipp folder at the redirected location and you receive the
preceding error message.

Fix as suggested by a Microsoft Online Partner Support rep:

1. Open the UNC path specified Target Location Folder.

2. Ensure that you can view hidden files, and then open the Microsoft
directory.

3. Create a folder called Msdaipp.

4. Check with this issue again.

However, if the issue persists, please perform the following steps to
create a new account with the Computer Administrator privilege and see
how things are going on.

1) Click Start, and click Control Panel.

2) Double-click "User Accounts".

3) Click the "Create a new account" link.

4) Follow the instruction to create a new account with the Computer
Administrator privilege.

5) Log off the current user account and then log on the new
account.

Also, please perform the troubleshooting steps in the following
article: 287402 ¡§Troubleshooting Web Folders¡¨

http://support.microsoft.com/?id=287402

A)  Replace the
+ signs with spaces.

e.g. http://test.webct.com/webct/webdav/10.1.6.95-1084809904923-2001072000.2001073000/Domain Name/Test Instituite

B) Sometimes the Web
Folder client in Windows could have been changed by another piece of
software (for example, Microsoft Office).  Please consider
following the instructions to restore the WebDAV client to the
original one.

1.  Find a file
called webfldrs.msi (Normally under WINDOWS\SYSTEM32\webfldrs.msi - if
you installed Windows XP Servicepack 1 you will find it under
WINDOWS\ServicePackFiles\i386webfldrs.msi).  E.g.
C:\WINNT\system32

2.  Start the installation with double-click or right-click ->
webfldrs.msi.

3.  Now you have to click on "Select reinstall
mode".

·    Uncheck "Repair all detected reinstall
problems".

·    Check "Force all files to be reinstalled,
regardless of checksum or version".

·    Check "Verify that required user registry
entries are present".

·    Check "Verify that required machine
registry entries are present".

·    Check "Validate shortcuts".

4.  Press OK and REINSTALL

5.  Normally no
reboot is required. Now the web folder client should have been
restored as it was shipped.

--

=====================================================================

Dr. Frank Lowney  [email-masked]

Director, Electronic Instructional Services, a unit
of the

Office of Information and Instructional
Technology,

Professional Pages:
http://www.gcsu.edu/oiit/eis/

Personal Pages:
http://www.faculty.de.gcsu.edu/~flowney

Voice: (478) 445-5260

NOTICE: Please be advised that I am hearing impaired and communicate
most effectively via e-mail.  Follow-up summaries of telephone
conversations by e-mail are most appreciated.

=====================================================================

We don't make instruction effective, we make effective instruction
more accessible.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Dec 2004 21:47:52 +0100

Frank Lowney wrote:
> I am caught in the middle of a "he said - she said" kind of discussion 
> about what constitutes a valid URI/URL for WebDAV and am posting here in 
> the hope of getting an authoritative answer as to which statement is 
> truer: use "+" or use "%20"  Here's the story:
> 
> There is a Learning Management System called WebCT Vista.  It uses an 
> Oracle DB back end and a java-based webserver called "WebLogic" from a 
> company called BEA.  The problem at hand is confined to Windows 
> clients.  Mac clients seems to work as well with this system as they do 
> with Apache and WebSTAR V,  The way WebCT Vista enables the use of 
> WebDAV is that it generates a URI that the client copies and pastes into 
> a WebDAV client application.  Here's an example:
> 
> WebCT Vista puts a "+" char in place of those spaces but this causes 
> Windows clients to gag and report that "The folder you are trying to 
> access is invalid" or words to that effect.  Microsoft has published 
> work around strategies for this (see below the dotted line). This 
> problem manifests itself only where there are spaces in the path and 
> only with the more recent Microsoft clients.  Older clients don't seem 
> to be bothered by this.
> 
> The engineers at WebCT Inc say that the "+" is kosher citing authorities 
> such as:
> 
>     It provides some java classes that does URI encoding.
> 
>     When you get the program running and entered a space, you will get a
>     + in return.
> 
> 
>     If you take a look at the source code, you can find this comment:
> 
> 
>     "The space character ' ' is converted into a plus sign '+'."
> 
> 
> Others suggest that spaces should be encoded as %20 in order to be valid.
> 
> idiosyncratic for WebCT Inc.  More importantly, which encoding strategy 
> is more valid, more robust?
> 

Yes, but in this case it may not be the root of the problem.

It is true that blank spaces must be escaped, but this is usually done 
using "%20". As far I can tell, "+" only has a special meaning within 
the query part.

Details in RFC2396 (<http://greenbytes.de/tech/webdav/rfc2396.html>); 
the W3C is not normative here; in particular not random source code 
samples...

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 9 Dec 2004 12:48:37 -0800

The authoritative reference here is RFC 2396
http://www.ietf.org/rfc/rfc2396.txt
 
According to the BNF productions in Appendix A, the plus character is
perfectly legal within a URI, including HTTP scheme. RFC 2616 explicitly
references RFC 2396.
 
The relevant productions are:
 
URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]

absoluteURI   = scheme ":" ( hier_part | opaque_part )

hier_part     = ( net_path | abs_path ) [ "?" query ]

net_path      = "//" authority [ abs_path ]

abs_path      = "/"  path_segments

path_segments = segment *( "/" segment )

segment       = *pchar *( ";" param )

param         = *pchar

pchar         = unreserved | escaped |

                 ":" | "@" | "&" | "=" | "+" | "$" | ","

Hope this helps.
 
- Jim

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Frank Lowney
Sent: Thursday, December 09, 2004 12:29 PM
To: [email-masked]
Subject: WebDAV, URL encoding and current Windows clients

I am caught in the middle of a "he said - she said" kind of discussion about
what constitutes a valid URI/URL for WebDAV and am posting here in the hope
of getting an authoritative answer as to which statement is truer: use "+"
or use "%20"  Here's the story:

There is a Learning Management System called WebCT Vista.  It uses an Oracle
DB back end and a java-based webserver called "WebLogic" from a company
called BEA.  The problem at hand is confined to Windows clients.  Mac
clients seems to work as well with this system as they do with Apache and
WebSTAR V,  The way WebCT Vista enables the use of WebDAV is that it
generates a URI that the client copies and pastes into a WebDAV client
application.  Here's an example:

http://vista.gsu.edu:8000/webct/webdav/131.96.160.58-1044482159055-328326100
1.flowney/University+System+of+Georgia/Georgia+College+and+State+University/
Documentation/Vista+3.0+Documentation/Vista+3.0+Dox.01/Section+Content

WebCT Vista puts a "+" char in place of those spaces but this causes Windows
clients to gag and report that "The folder you are trying to access is
invalid" or words to that effect.  Microsoft has published work around
strategies for this (see below the dotted line). This problem manifests
itself only where there are spaces in the path and only with the more recent
Microsoft clients.  Older clients don't seem to be bothered by this.

When you get the program running and entered a space, you will get a + in
return.

Is this a peculiarity of Java code, an Oracke requirement or just
idiosyncratic for WebCT Inc.  More importantly, which encoding strategy is
more valid, more robust?

------------------ Microsoft on WebDAV Issues ----------------------------
Some more information for anyone troubleshooting Windows WebDAV connections
http://support.microsoft.com/default.aspx?scid=kb;en-us;269681
Error:

You attempt to add a Web folder to the My Network Places folder, but you are
unsuccessful and you receive the following error message:

This behavior may occur if you have a system policy that redirects the
user's Application Data folder and prevents the creation of the Msdaipp
folder that the Web Folders feature uses. The Msdaipp folder is normally
located under the user's Userprofile\Application Data\Microsoft folder.

When you do not use this system policy, the first time you create a Web
folder in the My Network Places folder with the Add Network Place Wizard, a
subdirectory is created. If you set a system policy to change the
Userprofile\Application Data folder to a universal naming convention (UNC)
on a network server, this wizard does not create the Msdaipp folder at the
redirected location and you receive the preceding error message.

 
However, if the issue persists, please perform the following steps to create
a new account with the Computer Administrator privilege and see how things
are going on.
 
5) Log off the current user account and then log on the new account.
 
Also, please perform the troubleshooting steps in the following article:
287402 ¡§Troubleshooting Web Folders¡¨
http://support.microsoft.com/?id=287402

A)  Replace the + signs with spaces.
e.g.
<http://test.webct.com/webct/webdav/10.1.6.95-1084809904923-2001072000.20010
73000/Domain>
http://test.webct.com/webct/webdav/10.1.6.95-1084809904923-2001072000.200107
3000/Domain Name/Test Instituite
 
B) Sometimes the Web Folder client in Windows could have been changed by
another piece of software (for example, Microsoft Office).  Please consider
following the instructions to restore the WebDAV client to the original one.
 
1.  Find a file called webfldrs.msi (Normally under
WINDOWS\SYSTEM32\webfldrs.msi - if you installed Windows XP Servicepack 1
you will find it under WINDOWS\ServicePackFiles\i386webfldrs.msi).  E.g.
C:\WINNT\system32
2.  Start the installation with double-click or right-click -> webfldrs.msi.
3.  Now you have to click on "Select reinstall mode".
·    Uncheck "Repair all detected reinstall problems".
·    Check "Force all files to be reinstalled, regardless of checksum or
version".
·    Check "Verify that required user registry entries are present".
·    Check "Verify that required machine registry entries are present".
·    Check "Validate shortcuts".
4.  Press OK and REINSTALL
5.  Normally no reboot is required. Now the web folder client should have
been restored as it was shipped.
-- 
=====================================================================
Dr. Frank Lowney  [email-masked]
    Director, Electronic Instructional Services, a unit of the
    Office of Information and Instructional Technology,
    Professional Pages: http://www.gcsu.edu/oiit/eis/
    Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: (478) 445-5260
NOTICE: Please be advised that I am hearing impaired and communicate most
effectively via e-mail.  Follow-up summaries of telephone conversations by
e-mail are most appreciated.
=====================================================================
We don't make instruction effective, we make effective instruction more
accessible.

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 9 Dec 2004 21:50:39 +0100

Frank,

if you look at the URI RFC (old and new) you'll see that spaces in the  
path components are encoded with %20 and that '+' has no special  
meaning there. The encoding with '+' is only used in query parameters  
to the URL. This however is not the case in your example. The URI in  
your example should be endoded using %20.

Regards, Stefan

Am 09.12.2004 um 21:28 schrieb Frank Lowney:

> about what constitutes a valid URI/URL for WebDAV and am posting here  
> in the hope of getting an authoritative answer as to which statement  
> is truer: use "+" or use "%20"  Here's the story:
>
> clients.  Mac clients seems to work as well with this system as they  
> do with Apache and WebSTAR V,  The way WebCT Vista enables the use of  
> WebDAV is that it generates a URI that the client copies and pastes  
> into a WebDAV client application.  Here's an example:
>
> http://vista.gsu.edu:8000/webct/webdav/131.96.160.58-1044482159055 
> -3283261001.flowney/University+System+of+Georgia/ 
> Georgia+College+and+State+University/Documentation/ 
> Vista+3.0+Documentation/Vista+3.0+Dox.01/Section+Content
>
> The engineers at WebCT Inc say that the "+" is kosher citing  
> authorities such as:
>
> When you get the program running and entered a space, you will get a +  
> in return.
>
>  This behavior may occur if you have a system policy that redirects  
> the user's Application Data folder and prevents the creation of the  
> http://test.webct.com/webct/webdav/10.1.6.95-1084809904923 
> -2001072000.2001073000/Domain Name/Test Instituite
>  
> B) Sometimes the Web Folder client in Windows could have been changed  
> by another piece of software (for example, Microsoft Office).  Please  
> consider following the instructions to restore the WebDAV client to  
> the original one.
>  
> WINDOWS\SYSTEM32\webfldrs.msi - if you installed Windows XP  
> Servicepack 1 you will find it under  
> WINDOWS\ServicePackFiles\i386webfldrs.msi).  E.g. C:\WINNT\system32
>  ·    Check "Force all files to be reinstalled, regardless of checksum  
> or version".
> 5.  Normally no reboot is required. Now the web folder client should  
> have been restored as it was shipped.
> --
>

---

From: Jim Luther <[email-masked]>
Date: Thu, 9 Dec 2004 13:03:24 -0800

The problem with the "+" character may be a FAT naming convention  
problem (for the FAT documentation, go to  
<http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx>).  
It says this about FAT short names:

> The following characters are not legal in any bytes of DIR_Name:
> *  Values less than 0x20 except for the special case of 0x05 in  
> DIR_Name[0] described above.
> *  0x22, 0x2A, 0x2B, 0x2C, 0x2E, 0x2F, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E,  
> 0x3F, 0x5B, 0x5C, 0x5D, and 0x7C.

That includes the "+" character (0x2B). It also says this about FAT  
long names:

> The following six special characters are now allowed in a long name.   
> They are not legal in a short name.
>
> +   ,   ;   =   [   ]

So it could be something enforcing FAT short name character limitations.

Just a guess...

- Jim

On Dec 9, 2004, at 12:28 PM, Frank Lowney wrote:

> http://vista.gsu.edu:8000/webct/webdav/ 
> 131.96.160.58-1044482159055-3283261001.flowney/University+System+of 
> +Georgia/Georgia+College+and+State+University/Documentation/Vista+3.0 
> +Documentation/Vista+3.0+Dox.01/Section+Content
>
> http://test.webct.com/webct/webdav/ 
> 10.1.6.95-1084809904923-2001072000.2001073000/Domain Name/Test  
> Instituite
>

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 9 Dec 2004 16:12:30 -0800

OK, here is a suggested examples for REBIND and lock token submission:

Before:

+------------------+
| Root Collection  |
|  bindings:       |
|  CollW           |
+------------------+
     |
     |
     |
+-------------------------------+
| Collection C1                 |<--------+
| LOCKED infinity               |         |
| (lock token L1)               |         |
| bindings:                     |         |
| CollX               CollY     |         |
+-------------------------------+         |
     |                  |                 |
     |                  |  (creates loop) |
     |                  |                 |
+-----------------+  +------------------+ |
| Collection C2   |  | Collection C3    | |
| (inherit lock)  |  | (inherit lock)   | | 
| (lock token L1) |  | (lock token L1)  | |
| bindings:       |  | bindings:        | |
|  {none}         |  | y.gif     CollZ  | |
+-----------------+  +------------------+ |
                       |            |     |
                       |            +-----+
                       |
                   +---------------------------+
                   | Resource R2               |
                   | (lock inhereited from C1) |
                   | (lock token L1)           |
                   +---------------------------+

After:

+------------------+
| Root Collection  |
|  bindings:       |
|  CollW           |
+------------------+
     |
     |
     |
+-------------------------------+
| Collection C1                 |
| LOCKED infinity               |
| (lock token L1)               |
| bindings:                     |         
| CollX                  CollY  |         
+-------------------------------+         
     |              ^      |             
     |              |      |              
+-----------------+ | +------------------+ 
| Collection C2   | | | Collection C3    | 
|(inherited lock) | | | (inherited lock) |
|(lock token L1)  | | | (lock token L1)  |
| bindings:       | | | bindings:        |
| CollA           | | | y.gif            |
+-----------------+ | +------------------+
    |               |    |           
    +---------------+    |          
     (creates loop)      |
                   +---------------------------+
                   | Resource R2               |
                   | (inherited lock from C1)  |
                   | (lock token L1)           |
                   +---------------------------+

Should only involve passing lock token L1 in the If header of the REBIND.

- Jmi

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Dec 2004 17:14:49 +0100

> OK, here is a suggested examples for REBIND and lock token submission:

OK, so this would be either

MOVE /CollW/CollY/CollZ HTTP/1.1
Destination: /CollW/CollX/CollA
If: (<L1>)

or

REBIND /CollW/CollX HTTP/1.1
If: (<L1>)
Content-Type: application/xml

<rebind xmlns="DAV:">
   <segment>CollA</segment>

Do we have consensus to add this example at all? If so, would it make 
sense to *replace* the REBIND example we already have in section 6.1 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.6.1>)?

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 13 Dec 2004 12:15:40 -0800

>    <href>/CollW/CollY/CollZ</href>

I've double-checked this, and believe it to be correct.

> Do we have consensus to add this example at all?

My recollection is that Lisa was in favor, and Geoff was neutral. Given that
we're talking about adding an example, and not additional requirements, my
recommendation is to consider this sufficient rough consensus, and add the
example.

> If so, would 
> it make sense to *replace* the REBIND example we already have 
> in section 6.1 

I'd say no -- having both examples makes sense, since the first one is
relatively simple, and the second one is more complex.

I'd also recommend adding text to the example description along the lines of
"The binding between CollZ and C1 creates a loop in the containment
hierarchy. Servers are not required to support such loops, though the server
in this example does."

The reason for this is to ensure that implementors aren't accidentally left
with the impression they must implement loop-causing bindings.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Dec 2004 23:35:27 +0100

> hierarchy. Servers are not required to support such loops, though the server

Can we rephrase this a bit? It's never one specific binding that creates 
the loop....

> with the impression they must implement loop-causing bindings.

OK, proposed example text in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.6.2>. 
Do we need to say something about the "If" header?

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 13 Dec 2004 16:57:45 -0800

> Can we rephrase this a bit? It's never one specific binding 
> that creates the loop....

Sure. How about:

"This example shows a collection hierarchy with an internal cycle. Servers
are not required to support cycles in the containment hierarchy, though the
server in this example does."

> Do we need to say something about the "If" header?

Seems like a good idea. How about adding, at the end of the sentence ending
in "... to the collection C2.":

An If header is present in the request to submit the lock token for the lock
on the source and destination resources. In this case, the source and the
destination are both covered by the same lock, and hence only one lock token
needs to be supplied.

- Jim