Subject: Re: BIND and live property value consistency

From: Cullen Jennings <[email-masked]>
Date: Sat, 02 Jul 2005 09:17:15 -0700

On 6/27/05 8:22 PM, "Geoffrey M Clemm" <[email-masked]> wrote:

> In particular, the authors of the BIND specification believe
> that the semantics of a live property should be defined by
> the specification that introduces that live property,
> and if those semantics of a given live property are to be
> redefined/refined/clarified, that should be done in a
> specification that obsoletes the one with the original definition.

I have a few random possibilities that might help the WG sort some of this
issue out. Don't take any of these as the chair saying you should do this.
They are just some ideas that might lead to figuring out how to do this.

First, do everyone agree what to do about properties in future specs? I'm
guessing we do but I'm not sure.

One thing I wanted to point out is that an RFC can "update" previous RFC
without obsolescing it. It would be possible to have BIND or bis update all
the previous documents to provide advice on how properties work in the
context of links.

In the glacial time scale that these documents are taking, it seems like bis
and bind will come out at approximately the same time. Would this all be
easier if BIND depended on bis?

The terms "changing the semantics" sounds good but I get a little lost on
what is meant at times. Imagine we have some features of RFC 1000 called A,
then later we defined an extension called RFC 1500 that added a new function
called X. If 1500 added some additional semantics to feature A to define how
it works with function X, that seems all find and dandy. If 1500 redefines
how A works in a way that is not backwards compatible with a client and
server that was written after 1000 but before 1500, this seem like it will
introduce huge interop problems and needs to be considered very carefully.
I'm get lost if we are doing the equivalent of changing how 1000 works or if
we are providing additional information about what you need to do if you do
both 1000 and 1500.

There was a thread were we were trying to figure out how to get each
property to behave. This seems like a really good approach, if we can figure
out how we want them to work, then we can figure out if that is an update to
where they are defined, then we can figure out what document to put the text
it. 

enough rambling, upon more drinking a bunch more coffee, I may realize this
email has nothing of any use :-)

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 02 Jul 2005 09:17:22 -0700

On 6/27/05 8:22 PM, "Geoffrey M Clemm" <[email-masked]> wrote:

> A key question is whether disagreement on such a point
> from a single workgroup participant can veto a specification.

Let me answer about the very general case and not about this specific topic
of BIND. It can be hard to decide how to decide consensus with a group this
small. To answer your question, I think the short answer is mostly No but
the long answer is more complex. I view it as extremely likely that if there
was only a single person that disagreed, I would call it consensus. I would
want to spend the time to make sure that the WG understood the disagreement
and had provided informed comment. However, if the number of people involved
was amazingly small, there would be some point where I would just have to
say this WG is too small to say that the work reflected consensus of any
relevant group and recommend we just close the group. We have so few people,
it would be far easier for me if we came to conclusions that all the key
contributors could live with even if they did not think the decision is the
absolute best path.

On the topic at hand, keep in mind that we have to come to something that
not only makes sense to the WG but also makes sense to the IESG.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 02 Jul 2005 09:17:15 -0700

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 02 Jul 2005 09:17:22 -0700

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Jul 2005 17:01:26 +0200

> guessing we do but I'm not sure.

As far as I can tell, Lisa likes to see new constraints on the behaviour 
on some or all of the DAV:get* properties (which in turn are inherited 
from RFC2616's HTTP response headers).

Looking at 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/0142.html>:

"Where this document explains how MOVE and COPY should work with
getLastModified and ETags, I agree with the explanations.

Where the document explains that ETag behavior on multiple bindings
must remain unspecified, I disagree, as already noted.

Where the document says that header behavior is impossible to predict
because the headers are defined by HTTP, I agree that is the situation
in fact today, however I propose that we do better to help clients
here.  The bind spec can, and should, put more restrictions on servers
that support that spec in how they handle ETags and last-modified
timestamps."

I understand this is an acknowledgment that my analysis about the 
interaction between HTTP's response headers and WebDAV's namespace 
operations 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-properties-latest.html>) 
is indeed correct, but that she would like the BIND spec to introduce 
new constraints.

First of all, it's unclear to me what these new constraints would be, at 
least for the case of DAV:getlastmodified (please clarify).

