Subject: BIND and live property value consistency

From: Lisa Dusseault <[email-masked]>
Date: Sun, 19 Jun 2005 13:04:26 -0700

As Julian recently noted, the behavior of live properties on bindings 
(or on resources with multiple bindings) has been raised.  I still 
don't consider the issue closed and since we're reraising these issues, 
I wanted to methodically consider some of the implications of requiring 
consistency, of explicitly allowing variation, or of the spec remaining 
silent.

Important note:  Some of the confusion around these properties is 
increased by lack of explicitness in RFC2518 (source, displayname in 
particular).  If BIND depends on RFC2518 instead of 2518bis, that may 
have different implications for our decisions about the consistency of 
property values across bindings.   As we've discussed before, there's a 
certain amount of clarification that should be added to 2518bis about 
whether properties apply to underlying resources, but if BIND is issued 
as an RFC depending on 2518, before 2518bis is issued, then BIND 
implementors won't be able to benefit from clarifications in 2518bis.

DAV:getcontentlanguage
DAV:getcontentlength
DAV:getcontenttype

RFC2518 defines these as the values returned in a GET response in the 
Content-Language, Content-Length and Content-Type headers, so the value 
of this property can vary on bindings only if the GET response also 
varies on bindings.  Yet, the BIND spec doesn't require that the GET 
response be the same regardless of binding URL used.  A server could 
conceivably see bindings as a creative way of handling variant access 
or access to source/output versions of a dynamic resource, because 
bindings would allow a bindings-aware client to discover the other URLs 
and possibly to modify variants or source.  I wouldn't say I recommend 
this approach but it's not forbidden.
  - We don't have evidence so far that any implementations do anything 
other than keep these values consistent across bindings.
  - If the spec says that the values MUST be the same on all bindings, 
then servers can't implement odd features like using one binding to get 
to the German version of a resource, and the other binding to get the 
French version.    That seems fine to me, there are other, probably 
better ways of handling access to variants and source/output than using 
bindings.
  - If the spec explicitly allows variation, then clients must download 
the property separately for each binding if they care about it, and we 
might want to say something about why they could vary.
  - If the spec remains silent, we're unlikely to see odd 
implementations of this but it's conceivable.  A cautious and 
perceptive client implementor would behave as if it could differ and 
download the property an extra time for every binding.

DAV:getetag

Although RFC2518 says that this is tied to the ETag header value in a 
GET response, this is a little different than the last three, because 
it's perfectly conceivable for two URLs to have the same GET response 
(byte for byte) and yet have different ETag values.
  - We have evidence that server implementations use the URL to 
calculate the ETag, so presumably it would be easiest for those to 
continue that behavior.  OTOH some server implementations only base the 
ETag on resource characteristics, not on bindings.
  - 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.
  - If the spec explicitly allows variation, then clients must behave as 
if it does vary in order to interoperate against different servers. In 
some situations the client will have to query the ETag on several 
bindings to the same resource to verify whether it needs to 
resynchronize the resource, resulting in more roundtrips.  Of course 
the client is likely to behave the same way with all servers supporting 
bindings even if the ETag doesn't vary according to URL.
  - If the spec is silent, then a cautious and perceptive client 
implementor would behave as if the property could differ and do the 
extra work -- again, possibly unnecessary.

DAV:supportedlock
DAV:lockdiscovery

Since the BIND spec clearly states that locks are on resources, not on 
URLs, it's a pretty obvious assumption that the values of the 
lock-related properties must also be related to resources and not vary 
depending on URL.
  - If the spec states that the value MUST be the same on all bindings, 
I see no harm.
  - If the spec explicitly allows variation, that would be pretty weird. 
  I'm not sure what we would say to justify that.
  - If the spec remained silent, well, probably no harm, that would only 
be weird if the spec were explicit about other property behaviors.

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.

DAV:getlastmodified

Again, RFC2518 defines this as the value of the Last-Modified header on 
the GET request, but the server has a lot of leeway to set this to the 
last time the underlying resource was changed, or to update this when a 
new binding is created -- perhaps only the newest binding would have a 
different value because it was created after the underlying resource 
was last changed.
  - The implementations I know of would probably treat this as the time 
the underlying resource body was last modified.
  - If the spec states that this value MUST be the same on all bindings, 
and that it MUST reflect only changes to the body of the underlying 
resource, that would be the most clear and useful statement for clients 
-- clients could simply display this and users would easily be able to 
confirm that if this value changed then somebody had changed the body 
of the resource.  Servers would have to implement this in the same way 
when they add BIND support and I'm not aware of any problems that would 
cause.  Clients might sometimes see a new URL appear in a collection on 
date D2, when the last-modified time is a timestamp D1 from much 
earlier (before the client last synchronized, for example), but that 
seems unlikely to cause bugs.
  - If the spec explicitly allows this to vary then the spec probably 
has to say something about what that means.
  - If the spec remains silent, then a cautious and perceptive client 
implementor would have to assume that it could mean anything.  I'm not 
sure if it would be best to download all the different bindings' 
getlastmodified times to see if they're different.  If they are 
different, what would the client do?  Display the earliest one?  The 
latest one?  Which value would be most helpful to the user?  Again, 
existing document archive and retention programs would probably show 
different behavior if servers end up calculating this property in 
different ways.

