Subject: Re: [Bug 3] Bindings draft should specify if all properties MUST have same value on all bindings

From: Lisa Dusseault <[email-masked]>
Date: Mon, 6 Dec 2004 10:15:41 -0800

This bug/issue has been repeatedly closed "worksforme".  I do not agree 
that the issue is closed.  What is our model for whether a bug can be 
closed or not?

Lisa

On Dec 5, 2004, at 6:39 PM, [email-masked] wrote:

> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=3
>
>
>
>
>
> ------- Additional Comments From [email-masked]  2004-12-05 
> 18:39 -------
> Since RFC 2518 allows two URIs to map to the same resource, it is the
> responsibility of RFC-2518 to define the semantics of properties when 
> accessed
> from different URIs that map to the same resource.  The bindings draft 
> will
> inherit whatever semantics is defined for this by 2518.
>
> If there is ambiguity in semantics introduced by 2518, it should be 
> fixed in
> 2518bis, not in the bindings draft.  Having one spec define the 
> functionality
> of a feature defined by another spec is always a bad idea, since 
> unless the
> two specs are evolved in lock step (which never happens), there will be
> periods of times when the two specs say conflicting things about that 
> feature.
>
>
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Dec 2004 19:26:20 +0100

> that the issue is closed.  What is our model for whether a bug can be 

Well, it has also been re-opened, with which *I* don't agree. What does 
this tell us? BugZilla is just a tool for keeping track of issues, but 
it does not help defining rough consensus.

As stated before, a situation where a single voice continues to re-raise 
the same issue, but everybody else appears to agree that there is no 
problem, seems to be exactly the case where the term "rough consensus" 
applies.

See also 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/0025.html>.

Best regards, Julian

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

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 6 Dec 2004 10:55:42 -0800

I don't think everybody else agrees that there is no problem.  I have  
only heard a couple people directly address this issue.

The last time we discussed this (this fall but also way earlier), we  
did come to rough consensus that properties, even live properties, must  
have the same value no matter which binding is used to request the  
value of the property.  (I am not sure I agree with the conclusion, but  
I agree there was rough consensus.)

Now I'm saying that it's not clear in the spec that this is required  
and we should put it in the spec.  This is a different issue (what  
should be in the spec) than the previous issue ( what should be  
allowed) although clearly one follows from the other.   In the message  
you point to, Geoff and Jason and yourself addressed the "what should  
be allowed" issue.  Now let's discuss "what should be in the spec".

Lisa

On Dec 6, 2004, at 10:26 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> This bug/issue has been repeatedly closed "worksforme".  I do not  
>> agree that the issue is closed.  What is our model for whether a bug  
>> can be closed or not?
>
> Well, it has also been re-opened, with which *I* don't agree. What  
> does this tell us? BugZilla is just a tool for keeping track of  
> issues, but it does not help defining rough consensus.
>
> As stated before, a situation where a single voice continues to  
> re-raise the same issue, but everybody else appears to agree that  
> there is no problem, seems to be exactly the case where the term  
> "rough consensus" applies.
>
> See also

---

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

I think it would be good to include the following language in the bind
specification:

Note that, consistent with [RFC2518], the value of a dead property is
independent of the number of bindings to its host resource, and of the path
submitted to PROPFIND. Since live properties can be aribtrary computational
processes, they MAY vary depending on path or number of bindings, but SHOULD
NOT do this unless the definition of the live property explicitly includes
this dependency.

Here I avoided adding new requirements in areas already covered by 2518, but
did add requirements for the new situation raised by the BIND specification.

- Jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lisa Dusseault
> Sent: Monday, December 06, 2004 10:56 AM
> To: Julian Reschke
> Cc: Webdav WG
> Subject: Re: [Bug 3] Bindings draft should specify if all 
> properties MUST have same value on all bindings
> 
> 
> I don't think everybody else agrees that there is no problem. 
>  I have only heard a couple people directly address this issue.
> 
> The last time we discussed this (this fall but also way 
> earlier), we did come to rough consensus that properties, 
> even live properties, must have the same value no matter 
> which binding is used to request the value of the property.  
> (I am not sure I agree with the conclusion, but I agree there 
> was rough consensus.)
> 
> Now I'm saying that it's not clear in the spec that this is 
> required and we should put it in the spec.  This is a 
> different issue (what should be in the spec) than the 
> previous issue ( what should be  
> you point to, Geoff and Jason and yourself addressed the 
> "what should be allowed" issue.  Now let's discuss "what 
> should be in the spec".
> 
> Lisa
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Dec 2004 21:03:15 +0100

> only heard a couple people directly address this issue.

Well, I can only make statements about people who *do* say something 
about the topic. Those who did seemed to agree that the spec shouldn't 
say anything specific about this issue.

> be allowed" issue.  Now let's discuss "what should be in the spec".

I'm happy to discuss the issue "what should be in the spec". However, 
BIND does *not* introduce the concept of bindings. What it introduces is 
a new method for explicitly creating them (BIND), some BIND-optimized 
equivalents for MOVE and DELETE (REBIND and UNBIND), live properties and 
status codes that help in living with multiple bindings. But the basic 
concept of multiple URIs being mapped to the same URI is already present 
in RFC2518, thus if there is anything that needs to be clarified 
regarding the behaviour of properties, this needs to go into RFC2518 (as 
Jim already mentioned, the containment model described in the BIND spec 
really should be part of the base spec, not BIND).

So should I open an issue against RFC2518bis regarding this topic?

Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Dec 2004 21:09:39 +0100

> did add requirements for the new situation raised by the BIND specification.

I like that part that says that this is not a new requirement, but just 
a repeat of what RFC2518 already says.

On the other hand, I'm less convinced that the second part is a good 
idea. Having property values varying across bindings is IMHO an 
extremely bad idea, and so far I haven't seen a good use case for them. 
Saying that specs MAY define these kinds of properties sort of 
encourages them.

Anyway (and as mentioned in the reply to Lisa), this issue has nothing 
to do with BIND spec per se. Saying something in the BIND spec only 
makes sense if there is consensus to add equivalent language into 
RFC2518bis (and if this happens it's unclear why we need to add it to 
BIND in the first place).

Feedback appreciated.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 6 Dec 2004 12:19:24 -0800

> BIND does *not* introduce the concept of bindings. What it introduces 
> is a new method for explicitly creating them (BIND), some 
> BIND-optimized equivalents for MOVE and DELETE (REBIND and UNBIND), 
> live properties and status codes that help in living with multiple 
> bindings. But the basic concept of multiple URIs being mapped to the 
> same URI is already present in RFC2518, thus if there is anything that 
> needs to be clarified regarding the behaviour of properties, this 
> needs to go into RFC2518 (as Jim already mentioned, the containment 
> model described in the BIND spec really should be part of the base 
> spec, not BIND).
>

Only if RFC2518bis is going to include the whole bindings 
specification, or at least the resource-id property.  The reason why 
RFC2518 never needed to answer this question definitively is because  
clients had no way of knowing when two URLs point to the same resource. 
  If clients can't identify bindings, then there's no way to violate the 
client's expectations around property values of two bindings to the 
same resource.

With the bindings specification, the client can detect multiple 
bindings with 'resource-id', or for that matter the client may have 
used BIND.  So now that we have a spec describing how to identify and 
manipulate bindings, that spec needs to be clear on what the client 
must expect and/or what the server must do to meet expectations.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Dec 2004 21:55:09 +0100

Lisa Dusseault wrote:

> Only if RFC2518bis is going to include the whole bindings specification, 
> or at least the resource-id property.  The reason why RFC2518 never 
> needed to answer this question definitively is because  clients had no 
> way of knowing when two URLs point to the same resource.  If clients 
> can't identify bindings, then there's no way to violate the client's 
> expectations around property values of two bindings to the same resource.

If it doesn't matter, why does RFC2518 say:

"Although implicit in [RFC2068] and [RFC2396], any resource, including 
collection resources, MAY be identified by more than one URI. For 
example, a resource could be identified by multiple HTTP URLs."

(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.5.1.p.4>) and

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

(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3>)?

> With the bindings specification, the client can detect multiple bindings 
> with 'resource-id', or for that matter the client may have used BIND.  
> So now that we have a spec describing how to identify and manipulate 
> bindings, that spec needs to be clear on what the client must expect 
> and/or what the server must do to meet expectations.

I think it's safe to say that we'll continue to disagree on this. 
Multiple bindings to the same resource are part of RFC2518, even if it 
doesn't define the additional features in BIND 
(creation/discovery/diagnostics). So if there is anything unclear, it 
needs to be resolved in RFC2518bis as well. In which case the question 
arises why it would ever be a good idea to do it in two distinct places 
unless we can be absolutely certain that both say the same thing.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 6 Dec 2004 14:01:37 -0800

On Dec 6, 2004, at 12:55 PM, Julian Reschke wrote:

>> clients had no way of knowing when two URLs point to the same 
>> resource.  If clients can't identify bindings, then there's no way to 
>> violate the client's expectations around property values of two 
>> bindings to the same resource.
>
> resource MUST NOT succeed if can not be honored by all the URIs 
> through which the resource is addressable."
>

In this case it *does* matter to clients because it is detectable -- 
the behavior has concrete results, even if the client can't detect that 
there are multiple bindings.  If a client is trying to allow the user 
to edit a resource and therefore locks the resource, then the resource 
gets changed anyway, this would violate the client's expectation.  The 
client probably doesn't have a graceful way to recover from this kind 
of event even if the programmers are responsible in checking for it (by 
looking at the ETag).  Therefore, this language is necessary to ensure 
that the lock covers the real resource and that the lock behaves the 
way the client expects it to.

If we can come up with a use case where it's important for the client 
to rely on property values being the same for every binding to a 
resource, even without being able to tell that the resource has 
multiple bindings or what they are, then I will agree that RFC2518bis 
needs to cover that behavior as well.

Lisa

---

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

Lisa Dusseault wrote:
> In this case it *does* matter to clients because it is detectable -- the 
> behavior has concrete results, even if the client can't detect that 
> there are multiple bindings.  If a client is trying to allow the user to 

It's always detectable. For instance, if I submit a depth:0 LOCK request 
to "/a", and a subsequent PROPFIND on the DAV:lockdiscovery property of 
"/b" shows that it is locked by the same lock I just created on "/a", I 
can conclude that both are the same resource.

BIND makes it *easier* to detect sameness, but it doesn't introduce any 
new concept.

> ...

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 6 Dec 2004 15:25:13 -0800

On Dec 6, 2004, at 2:20 PM, Julian Reschke wrote:

>>> "Although implicit in [RFC2068] and [RFC2396], any resource,  
>>> including collection resources, MAY be identified by more than one  
>>> URI. For example, a resource could be identified by multiple HTTP  
>>> URLs."
>>>
>> the behavior has concrete results, even if the client can't detect  
>> that there are multiple bindings.  If a client is trying to allow the  
>> user to
>
> It's always detectable. For instance, if I submit a depth:0 LOCK  
> request to "/a", and a subsequent PROPFIND on the DAV:lockdiscovery  
> property of "/b" shows that it is locked by the same lock I just  
> created on "/a", I can conclude that both are the same resource.
>
> BIND makes it *easier* to detect sameness, but it doesn't introduce  
> any new concept.
>
Clever... so an observant client could detect that the same lock  
existed on two URLs so conclude they are bindings to the same resource  
(unless the server calculates the value for lockdiscovery on the fly  
and does something unlikely and weird with lock tokens).

I still think that the bindings draft makes it far more likely that a  
client will try to detect whether two bindings are the same resource  
and behave differently if they are.  For example, a client that is  
bindings-aware could try to speed up synchronization by using  
'DAV:resource-id' and synchronizing only once per resource, rather than  
once per binding.  The client could cache the 'DAV:acl' property (or  
any other live property) for offline use.  If the client knows that all  
bindings will have the same value for 'DAV:acl' then it only needs to  
request that property once per resource.  OTOH if the client knows that  
different bindings may have different values for 'DAV:acl' (or another  
live property) then the client must ask once for each binding.

I also worry that it's not enough for us to say that dead properties  
MUST be the same value no matter which binding is addressed but live  
properties MAY vary.  We don't have a reliable way for the client to  
tell which properties are dead and which are live.  Still, I could live  
with that.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Dec 2004 11:50:53 +0100

> and does something unlikely and weird with lock tokens).