Furthermore, I don't see *at all* why it would be the BIND spec that 
should introduce these constraints. It may be a good idea to define a 
specific WebDAV profile where clients can rely on some of these 
properties behaving in a more predictable way (including a method for 
clients to detect that), but that would be a *profile* that many 
RFC2518-compliant servers will not be able to implement.

> the previous documents to provide advice on how properties work in the

As a matter of fact, the current draft indeed says that it is updating 
RFC2518 (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#ED_updates> 
for history of decision).

The question is: if we want to state something which is missing from 
RFC2518 (like a discussion about the behaviour DAV:get* properties under 
namespace operations), does it belong into BIND or into RFC2518bis? What 
would be the benefit of putting it into BIND, when many implementors may 
not even read it there?

> easier if BIND depended on bis?

In the end, it won't matter a lot if we really finish RFC2518bis as 
proposed. However, I'm not sure of any objective benefit of that 
compared of letting BIND refer to RFC2518, and having RFC2518bis 
obsolete RFC2518 later.

> introduce huge interop problems and needs to be considered very carefully.

Right.

> we are providing additional information about what you need to do if you do

When we're doing something like fixing the definition of DELETE 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#delete.and.bindings>, 
  this is indeed a fix (RFC2518 said something about DELETE on resources 
with multiple URIs that the WG decided is simply incorrect; also 
resulting in a change in RFC2518bis).

On the other hand, we have been very careful in *not* breaking existing 
semantics for BIND. For instance, instead of changing RFC2518's 
definition of MOVE, we have defined a new method REBIND instead. This 
will allow servers to keep implementing RFC2518's definition of MOVE 
(non-atomic, best effort), while also providing a new method with 
stronger sematics (that however may fail where MOVE succeeded for the 
same parameters).

The proposal to constrain the behaviour of the RFC2616-inherited 
properties IMHO will either cause servers not to be implement BIND at 
all, or not to implement that constraint (thus to be non-compliant). 
Thus, tying both things (authoring/discovery of multiple bindings vs 
live property behaviour) seems to me like a very bad idea.

If anybody wants to make things easier for some clients, the right 
approach seems to define a profile of WebDAV/BIND, and provide a method 
for clients to detect support for that. But this does not belong into BIND.

> where they are defined, then we can figure out what document to put the text

As far as I can tell, there's clearly no consensus for adding new 
constraints. That seems to leave us with the following options:

1) Do not say anything at all; and let RFC2518bis provide additional 
clarification. This makes a lot of sense, because the whole discussion 
is really independant of BIND, because it's a result of namespace 
operations in general.

2) State what really shouldn't need to be stated: live properties behave 
  exactly in the manner defined by their base specs, potentially 
including a table.

My personal preference would be in favor of simplicity (thus 1), but I'm 
open for the other options, if this is what the WG wants.

> email has nothing of any use :-)

Oh yes, it had.

Best regards, Julian

---

From: Brian Korver <[email-masked]>
Date: Tue, 05 Jul 2005 16:30:06 -0700

Geoffrey M Clemm wrote:
> 
> We have gone over these exact arguments many times.
> It is true that we disagree, but that disagreement is over
> a single simple point.
> 

Add me to the "disagree" group.

Certainly there are cases were I agree with the authors of
the BIND spec, but there ar lots of cases when the
redefinition/refinement/clarification is only relevant in
the context of the new document or when it's not possible
to change the document that introduces the live property
(eg 2616) -- in these cases I believe the redefinition/
refinement/clarification should appear in a spec that does
not obsolete the original definition.

-brian
[email-masked]