DAV:displayname

RFC2518 underspecifies this property and we know the problems that has 
caused. Nevertheless BIND could say something here.
  - We do have implementation evidence that some implementations 
calculate display name from the URL, thus it could conceivably vary 
according to binding.  We also know some implementations store display 
name as if it were a dead property, thus it would not vary according to 
binding.
  - 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.
  - If the spec explicitly allows this to vary, that implicitly supports 
the calculated displayname model.  Probably, however, servers which 
keep the value consistent would continue to do so.
  - If the spec is silent, then a cautious and perceptive client 
implementor would have to assume that displayname could vary and 
download it again for every binding if the client needs this property.

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 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.

Lisa

---

From: Manfred Baedke <[email-masked]>
Date: Tue, 21 Jun 2005 11:23:58 +0200

Hello,

As a mere implementor, I have never posted on this list before, but now 
I am getting a little worried. I have been working on a specific backend 
for the SAP Netweaver WebDav server that does not (and never will) 
implement BIND. But it does implement large parts of RFC 3253. In 
particular it supports the Version-Controlled-Collection feature, which 
forces the existence of multiple bindings of the same resource in some 
cases.
Our implementation neither implements BIND nor a spec depending on BIND. 
So I really do not want BIND to put any constraints on our implementation.
The existence of multiple bindings has nothing to do with the existence 
of the BIND method. The BIND spec is the wrong place to describe the 
behavior of properties that are defined by other specifications under 
methods that are defined by other specifications.

Regards,
Manfred

Lisa Dusseault wrote:
> (or on resources with multiple bindings) has been raised.  I still don't 
> consider the issue closed and since we're reraising these issues, I 
> wanted to methodically consider some of the implications of requiring 
> conceivably see bindings as a creative way of handling variant access or 
> access to source/output versions of a dynamic resource, because bindings 
> would allow a bindings-aware client to discover the other URLs and 
> possibly to modify variants or source.  I wouldn't say I recommend this 
> approach but it's not forbidden.
>  - If the spec remains silent, we're unlikely to see odd implementations 
> of this but it's conceivable.  A cautious and perceptive client 
> implementor would behave as if it could differ and download the property 
> an extra time for every binding.
> 
> DAV:getetag
> 
>  - We have evidence that server implementations use the URL to calculate 
> the ETag, so presumably it would be easiest for those to continue that 
> behavior.  OTOH some server implementations only base the ETag on 
> resource characteristics, not on bindings.
> resynchronize the resource, resulting in more roundtrips.  Of course the 
> client is likely to behave the same way with all servers supporting 
>  - If the spec states that the value MUST be the same on all bindings, I 
> see no harm.
> different value because it was created after the underlying resource was 
> last changed.
> confirm that if this value changed then somebody had changed the body of 
> the resource.  Servers would have to implement this in the same way when 
> they add BIND support and I'm not aware of any problems that would 
> date D2, when the last-modified time is a timestamp D1 from much earlier 
> (before the client last synchronized, for example), but that seems 
> unlikely to cause bugs.
>  - If the spec explicitly allows this to vary then the spec probably has 
> to say something about what that means.
>  - 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.
> the calculated displayname model.  Probably, however, servers which keep 
> the value consistent would continue to do so.
> 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 
> 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.
> 
> Lisa
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Jun 2005 19:13:49 +0200

Lisa,

thanks for the feedback.

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. In 
general, introducing new requirements not present in either RFC2616 or 
RFC2518 is a bad idea.

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>).

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).

> implementors won't be able to benefit from clarifications in 2518bis.

---> 3).

> an extra time for every binding

Agreed, except I'm not sure what you call "odd". If RFC2616 allows this 
behaviour, and RFC2616 ultimately defines the semantics of these 
properties, it's not up to us to decide what's "odd"...

> (byte for byte) and yet have different ETag values.

I don't agree here that it's different. DAV:etag is whatever the server 
returns upon GET as "ETag" response header. Same behaviour as for the 
above three.

> resource characteristics, not on bindings.

Yes. Some really have unique ideas for each content body that's there, 
others compute it dynamically based on timestamps and such.

> -- 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.

> bindings even if the ETag doesn't vary according to URL.

Yes.

> extra work -- again, possibly unnecessary.

Yes.

>  - If the spec states that the value MUST be the same on all bindings, I 

Agreed.

>  I'm not sure what we would say to justify that.

I think that would be a bug.

> be weird if the spec were explicit about other property behaviors.

Yes.

> 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).

> different behavior if servers end up calculating this property in 

But the DAV:getlastmodified falls into the same category as all the 
other DAV:get* properties. They are defined as per RFC2616, and as I 
have shown multiple times, you cannot rely on them to be stable across 
namespace operations (be it MOVE or BIND). So we really cannot say 
anything above what RFC2616 already says.

> caused. Nevertheless BIND could say something here.

How? If it's underspecified in RFC2518 (with which I agree), it needs to 
be clarified in RFC2518bis...