If a server does something "unlikely and weird" that causes this not to 
work, then it's broken. There's no reason to believe that a server that 
get's DAV:lockdiscovery wrong will get DAV:resource-id right, so why 
would I worry about that?

> live property) then the client must ask once for each binding.

Which is exactly the reason why RFC3744 says that DAV:acl will be the 
same no matter what binding you use.

> tell which properties are dead and which are live.  Still, I could live  

Well, as you just pointed out, the difference between dead and live 
properties is fuzzy. Also, the statement as proposed, sort of 
*encourages* implementers to have live properties varying by binding. 
IMHO, they shouldn't (as properties are part of the state of the 
resource or computed based on the state of a resource), and thus should 
not vary at all. My impression from earlier discussion was that you 
don't buy that point of view, so I haven't tried hard to get it into the 
spec. Should I now?

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 7 Dec 2004 09:45:07 -0800

>> 'DAV:resource-id' and synchronizing only once per resource, rather 
>> than  once per binding.  The client could cache the 'DAV:acl' 
>> property (or  any other live property) for offline use.  If the 
>> client knows that all  bindings will have the same value for 
>> 'DAV:acl' then it only needs to  request that property once per 
>> resource.  OTOH if the client knows that  different bindings may have 
>> different values for 'DAV:acl' (or another  live property) then the 
>> client must ask once for each binding.
>