> 
> Cheers,
> Geoff
> 
> p.s. A few additional comments interspersed below.
> 
> Lisa wrote on 06/27/2005 06:02:28 PM:
>  > We disagree on some pretty fundamental issues here, it seems...
>  >
>  > On Jun 21, 2005, at 10:13 AM, Julian Reschke wrote:
>  > > Let me make some base statements before I dig into the details:
>  > >
>  > > 1) If the spec can't be implemented within Apache/moddav on a Unix  
>  > > filesystem (using hard links), there's something wrong with the spec.
>  >
>  > I am not sure about this.  ACL couldn't be implemented on a Unix  
>  > filesystem using Unix permissions and in the end we had to live with  
>  > that.  For that matter, you can't implement WebDAV properties on a Unix  
>  > fs without creating extra data store constructs of some kind.  So I  
>  > wouldn't agree with a statement this broad although I would agree with  
>  > a statement to the effect that it's a "nice to have" if bindings can be  
>  > implemented using Unix fs hard links.
> 
> A more important point here is that the Unix file system is a common
> example of an existing WebDAV implementation that exposes multiple 
> bindings,
> just as is defined and allowed by RFC 2616 (and therefore inherited by
> RFC 2518). So any constraints you try to place on the semantics of 
> multiple bindings
> are new constraints being placed on existing properties and methods.
> 
>  > > In general, introducing new requirements not present in either 
> RFC2616  
>  > > or RFC2518 is a bad idea.
>  >
>  > I don't agree with this -- a new spec is all about adding new  
>  > requirements.   Are you talking instead about new requirements that  
>  > would affect an implementor who wasn't implementing bindings?  That I  
>  > do agree with, but I'm not suggesting that kind of thing, naturally  
>  > that is ineffectual.
> 
> You appear to be suggesting exactly that kind of thing.  As indicated 
> above,
> multiple bindings are defined in RFC-2616, and exist in common 
> implementations
> (such as Unix file-system based implementations).
> 
>  > The argument (seen elsewhere, e.g. in the property behavior proposal)  
>  > that any feature that is defined in HTTP can't be defined more  
>  > carefully in a draft that extends HTTP is one I have to reject for all  
>  > the interoperability problems that must cause if taken as a general  
>  > argument.  We can't expect authors of specs to be omniscient -- they  
>  > can only deal with issues they are made aware of -- and we must be able  
>  > to help implementors out by making things clear when we have the  
>  > chance.
> 
> And we do so by doing defining a particular property more carefully in
> a "bis" specification that replaces the one that previously defined
> that property, so that the implementor of that property does not have
> to be omniscient and guess all the specifications that they need
> to read in order to understand the behavior of that property.
> 
>  > > 2) The behaviour of live properties for multiple URIs follows the 
> same  
>  > > patterns as for plain HTTP/WebDAV when namespace operations such as  
>  > > MOVE are involved (see discussion in  
>  > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/
>  > > 0001.html>).
>  >
>  > That may be, but I don't see that sufficiently spelled out for  
>  > implementors to end up with something consistent.  Nor do I think we've  
>  > examined all the ramifications of that kind of broad statement.
> 
> The specification is not an implementation guide, exactly to allow for
> a variety of implementations.  So it is not always the case that "more
> guidance is better", if that guidance invalidates reasonable alternative
> implementations.  So this will always be a value-judgement that is unlikely
> to ever get unanimous agreement.
>  
>  > > 3) I disagree that it is a problem when RFC2518bis (containing  
>  > > clarifications on live property behaviour) comes out after BIND; once  
>  > > it's officially updating RFC2518, this is what readers of the BIND  
>  > > spec should read (just like RFC3986 is now the current URI spec, and  
>  > > both RFC2518 and RFC2616 still point to older revisions).
>  >
>  > So Bind will reference RFC2518?  If so, then implementors *can't*  
>  > automatically update the reference to what replaces RFC2518 unless that  
>  > makes no interoperability differences.  To do so would be to be  
>  > non-compliant with Bind and what it references.
> 
> What?  There is a clearly defined IETF process for defining a replacement
> specification (that's what the "obsoletes" keyword is for).
> So "automatically updating the reference to what replaces
> RFC2518" is exactly what is expected from all implementors, just as they
> were expected to implement RFC2616 instead of RFC2068.
> 
>  > That also means that implementors of RFC2518 and RFC2616 can't cause  
>  > backward-compatibility problems with clients by implementing RFC3986  
>  > and still claim compliance with RFC2518/2616.
> 
> That is exactly what they can (and are expected) to do.  Of course, the
> authors of RFC3986 worked hard to minimize those backward compatibility
> issues with RFC2396 (just as the authors of RFC2518bis
> are expected to minimize the backward compatibility issues with RFC2518).
> 
> The rest of the message below should appear in an RFC2518bis thread,
> so I'll wait to respond to it until it appears there.
> 
>  > >>  - If the spec says that the value MUST be the same on all bindings,  
>  > >> then this makes for the easiest and most efficient client  
>  > >> synchronization operations.  OTOH a few server implementations must  
>  > >> change a little bit to correctly implement BIND.  I think this is  
>  > >> fine -- a minor server burden for increased efficiency and  
>  > >> simplicity.
>  > >
>  > > As I have pointed out multiple times (see link above), this does not  
>  > > work. Servers must have the freedom to adjust ETags because of  
>  > > namespace operations, so they also need to be able to do that for  
>  > > BIND. Could you *please* follow up on the analysis in  
>  > > <http://greenbytes.de/tech/webdav/draft-reschke-webdav-namespace-vs-
>  > > properties-latest.html>? Thanks.
>  >
>  > Where this document explains how MOVE and COPY should work with  
>  > timestamps.
>  > >> DAV:creationdate
>  > >> RFC2518 defined this property and didn't tie it to any locking or 
> GET  
>  > >> request behavior, and it isn't used for synchronization or cache  
>  > >> refreshes.  Thus we have little to guide us on behavior but OTOH  
>  > >> probably not a lot of problems caused if we go either way.
>  > >>  - If the spec states that the value MUST be the same on all 
> bindings  
>  > >> and that it MUST be the date the resource was first created (e.g.  
>  > >> with PUT), then this is the best case for people viewing 
> creationdate  
>  > >> (as some clients already display it).  It makes most sense to the  
>  > >> person that creation date be the date of first uploading the content.
>  > >>  - If the spec states that the value MUST be the same on all 
> bindings  
>  > >> and that it MUST be the date the last binding was created that could  
>  > >> be a little weird.
>  > >>  - If the spec explicitly allows different bindings to have 
> different  
>  > >> creationdate values then this implies that the creationdate is the  
>  > >> date of creation of the binding.  That's not unreasonable.  
>  > >> Presumably a client could find the oldest binding and use its  
>  > >> creationdate as the resource creationdate.
>  > >>  - If the spec is silent then we really don't know if creation date  
>  > >> refers to creation of the resource or of the binding.  A person 
> using  
>  > >> a client that simply displays the value might notice the different  
>  > >> behaviours on different servers.  A document retention or document  
>  > >> archival program might produce quite different results depending on  
>  > >> how this was implemented.  A cautious and perceptive client or agent  
>  > >> implementor would have to assume that they might vary and would have  
>  > >> to check all bindings.  OTOH there are already clients and archival  
>  > >> programs which aren't aware of bindings and these would have to be  
>  > >> upgraded to check the creationdate on different bindings in order to  
>  > >> regain predictable behavior.
>  > >
>  > > I disagree. DAV:resourcetype is defined by RFC2518 to be a property 
> of  
>  > > the resource; and the whole point of the BIND spec is to define  
>  > > behaviours for multiple URIs mapped to the same resource. So it seems  
>  > > to be straighforward that the DAV:creationdate will be the same for  
>  > > all URLs (just like DAV:lockdiscovery).
>  >
>  > I agree that DAV:creationdate should be the same for all URLs to the  
>  > same resource.  I think that's the best option and I'd like that added  
>  > to the spec.
>  >
>  > >>  - If the spec says that displayname MUST be consistent across  
>  > >> bindings, then some implementations would have to change the way 
> they  
>  > >> calculate displayname in order to implement BIND.  I would argue 
> that  
>  > >> would be a good thing and would help alleviate the uncertainty in  
>  > >> RFC2518.
>  > >
>  > > I agree that it would be good if servers would behave that way, and  
>  > > thus we should clarify that in RFC2518bis.
>  >
>  > The Bindings spec also can, and should, say something about this,  
>  > particularly if it references RFC2518.
>  >
>  > >> DAV:source
>  > >> This property isn't widely implemented so it's hard to make any  
>  > >> statements about implementations or about implications of 
> consistency  
>  > >> across bindings.
>  > >> General case
>  > >> It would be best if BIND could say something about the general case  
>  > >> of live properties even if it leaves some leeway for future live  
>  > >> properties to be defined as exceptions to the general case. Based on  
>  > >> looking at the live properties defined in RFC2518, we could define  
>  > >> those as being the same values across all bindings.  The 
> consequences  
>  > >> of this would be more
>  > >
>  > > I guess you mean those except the DAV:get* properties defined by  
>  > > RFC2616?
>  >
>  > No, I think we could include those as well and it would improve  
>  > interoperability and make implementations more consistent.   I bet that  
>  > if servers implementing Binding were required to do these properties a  
>  > certain way, then even other servers that don't implement Binding would  
>  > find the guidance and example helpful and can decide whether to update  
>  > their implementations accordingly even if they're not required to.
>  >
>  > >
>  > >> consistent and clear server behavior and easier client  
>  > >> implementations, at the cost of some server implementations having 
> to  
>  > >> change a few things in order to become compliant with BIND.  It's  
>  > >> conceivable that such a clear requirement would rule out some  
>  > >> imaginative and odd ways of implementing new  or custom 
> functionality  
>  > >> based on bindings and existing live properties, which might not be a  
>  > >> bad thing.  A clear requirement for existing live properties to have  
>  > >> the same values on all bindings could still allow for exceptions for  
>  > >> new live properties defined differently, and thus not close off  
>  > >> future innovation.
>  > >
>  > > How about suggesting a concrete wording? First thing we should do 
> then  
>  > > is to test it against what RFC3253, RFC3648 and RFC3744 already  
>  > > define.
>  >
>  > I am not sure about RFC3253.  It's got a bunch of very complex stuff  
>  > and I am not sure how all its properties should behave.  However, for  
>  > the others , I suggest wording along these lines:
>  >
>  > "The live properties defined in RFC2518, RFC3648 and RFC3744 are all  
>  > resource properties, and therefore those values MUST NOT vary due to  
>  > the binding used to access the resource."
>  >
>  > Lisa
>  >
>  >

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Jul 2005 02:40:22 +0200

Brian Korver wrote:
> ...

OK.

Let's start with the hardest one. As far as I understand, Lisa wants the 
BIND spec to put additional constraints on how DAV:getlastmodified, i.e. 
the HTTP lastmodified response header, behaves. Right now, I have 
absolutely no idea what kind of constraint this could be.

Please make a proposal for actual spec text that the WG can consider.

Best regards,

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 06 Jul 2005 09:10:17 -0700

Sure; how about this?  The general requirement and specific requirement  
don't have to be in the same place in the document so I've called them out  
separately.

General requirement: "All live properties defined in RFC2518 MUST have the  
same value across all bindings to the same resource. "

Specific: "The DAV:getlastmodified property MUST change when the  
underlying resource body is altered.  The property value MUST NOT change  
when a new binding to the resource is created or when a binding to the  
resource is removed.  If a collection has a DAV:getlastmodified property  
then its value SHOULD change whenever its set of bindings changes  
(including new bindings, removed bindings or bindings where the name or  
target changes).  "

I'm sure this could use some tweaking, but this is the general idea.  With  
these requirements the property continues to behave the way that it would  
before bindings, tied to the HTTP header and all.  A client that is  
unaware that bindings exist would not find any unusual behavior as a  
result of these requirements -- a PUT would still update the last modified  
stamp, and creation or deletion of a binding elsewhere (an event  
unnoticeable by a client that doesn't support bindings) wouldn't  
surprisingly change the value.

Lisa

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Jul 2005 18:18:30 +0200

Lisa Dusseault wrote:
> don't have to be in the same place in the document so I've called them 
> out  separately.
> 
> General requirement: "All live properties defined in RFC2518 MUST have 
> the  same value across all bindings to the same resource. "
> 
> underlying resource body is altered.  The property value MUST NOT 
> change  when a new binding to the resource is created or when a binding 
> to the  resource is removed.  If a collection has a DAV:getlastmodified 
> property  then its value SHOULD change whenever its set of bindings 
> changes  (including new bindings, removed bindings or bindings where the 
> name or  target changes).  "

Well, as I have explained multiple times, this doesn't reflect reality. 
Servers *do* have to change the lastmodified date because of namespace 
operations; otherwise it will loose it's HTTP-2616-defined semantics.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 6 Jul 2005 19:39:21 -0400

I agree with Julian.

For folks that may have missed Julian's previous explanations, if:
- a resource at /x/foo.html has getlastmodified value of 57
- a resource at /y/bar.html has getlastmodified value of 48,
- /x/foo.html is deleted
- BIND creates a second binding to /y/bar.html at /x/foo.html.
then:
- the getlastmodified value of /y/bar.html must be updated to be
at least 49.

This is illustrative of the general principle that the behavior
of properties should be defined without trying to treat multiple
bindings as a special case (i.e. any implementation that satisfies
the definition of that property should be acceptable, and shouldn't
be constrained by some "implementation advice" in the BIND specification).

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 6 Jul 2005 19:52:31 -0400

Argh.  I should have said: "must be updated to be at least 58"

Cheers,
Geoff

Geoff wrote on 07/06/2005 07:39:21 PM:
> if:

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 07 Jul 2005 10:07:29 -0700

It's too bad about confusing existing clients when 'getlastmodified'  
changes on some resource without any body changes (the client may be  
completely unaware of bindings changse going on elsewhere), but I guess  
that's a less bad approach than possibly causing synchronization errors.

To me this seems like a perfect argument for requirements in the BIND  
spec, not just implementation advice.  Because of the synchronization  
problems clients would have if implementors do it wrong, we should add:

"WebDAV (RFC2518) states that the getlastmodified property value MAY be  
updated when changes are made to the resource even if the changes aren't  
to the resource body.  However, because clients may synchronize resources  
based on the value of this property, and because a binding to one resource  
at URL A may replace another binding at the same address, this requires a  
new getlastmodified date in order to trigger the client to synchronize  
properly.  Thus, the server MUST update the getlastmodified property value  
whenever a new binding is added to an existing resource as well as when  
REBIND is used."

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Jul 2005 19:23:09 +0200

Lisa Dusseault wrote:
> updated when changes are made to the resource even if the changes 
> aren't  to the resource body.  However, because clients may synchronize 
> resources  based on the value of this property, and because a binding to 
> one resource  at URL A may replace another binding at the same address, 
> this requires a  new getlastmodified date in order to trigger the client 
> to synchronize  properly.  Thus, the server MUST update the 
> getlastmodified property value  whenever a new binding is added to an 
> existing resource as well as when  REBIND is used."
> 
> Lisa

Lisa,

in this case, MUST is wrong as well. A server may very well be aware of 
any resource mapped previously to that URI, so it *could* make a better 
decision.

Anyway, this is a generic HTTP vs WebDAV issue, so please add it to the 
RFC2518bis issues list; and let's resolve it there.

Best regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 07 Jul 2005 13:29:51 -0700

Well I think the MUST is better than nothing, but there's probably other  
alternatives -- a careful SHOULD, or even a more nuanced requirement.

"WebDAV states that the getlastmodified property MAY be udpated when  
changes are made to the resource even if the changes aren't to the  
resource body, and this naturally includes changes to the resource's  
bindings.  Note however that clients might use Last-Modified to  
synchronize changes to resources, so servers MUST ensure that the value is  
updated in order to allow synchronization to be correct.  For example,  
when a binding to a resource with last-modified time T1 is replaced with a  
binding to a resource with last-modified time T2, the server either has to  
ensure that T2>T1 or update it accordingly."

Lisa

On Thu, 07 Jul 2005 10:23:09 -0700, Julian Reschke <[email-masked]>  
wrote:

>> completely unaware of bindings changse going on elsewhere), but I  
>> guess  that's a less bad approach than possibly causing synchronization  
>> errors.
>>  "WebDAV (RFC2518) states that the getlastmodified property value MAY  
>> be  updated when changes are made to the resource even if the changes  
>> resources  based on the value of this property, and because a binding  
>> to one resource  at URL A may replace another binding at the same  
>> address, this requires a  new getlastmodified date in order to trigger  
>> the client to synchronize  properly.  Thus, the server MUST update the

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 7 Jul 2005 16:42:42 -0400

As Julian states below, this is a very reasonable thread to pursue in
the context of RFC2518bis, and given that RFC2518bis
is a current high priority deliverable for this workgroup, it baffles me 
why we
are having this discussion in a BIND protocol thread.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Jul 2005 13:43:31 +0200

> are having this discussion in a BIND protocol thread.

Same here.

Below is a proposed modest addition to 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.6>, 
which currently reads:

"Consistent with [RFC2518] the value of a dead property MUST be 
independent of the number of bindings to its host resource or of the 
path submitted to PROPFIND."

Proposed text:

"Consistent with [RFC2518], the value of a dead property MUST be 
independent of the number of bindings to its host resource or of the 
path submitted to PROPFIND.  On the other hand, the behaviour for each 
live property depends on it's individual definition, which in turn 
should define how the property value behaves (for example, see 
[RFC3744], section 5, paragraph 2)."

Feedback appreciated,

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 08 Jul 2005 09:13:24 -0700

I agree with adding the proposed wording (except note "it's" needs no  
apostrophe), however I don't consider it sufficient unless BIND builds on  
RFC2518bis where we can make these definitions clear.

Lisa

On Fri, 08 Jul 2005 04:43:31 -0700, Julian Reschke <[email-masked]>  
wrote:

>> is a current high priority deliverable for this workgroup, it baffles  
>> me why we

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 8 Jul 2005 12:24:55 -0400

The proposed additional text is fine with me, although I'd probably
delete the phrase "which in turn should define how the property value
behaves", since I believe it is redundant.

Cheers,
Geoff

> > is a current high priority deliverable for this workgroup, it baffles 
me

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Jul 2005 19:14:14 +0200

> behaves", since I believe it is redundant.

Good point. New proposed text 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.6>):