> name as if it were a dead property, thus it would not vary according to 

Yes.

> 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.

> download it again for every binding if the client needs this property.

Depends on what RFC2518 and our bis issues list say; and whether 
there'll be servers that actually do implement multiple bindings while 
having the per-URL displayname functionality. I'm not aware of any.

> 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?

> 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.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 27 Jun 2005 15:02:28 -0700

We disagree on some pretty fundamental issues here, it seems...

On Jun 21, 2005, at 10:13 AM, Julian Reschke wrote:

> 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.

> 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.

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.

> patterns as for plain HTTP/WebDAV when namespace operations such as  
> MOVE are involved (see discussion in  

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.

> 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.

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.

>> change a little bit to correctly implement BIND.  I think this is  
>> fine -- a minor server burden for increased efficiency and  
>> simplicity.
>
> 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  
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.

>> 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.
>> and that it MUST be the date the last binding was created that could  
>> be a little weird.
>> 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.
>> refers to creation of the resource or of the binding.  A person using  
>> a client that simply displays the value might notice the different  
>> 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  
> 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.

> 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.

>> 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  
>> of this would be more

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   
>> new live properties defined differently, and thus not close off  
>> future innovation.
>

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: Geoffrey M Clemm <[email-masked]>
Date: Mon, 27 Jun 2005 23:22:56 -0400

We have gone over these exact arguments many times.
It is true that we disagree, but that disagreement is over
a single simple point.

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.

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

Cheers,
Geoff

p.s. A few additional comments interspersed below.

> 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. 

> do agree with, but I'm not suggesting that kind of thing, naturally 

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).

> to help implementors out by making things clear when we have the 

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.

> 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.
 
> 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.

> 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.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Jun 2005 17:14:53 +0200

Yes.

Agreed.

The other point we seem to disagree upon is that BIND should only be 
applicable to a certain class of servers that indeed can maintain the 
live properties the way many wish. I absolutely agree in that it's a 
good thing if a server behaves that way, but I also think that BIND 
shouldn't mandate that. We conceivably could do two things:

- in RFC2518bis, clarify the issues that arise because of the 
interaction between DAV:get* properties inherited from HTTP and the 
WebDAV namespace operations (for instance, state that a server must do 
post-namespace-op-cleanup of for instance DAV:getlastmodified; and also 
suggest that having strong entity tags that are unique across the 
server's whole namespace will make that unnecessary for DAV:getetag)

- define a specific profile (putting additional constraints on the 
behaviour of some of these live properties), and make that 
client-detectable (for instance through a specific DAV: header option).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Jun 2005 17:39:29 +0200

> implemented using Unix fs hard links.

The issue with Apache/mod_dav is this: mod_dav does *not* compute entity 
tags (or lastmodified on it's own), it simply uses the ones already 
implemented in httpd (or whatever the name of the base component is). 
This core component is designed to function completely independantly of 
WebDAV, so it's simply impossible to change the ETag requirements here. 
Of course things look different if a server implements all of 
HTTP/WebDAV/BIND in the same place, but that approach simply isn't going 
to work in all use cases.

>> In general, introducing new requirements not present in either 
>> RFC2616  or RFC2518 is a bad idea.
> 
> 

Actually, this is what you seem to suggest. You're asking for new 
requirements on the behaviour of DAV:get* properties, and these 
requirements affect all servers, not only those aware of bindings.

> to help implementors out by making things clear when we have the  chance.

It depends on what the target audience of that spec is. Of course you 
can profile HTTP/WebDAV for some specific scenarios, but that also means 
that what you spec may not be implementable for many servers. This is 
something the BIND spec editors want to avoid.

>> 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  

OK, so that's a To-Do item for RFC2518bis.

> So Bind will reference RFC2518?  If so, then implementors *can't*  

Of course.

> non-compliant with Bind and what it references.

I'm not sure I follow. In the IETF, this (updates of a base document) 
happens all the time and nobody seems to suggest that RFCs absolutely 
need to be updated just because a base document has progressed to a new 
standards level.

> and still claim compliance with RFC2518/2616.

Interesting. So why are we talking of RFC2616 all the time, when the 
spec that RFC2518 refers to is actually RFC2068???

> that support that spec in how they handle ETags and last-modified  

(see separate email 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/0144.html>).

>> 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  
>>> 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.
>>
>>

So how is it supposed to do that without risking to disagree with 
RFC2518bis?

>>> statements about implementations or about implications of 
>>> consistency  across bindings.
>>> General case
>>> those as being the same values across all bindings.  The 
>>> consequences  of this would be more
>>
>>

That sounds like you're trying to use BIND to enforce a specific server 
behaviour to everybody else. I disagree with that approach, although I 
may agree that it's good if a server behaves that way. To get there, 
it's IMHO better to (1) explain the issue and (2) potentially make it 
easier for clients to find out whether a server follows that model. Both 
would be action items for RFC2518bis.

>>> implementations, at the cost of some server implementations having 
>>> to  change a few things in order to become compliant with BIND.  
>>> 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 think it's inacceptable because it describes what may be desirable in 
some scenarios, but not reality.

Best regards, Julian