I took 'DAV:acl' as an example because it's one we're familiar with and 
we can see the consequences of error.  It's other live properties I'm 
worried about.
(BTW, where does RFC3744 say that?  I see lots of places where 
'DAV:acl' is defined with respect to a resource and the language is 
fairly precise about resources and URLs, so one might believe that this 
behavior is implicit, but I can't see where it says anything about 
bindings.)

>> tell which properties are dead and which are live.  Still, I could 
>> live  with that.
>
> resource or computed based on the state of a resource), and thus 
> should not vary at all. My impression from earlier discussion was that 
> you don't buy that point of view, so I haven't tried hard to get it 
> into the spec. Should I now?
>
Even if I disagree with the conclusion -- perhaps *particularly* 
because I disagree with the conclusion and others may also -- I feel 
strongly that the decision should be reflected as a requirement in the 
specification.

Lisa

---

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

Lisa Dusseault wrote:
> (BTW, where does RFC3744 say that?  I see lots of places where 'DAV:acl' 
> is defined with respect to a resource and the language is fairly precise 
> about resources and URLs, so one might believe that this behavior is 
> implicit, but I can't see where it says anything about bindings.)

It doesn't need to:

<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.5.p.2>

> Even if I disagree with the conclusion -- perhaps *particularly* because 
> I disagree with the conclusion and others may also -- I feel strongly 
> that the decision should be reflected as a requirement in the 
> specification.

However, that requires that there *is* a decision. As far as I can tell, 
there's currently no consensus for any specific statement.

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 7 Dec 2004 13:26:53 -0500

> > Even if I disagree with the conclusion -- perhaps *particularly* 
because 

> there's currently no consensus for any specific statement.

I agree (that there is no consensus ... I am undecided about this myself
since there are valid arguments to be made in either direction).

So in this case, since the core bind functionality does not depend on
having an answer to this question, we should leave the issue unspecified,
so that client do not false assume that this behavior is standarized.
When we have reached consensus on this point, we can add it to the next
revision of the appropriate specification (and at that time, can reopen
the debate on which is the appropriate specification :-).

Cheers,
Geoff

---

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

Seems to me we already have an example of a live property that varies
depending on the binding used to access it -- DAV:displayname. On servers
where this just reflects the binding name of the resource, it seems like it
would vary depending on the binding used to access it.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Dec 2004 14:57:55 +0100

> would vary depending on the binding used to access it.

This is a known issue with servers that indeed implement DAV:displayname 
that way; for instance discussed in 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#bind_properties>.

My position is, that a server that implements DAV:displayname as 
computed property based on the binding name is simply poorly 
implemented; DAV:displayname is defined to be "...a description of the 
resource that is suitable for presentation to a user" 
(<http://greenbytes.de/tech/webdav/rfc2518.html#PROPERTY_displayname>), 
not a repetition of the last path segment.

Apache/moddav and many other serves get this right; and I expect the 
same will apply to any server that actually supports multiple bindings.

Best regards, Julian

---

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

It seems to me that a live property inherently has the quality that its
output can depend on an arbitrary computational process, which can make use
of any aspect of the server's state it has access to. This includes
bindings.

While it is reasonable for servers to make use of this capability sparingly,
it's also reasonable for them to have live properties that depend on binding
state if it supports a particular application.

Julian writes:
> Also, the statement as proposed, sort of
> *encourages* implementers to have live properties 
> varying by binding.  IMHO, they shouldn't (as 
> properties are part of the state of the resource 
> or computed based on the state of a resource), and 
> thus should not vary at all.

There's nothing in 2518 that implies a live property's computation depends
only on the state of the resource. It would be prefectly valid to have a
live property that returned a random number.

I'm not too worried about encouraging binding-specific properties, as I
believe implementors would be able to see the potential usability drawbacks
of such properties.

- Jim

---

From: Brian Korver <[email-masked]>
Date: Thu, 9 Dec 2004 17:04:39 -0800

I strongly agree that text like this -- text that explains the rough
consensus on how properties interact with bindings -- should appear
in the bind spec (ignoring whether or not this exact text represents
the rough consensus).

-brian
[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Thu, 9 Dec 2004 17:09:12 -0800

Julian,

Ok, we know your vote for how live properties interact with bindings
(as if we didn't know already ;-), but I think that in combination
with Jim's point underscores the need for explicit text in the bind
spec.

-brian
[email-masked]

On Dec 8, 2004, at 5:57 AM, Julian Reschke wrote:
> This is a known issue with servers that indeed implement  
> DAV:displayname that way; for instance discussed in  
> (<http://greenbytes.de/tech/webdav/ 
> rfc2518.html#PROPERTY_displayname>), not a repetition of the last path  
> segment.
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Dec 2004 09:41:35 +0100

> in the bind spec (ignoring whether or not this exact text represents

Well, the main issue is that we don't have "rough consensus" yet (and 
when we have, that should be added as to-do for RFC2518bis).

Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Dec 2004 19:28:58 +0100

> live property that returned a random number.

<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.4.1>:

"Properties are pieces of data that describe the state of a resource. 
Properties are data about data."

Also note that aforementioned live property wouldn't *vary* by binding; 
it would just be random. What I'm looking for is a use-case where 
properties varying by *binding* really make sense. So far, I'm not aware 
of any case where this wouldn't be better modelled as a property on the 
collection holding the binding.

> believe implementors would be able to see the potential usability drawbacks

I tend to disagree here (judging from previous reactions) :-)

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 10 Dec 2004 11:45:29 -0800

What about a live property called "nextPhoto" on a WebDAV collection of 
photos?  Then it's trivial to do a "slideshow" for that collection, 
going from one photo to the next.  You can support one photo that 
appears in multiple slideshows through bindings, and the value for 
"nextPhoto" depends on which slide show the client is looking at, which 
is clearly detectable from the URL.

This kind of thing could be useful for other applications as well.  It 
could even work with PROPPATCH, because the server knows to treat this 
as a "per-binding" property and change only the value that applies for 
this binding.

I can even imagine a generic way of the client telling the server to 
"create me this new dead property as a per-binding property" so that 
the client can provide a new value per binding.

Lisa

On Dec 10, 2004, at 10:28 AM, Julian Reschke wrote:

> Also note that aforementioned live property wouldn't *vary* by 
> binding; it would just be random. What I'm looking for is a use-case 
> where properties varying by *binding* really make sense. So far, I'm 
> not aware of any case where this wouldn't be better modelled as a 
> property on the collection holding the binding.
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Dec 2004 21:05:50 +0100

> is clearly detectable from the URL.

Either use Ordered Collections (RFC3648), add a multi-valued property on 
the collection container, or expose the information as pair 
(parent-collection, next-binding) on the resource.

> as a "per-binding" property and change only the value that applies for 

So where do you store it? Either on the resource itself (in which case 
you need to maintain that property for each parent collection, so you 
could simply expose that information as well), or on the collection.

> "create me this new dead property as a per-binding property" so that the 
> client can provide a new value per binding.

I can imagine a lot of things as well. The question is: do we really 
need that and how does fit into the model that we're using for WebDAV?

BTW: you seem to be changing positions frequently :-) May I remind you 
that you asked that the BIND spec mandates that properties MUST NOT vary 
across bindings?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Dec 2004 21:09:25 +0100

> client can provide a new value per binding.

Forgot to mention...: what you describe here (to me) clearly is a case 
of where the information you want to expose is part of the state of the 
slide show, not of an individual picture. So it seems to be quite 
obvious to model the slide show as WebDAV collection, and to maintain 
ordering and other defaults (display time, effects, whatever) as state 
of that collection.

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 10 Dec 2004 12:38:25 -0800

>
>> This kind of thing could be useful for other applications as well.  
>> It could even work with PROPPATCH, because the server knows to treat 
>> this as a "per-binding" property and change only the value that 
>> applies for this binding.
>

WebDAV servers *store* things any way they like.  E.g. a new table in 
the backend database called "PER_BINDING_PROPS" with column headers for 
binding, property name and value. Who cares how they store it -- that's 
what gives the implementors flexibility.  WebDAV's model and 
marshalling are what we're talking about.

> that you asked that the BIND spec mandates that properties MUST NOT 
> vary across bindings?
>
As it happens, I am not changing positions on this issue (although I 
reserve my right to change my mind if I'm convinced by an argument or 
think of new cases).  I have held this position for a year or more now 
and will try to state it again another way:

That servers should be allowed to vary properties per binding and IF 
that's the consensus...
     then the specification should warn clients that "clients MUST be 
prepared for properties that vary per binding"
ELSE IF the consensus (despite my opinion) is that properties can't 
vary per binding
     then the specification should say that properties MUST NOT vary 
across bindings.

Lisa

---

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

Lisa Dusseault wrote:
> what gives the implementors flexibility.  WebDAV's model and marshalling 
> are what we're talking about.

Yes, and WebDAV's (that is, HTTP's) model involves resources and URIs. 
URIs are used to address resources, and content and properties represent 
the state of the *resource*, no the URI.

If you want things to vary based on the binding, store them with the 
binding, and in WebDAV's model, that's part of the state of the parent 
collection. It's ok to do this, but if you do things will stay much 
simpler if you work with that model.

For instance, is PROPPATCHing "the next picture" modifying the state of 
the picture, or that of the slide show? If it's part of the picture, 
I'll need write permissions to the picture resource, right? Why would I 
need that if the only thing I do is changing the ordering in a container 
object (the slide show)?

> ELSE IF the consensus (despite my opinion) is that properties can't vary 
> per binding

As far as I can tell, there is no consensus for either of these. RFC2518 
says that properties "describe the state of a resource". People seem to 
come to different conclusions about what this means, but if this is the 
case, it should be fixed in RFC2518, not in BIND.

Best regards, Julian

---

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

Let me suggest the following language. I think we all agree this is a
minimum level statement on the issue -- where we differ is in how to go
beyond this level (Julian wants to change the SHOULD to a MUST , while I'd
like to add an additional MAY).

Proposed language:

Note that, consistent with [RFC2518], the value of a dead property is 
independent of the number of bindings to its host resource or of the 
path submitted to PROPFIND. Similarly consistent with [RFC2518], the
value of a live property SHOULD be independent of the number of
bindings to its host resource, and of the path submitted to PROPFIND.

The reason for the two almost-identical sentences is to address Julian's
desire to not include spec. language that's obvious from a careful reading
of 2518. I personally prefer the following, more compact construction:

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

- Jim

---

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

> its host resource or of the path submitted to PROPFIND.

I personally would prefer to stay silent about the topic, but if 
everybody else is agreeing, I'll be happy to add one of these 
(preferrably the latter, shorter one).

Feedback appreciated,

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 14 Dec 2004 00:13:09 -0500

I also would prefer to remain silent, but I can live with this text
(I prefer the shorter version).

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Dec 2004 15:43:33 +0100

> (I prefer the shorter version).

OK, *where* should thie statement go...?

Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 14 Dec 2004 09:38:09 -0800

> OK, *where* should thie statement go...?

My recommendation is a new section, titled, "PROPFIND and Bindings", placed
either immediately before or after section 2.6.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Tue, 14 Dec 2004 19:15:34 +0100

> either immediately before or after section 2.6.

OK, done in... 
<http://www.webdav.org/bind/draft-ietf-webdav-bind-latest.html#rfc.issue.2.6_bindings_vs_properties>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 18 Dec 2004 20:34:40 +0100

> <http://www.webdav.org/bind/draft-ietf-webdav-bind-latest.html#rfc.issue.2.6_bindings_vs_properties>. 

I haven't heard back from anybody, thus I'll assume that I can close the 
issue.

Joe, Lisa; as far as I can tell all we're done except for

	<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=2>

where feedback to my latest entry would be appreciated.

Other than that, I think we can either last-call draft -09 or submit the 
current draft as -10 and last-call that. It would be extremely good if 
we could do that early next week (with a four week last-call period), so 
that people interested have something to read over the holidays.

Please provide feedback about how to proceed as soon as possible.

Best regards, Julian