"2.6. PROPFIND and Bindings

Consistent with [RFC2518], the value of a dead property MUST be 
independent of the number of bindings to its host resource or of the 
path submitted to PROPFIND. On the other hand, the behaviour for each 
live property depends on its individual definition (for example, see 
[RFC3744], section 5, paragraph 2)."

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Jul 2005 19:32:15 +0200

Lisa Dusseault wrote:
> apostrophe), however I don't consider it sufficient unless BIND builds 
> on  RFC2518bis where we can make these definitions clear.

OK,

to summarize: Lisa prefers to either delay BIND (by making it depend on 
RFC2518bis), or to duplicate explanations (that will need to go into 
RFC2518bis anyway). Geoff and I think that the draft as currently 
proposed is clear enough, and that none of the alternatives proposed by 
Lisa are better (Geoff, you'll correct me if I'm wrong here).

At this point I propose that the WG makes a decision on this; it seems 
that all arguments have been exchanged on this and we really have more 
important work to do.

Speaking of which:

- What is the current RFC2518bis issues list 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/buglist.cgi?product=WebDAV-RFC2518-bis>, 
<http://www.webdav.org/wg/rfcdev/issues.htm> or something else?), and 
who is maintaining it?

- Is there a document change history that tracks all changes that have 
been made in the last (expired) draft 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-06.txt>) 
compared to RFC2518?

- Are there any plans to actually start working on the draft again? Is 
there anything holding us back besides the three WGLCs we're just finishing?

Best regards,

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 08 Jul 2005 10:42:58 -0700

> (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-06.txt>)  

Yes -- RFC2518 Changes.doc
I have been hosting this at  
http://www.sharemation.com/%7Emilele/public/dav/
but I'll move it to our share at http://ietf.webdav.org/webdav with the  
next version.

> there anything holding us back besides the three WGLCs we're just  

Yes, and yes -- there are a bunch of issues I was unable to determine  
consensus on very well while I was chair.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Jul 2005 20:05:15 +0200

Lisa Dusseault wrote:
>> - Is there a document change history that tracks all changes that 
>> have  been made in the last (expired) draft  

As far as I can tell, this document was last changed over two years ago, 
  maybe there's a newer version somewhere else???

>> - Are there any plans to actually start working on the draft again? 
>> Is  there anything holding us back besides the three WGLCs we're just  
>> finishing?
> 
> 

So what's your proposal how we the WG should proceed. In particular, 
what about the state of the issues list I asked about?

Best regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 08 Jul 2005 11:57:48 -0700

> what about the state of the issues list I asked about?
That's up to Cullen, and I don't know the state of the issues list except  
that it's out-of-date.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Sat, 09 Jul 2005 09:20:24 +0200

Lisa Dusseault wrote:
> 
> On Fri, 08 Jul 2005 11:05:15 -0700, Julian Reschke 
> <[email-masked]>  wrote:
> 
> 
>>
> That's up to Cullen, and I don't know the state of the issues list 
> except  that it's out-of-date.

Let's rephrase that: you say that you think you have the editor role for 
RFC2518bis. In case you'd be starting to work on it again, where would 
you look for the next to-do item?

Best regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 09 Jul 2005 17:10:05 -0700

> you look for the next to-do item?

I am starting work on it again, and I'm reviewing the latest draft to see  
which features still remain that haven't had demonstrated implementation  
and interoperability.  I figured I'd catch up with the main to-do list  
once it had been updated or regenerated.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jul 2005 10:22:00 +0200

Lisa Dusseault wrote:
> 
> 
> On Sat, 09 Jul 2005 00:20:24 -0700, Julian Reschke 
>> Let's rephrase that: you say that you think you have the editor role 
>> for  RFC2518bis. In case you'd be starting to work on it again, where 
>> would  you look for the next to-do item?
>>
> 
> I am starting work on it again, and I'm reviewing the latest draft to 
> see  which features still remain that haven't had demonstrated 
> implementation  and interoperability.  I figured I'd catch up with the 
> main to-do list  once it had been updated or regenerated.

If I understand you right, you will not update (and keep up-to-date) at 
least one of the two issues lists we have?

Some more thoughts about how I think we need to proceed with RFC2518bis:

- Any change compared to RFC2518 (unless really strictly editorial) 
needs to have a well-understood issue description; and a WG consensus 
for changing it.

- Consequently, changes in the latest draft that can't be traced to one 
of these will need to be backed out.

- RFC2518bis needs to have a complete appendix listing all non-editorial 
changes compared to RFC2518.

- If we think that RFC2518 contains stuff for which there is no 
demonstrated interoperability, we should add that to the issues list as 
action item.

Finally,

- we go through the issues list until all issues are closed (where 
"closed" can also mean that the WG just states that it was unable to 
come up with a resolution)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Jul 2005 10:55:27 +0200

> come up with a resolution)

One additional thought:

If -- while doing this -- we find that we can't resolve everything or if 
we find features that we think need to be kept although no interop was 
demonstrated, not going to "Draft" standard and republishing as 
"Proposed" should be considered a viable option (compared to giving up).

In practice, few people really understand the different standards 
levels; and not updating the spec (with many known and resolved(!) 
issues) at all certainly is worse then doing the update, but not 
progressing on the standards ladder.

Best regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 10 Jul 2005 16:03:58 -0700

At this point it would be good to be clear about what we're doing.  I  
propose we try for Draft Standard and follow the rules that implies.  Do  
you think there's some reason we won't be able to do that?

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Jul 2005 08:02:42 +0200

Lisa Dusseault wrote:
> propose we try for Draft Standard and follow the rules that implies.  
> Do  you think there's some reason we won't be able to do that?

Yes. There are some things in the draft that are new; so if we want to 
keep them, we better make sure they are implemented somewhere very soon 
(I'm thinking of PROPFIND/dead-props, the DAV:lockroot element or the 
Force-Authenticate header).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Jul 2005 14:50:52 +0200

> [RFC3744], section 5, paragraph 2)."

There's a deadline for Internet Draft submissions next Monday. To make 
sure that all WGLC'd drafts have up-to-date versions published before 
the IETF meeting in Paris, I'll submit this version before the end of 
this week. (so if somebody disagrees with this change, please speak up 
soon!).

Best regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 11 Jul 2005 11:28:08 -0700

Agreed.  I don't know for sure of any implementations myself.  Anybody?

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Jul 2005 12:46:05 +0200

> Agreed.  I don't know for sure of any implementations myself.  Anybody?

PROPFIND/dead-props and DAV:lockroot are implemented in our server and 
client. So if one other client/server implementation had this (Xythos 
comes to mind), we could leave it in.

Best regards, Julian

---

From: John Baumgarten <[email-masked]>
Date: Wed, 13 Jul 2005 17:49:03 -0700

.Mac iDisk implements dead-props, but not lockroot.  We don't  
implement Force-Authentication, but would if standardized.

-Jake

On Jul 11, 2005, at 11:28 AM, Lisa Dusseault wrote:

> On Sun, 10 Jul 2005 23:02:42 -0700, Julian Reschke  
>>>  At this point it would be good to be clear about what we're  
>>> doing.  I  propose we try for Draft Standard and follow the rules  
>>> that implies.  Do  you think there's some reason we won't be able  
>>> to do that?
>>>
>>
>> Yes. There are some things in the draft that are new; so if we  
>> want to keep them, we better make sure they are implemented  
>> somewhere very soon (I'm thinking of PROPFIND/dead-props, the  
>> DAV:lockroot element or the Force-Authenticate header).
>>
>> Best regards, Julian
>>
>
>
>
> --