Subject: WG Last call for BIND

From: Joe Hildebrand <[email-masked]>
Date: Tue, 11 Jan 2005 17:42:26 -0700

This e-mail serves as the Working Group Last Call for BIND:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-10.txt

Here is the process we are going to use:
- Issues entered into the issue tracker: 
http://ietf.webdav.org:8080/bugzilla/
- Discuss issues on the list by replying to the issue e-mail
- If you believe you have the resolution of the issue, attach it as a 
comment on the tracker
- If you agree with the issue, vote for it on the tracker
- The issue opener may close the issue, if the vote count is still 0
- If the vote count is >0, only a working group chair or person 
designated by the chair may close the issue
- Issues will be closed when consensus is achieved on the issue being 
resolved
- Once an issue is closed according to this process, it may not be 
reopened
- If you still have outstanding issues that were closed, that you 
believe are still an issue, reopen the issue, and we will use these 
rules to close them
- Issues that have 0 votes at the end of last call will be closed 
automatically

The vote count is not a 'majority wins' sort of vote, but hopefully 
will allow some of those who want to register concern to be able to do 
so in a relatively low-effort way.

Last call will go on for three weeks, ending at 12 noon GMT February 2, 
2005.

-- 
Joe Hildebrand
Denver, CO, USA

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Jan 2005 02:02:38 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-10.txt

Thanks.

> - If you agree with the issue, vote for it on the tracker

If I disagree, then....?

> - Issues will be closed when consensus is achieved on the issue being 

Shouldn't that be "rough consensus"? As far as I can tell, I expect that 
there'll be issues for which we definitively won't reach consensus, 
judging from past discussions.

> - Once an issue is closed according to this process, it may not be reopened

Nit: that seems to say that an issue may not be re-opened unless 
somebody feels it needs to :-)

> - Issues that have 0 votes at the end of last call will be closed 

Are votes from the issue opener counted?

> The vote count is not a 'majority wins' sort of vote, but hopefully will 
> allow some of those who want to register concern to be able to do so in 
> a relatively low-effort way.

As there doesn't seem to be a way to vote against an issue, this doesn't 
seem to work.

> Last call will go on for three weeks, ending at 12 noon GMT February 2, 

Best regards, Julian

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 11 Jan 2005 23:30:34 -0500

I share Julian's concern that the lack of a "vote against" feature makes 
the bugzilla voting mechanism not very useful/appropriate for 
specifications issues.  The policy of limiting the number of votes 
(currently set to just 1) further limits the utility of this mechanism 
(and encourages bundling all of ones issues into a single "report" so that 
you can vote for all of them without spending multiple votes).

I also share his puzzlement over the "you can't reopen an issue unless you 
want to" rule (:-).

A key point is how one determines rough consensus (since the voting 
mechanism doesn't help with that).  Any thoughts on how that would be 
determined?

Cheers,
Geoff

reopened
> > The vote count is not a 'majority wins' sort of vote, but hopefully 
will

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 11 Jan 2005 23:21:02 -0700

>> - If you agree with the issue, vote for it on the tracker

You voice your disagreement on the list.  It's not an actual vote, it's 
a way to find out if certain issues are just outliers.  My 
understanding of some of the disagreements that have happened in the 
past is that people have had issues, other people have agreed with them 
but not said anything.  I'd say that by definition, an issue that only 
has a single supporter shouldn't hinder rough consensus.  This is 
actually an attempt to weed out those issues more easily.

> Shouldn't that be "rough consensus"? As far as I can tell, I expect 
> that there'll be issues for which we definitively won't reach 
> consensus, judging from past discussions.

Sorry, I was slightly unclear.  "consensus is achieved" should have 
read something like "when the chairs decide that rough consensus has 
been reached".

> somebody feels it needs to :-)

We didn't have process for closing issues until now.  Some of them may 
have been closed without the opener feeling their issue got full 
treatment.  My intent was that only issues that have been closed prior 
to this last call could be re-opened.

> Are votes from the issue opener counted?

As the 0th vote.  :)

>> will allow some of those who want to register concern to be able to 
>> do so in a relatively low-effort way.
>
> As there doesn't seem to be a way to vote against an issue, this 
> doesn't seem to work.

The word "vote" is perhaps confusing.  It's just a way of registering 
the fact that an issue is important to more than one person.

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 11 Jan 2005 23:37:13 -0700

> I share Julian's concern that the lack of a "vote against" feature 
> makes the bugzilla voting mechanism not very useful/appropriate for 
> (and encourages bundling all of ones issues into a single "report" so 
> that you can vote for all of them without spending multiple votes).

Sorry about that.  I've set the max votes to 100.

> I also share his puzzlement over the "you can't reopen an issue unless 
> you want to" rule (:-).

Hopefully I clarified that in my response to him.

> mechanism doesn't help with that).  Any thoughts on how that would be 

Chair omniscience.  :)

Seriously, if there are multiple camps that can't come together, we'll 
have to keep working.

I'll suggest again that those who want these drafts to continue to make 
forward progress would benefit from coming to an IETF meeting and doing 
some good old-fashioned politics.  Meet people.  Make friends.  Explain 
your point of view.  Relationships, trust, and respect can drive a 
group towards consensus.

http://ietf.org/meetings/IETF-62.html

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Jan 2005 09:42:19 +0100

Joe Hildebrand wrote:
 > ...
> your point of view.  Relationships, trust, and respect can drive a group 
> towards consensus.
> ...

I find this comment puzzling. BIND has passed already one WG last call a 
few years ago, has been on the WG's agenda almost since day one (as part 
of "advanced collections"), and has been the top priority in the WebDAV 
WG's charter for quite some time. Does it really need additional 
political lobbying at this point?

After all, there is no requirement whatsoever that WGs indeed meet at 
each IETF (or at all, for that matter). If the WG chairs want to promote 
a meeting, it would be helpful if there'd be some more advance planning 
than in the past, so that people would have some idea about what the 
goals are (just re-stating the status quo isn't that helpful).

As far as I can tell, the current contents of BIND indeed represents 
rough consensus (in the semantics the WG wanted to achieve) *and* 
running code (interoperable code being *deployed*, not only in 
development), so it's really really time that it get's out of ID state 
(even if this means publishing as "Experimental" if that is needed to 
overcome the opposition of a few who, for reasons unclear to me, seem to 
prefer blocking the progress).

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 12 Jan 2005 07:36:25 -0500

I'm happy with all of Joe's answers, so I'm +1 for the process
(in the spirit of getting rough consensus on the process for
determining rough consensus :-).

BTW, I encourage folks to review the outstanding issues against
2518bis, and vote for the ones you care about.

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 12 Jan 2005 07:45:10 -0500

I believe Joe was just responding to my question about the general
process of achieving rough consensus, and not speaking primarily about
the BIND specification.   In particular, during the design phase of
a new specification, face-to-face communication is often required to
iron out different points of view.  During the "review" phase, I've 
found that email is often sufficient (and often preferable, because
it widens the discussion to a larger group, since often it is only the
"designers" whose companies are willing to fund travel).

Cheers,
Geoff

> > your point of view.  Relationships, trust, and respect can drive a 
group

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 12 Jan 2005 07:33:38 -0700

This is a good example of how, if you knew me a little better, our 
communication could be improved.  This was off the topic of BIND in 
specific, on to how to achieve consensus in general.

BIND should be fine.  2518bis may yet need some discussion, as may 
other topics.

-- 
Joe Hildebrand
Denver, CO, USA

On Jan 12, 2005, at 1:42 AM, Julian Reschke wrote:

>
> Joe Hildebrand wrote:
> > ...
>> I'll suggest again that those who want these drafts to continue to 
>> make forward progress would benefit from coming to an IETF meeting 
>> and doing some good old-fashioned politics.  Meet people.  Make 
>> friends.  Explain your point of view.  Relationships, trust, and 
>> respect can drive a group towards consensus.
>> ...
>
> I find this comment puzzling. BIND has passed already one WG last call 
> a few years ago, has been on the WG's agenda almost since day one (as 
> part of "advanced collections"), and has been the top priority in the 
> WebDAV WG's charter for quite some time. Does it really need 
> additional political lobbying at this point?
>
> each IETF (or at all, for that matter). If the WG chairs want to 
> promote a meeting, it would be helpful if there'd be some more advance 
> planning than in the past, so that people would have some idea about 
> what the goals are (just re-stating the status quo isn't that 
> helpful).
>
> overcome the opposition of a few who, for reasons unclear to me, seem 
> to prefer blocking the progress).
>
> Best regards, Julian
>
> --

---

From: Brian Korver <[email-masked]>
Date: Tue, 18 Jan 2005 16:30:30 -0800

The BIND spec doesn't mention ETags at all, but buried in section
3.11 of RFC 2616 is the following text:

    An entity tag MUST be unique across all versions of all entities
    associated with a particular resource. A given entity tag value MAY
    be used for entities obtained by requests on different URIs. The use
    of the same entity tag value in conjunction with entities obtained by
    requests on different URIs does not imply the equivalence of those
    entities.

which (at least to me) seems counter-intuitive in the face of multiple
bindings -- I would have guessed that the ETag would remain constant.
Any chance we could squeeze some text into the draft, similar to that
dealing with locking?  Something approximately like:

   Entity Tags and Bindings

   It might be thought that ETags would be associated with resources,
   not URIs, and as such two different URIs with identical ETags
   would imply that the URIs are bindings to the same resource.
   This is not the case, however.  Section 3.11 of [RFC2616]
   states that ETags are on URIs, not resources.

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2005 01:52:39 +0100

> bindings -- I would have guessed that the ETag would remain constant.

I think all this says is that if you get the same Etag for "/a" and 
"/b", you can't assume that it's the same entity.

>   states that ETags are on URIs, not resources.

I agree with the conclusion, but I think the motivation for saying this 
is a bit weak. Could you please re-read 3.11 and consider my explanation 
  above?

That being said here's something for RFC2518bis to clarify: RFC2616's 
definition of ETag semantics doesn't work well with namespace 
operations. In practice, within the same URL namespace ETags will only 
work well when they are indeed unique not only for all versions for a 
single URI, but for the whole namespace (otherwise a server will have to 
do post-processing after MOVE operations to ensure that ETag semantics 
are preserved, possibly assigning new ETags just because a namespace 
operation occured).

Best regards, Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 18 Jan 2005 17:08:00 -0800

>   A given entity tag value MAY be used for entities obtained 
>   by requests on different URIs. The use of the same entity 
>   tag value in conjunction with entities obtained by

My recollection is that a server might decide to implement Etags as a simple
integer that is updated on every state modification. In this case, all of
the resources on a server would start out with the same Etag value of "1".
In this case, the fact of all Etags being "1" certainly doesn't imply that
all URIs are mapped to the same resource. The fact that all Etags have the
value "1" is still consistence with Etags being defined on resources.

>    states that ETags are on URIs, not resources.

So, if we were to put in language, I'd add something like:

Implementors note: Etag values are only required to be unique across all
  versions of a particular resource, not unique across all versions and
  all resources. As a result, two separate resources may have the same
  Etag value, and hence Etag values cannot reliably be used to establish
  the identity of a resource accessible via multiple URIs.

- Jim

PS - How is the quota specification coming along?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2005 02:14:25 +0100

> value "1" is still consistence with Etags being defined on resources.

Correct. For instance, subversion could use it's global version counter 
as Etag.

>   the identity of a resource accessible via multiple URIs.

That's correct, but I really have a hard time understanding why anybody 
would *think* that ETags can be used that way. If they could, we 
wouldn't need DAV:resource-id...

Best regards, Julian

---

From: Brian Korver <[email-masked]>
Date: Tue, 18 Jan 2005 17:17:59 -0800

> "/b", you can't assume that it's the same entity.

Right, that's what I believe it says too, but I think that may be
counter-intuitive for some implementers -- who may in fact miss
this text in 3.11 and to implement expecting that they can assume
it's the same entity.

> I agree with the conclusion, but I think the motivation for saying 
> this is a bit weak. Could you please re-read 3.11 and consider my 
> explanation  above?
>
> single URI, but for the whole namespace (otherwise a server will have 
> to do post-processing after MOVE operations to ensure that ETag 
> semantics are preserved, possibly assigning new ETags just because a 
> namespace operation occured).
>
> Best regards, Julian
>
> -- 
-brian
[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Tue, 18 Jan 2005 17:19:48 -0800

On Jan 18, 2005, at 5:08 PM, Jim Whitehead wrote:
[snip]
> PS - How is the quota specification coming along?

I'm working on it right now and plan to have it out in the
next few days.

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2005 02:29:57 +0100

> this text in 3.11 and to implement expecting that they can assume

I'm not sure why implementers who are going to miss a specific section 
in RFC2616 aren't going to miss other important sections in RFC2616, 
RFC2518 or BIND as well -- so I don't buy that as reason to repeat 
something that another spec (normatively referenced) already says.

Have you actually *seen* implementers make that mistake? In which case a 
request for clarification should be added to the RFC2616 errata list.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 18 Jan 2005 17:32:07 -0800

> this text in 3.11 and to implement expecting that they can assume

I suggest we give them a sharp object and let evolution take its course.

There is nothing in either specification that would lead to such an
assumption and no evidence that implementers have made it (at least
none that survived in the wild).

....Roy

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 18 Jan 2005 18:27:34 -0800

When I first considered ETags and bindings, I assumed that all bindings 
to the same resource MUST show the same ETag.  That came from my 
understanding of what the ETag is used for, which is shaped by the 
implementations I've been involved in and what they do (authoring, 
sharing).  Note that I'm not making the naive assumption that an ETag 
can be used to identify two bindings -- but I did make the assumption 
that a single ETag can be recorded in order to synchronize a set of 
bindings to a single resource.

Then I saw Brian's email, where he put forward an excellent argument 
for why every binding MUST show its own unique ETag.  I can entirely 
understand a server implementor reading these specs and making that 
decision.

So if I wrote a synchronizing client (which I am), and Brian wrote an 
authoring server (which he does), if we were guided only by the specs 
and our interpretations, we would probably have interoperability 
problems.  My client would probably be confused by synchronizing two 
URLs which it knew to be bindings to the same resource but which 
reported different ETags.

Thus, I support adding text to bindings, either limiting the ways that 
servers can implement ETags and bindings, or explaining to clients the 
wide range of possible implementations they might have to deal with.

Lisa

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 18 Jan 2005 23:15:32 -0500

I think the heart of this issue is that the binding
specification states that live properties SHOULD have the
same value no matter what binding is used to access it.
This would imply that the getetag property SHOULD have the
same value no matter what binding is used to it.

If we agree that a resource should have the same getetag
property, no matter what binding is used to access it, then
the specification is correct as currently written, but 
I'm OK with making that statement explicitly in the spec,
since that is an etag constraint that is not stated in 2616, and
so there probably are etag implementations that do not satisfy
that constraint and that therefore should not be used with
a binding implementation.

Conversely, if we agree that a resource may have different
getetag property values when it is accessed from different 
bindings, then we should modify section 2.6 to say "unless explicitly
stated in the definition of the live property", and then
state that getetag is a property whose value can differ when
accessed from different bindings.

Cheers,
Geoff

p.s. I did get a bit of a chuckle over the 
characterization of the statement about etags 
being "buried" in section 3.11 of RFC-2616, since the
the title of section 3.11 is "Entity Tags", and that
section is only 3 paragraphs long.
Come on Roy, how did you expect folks to find that kind
of stuff if you're going to hide it away like that (:-).

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Jan 2005 09:18:38 +0100

> can be used to identify two bindings -- but I did make the assumption 

ETags do not identify resources or bindings. ETags can be used *with* 
URIs (as pair (URI, etag)) to identify one specific entity body you may 
get when applying GET to that URI.

> bindings to a single resource.

If this would be the case, we wouldn't need DAV:resource-id. In 
particular, how would that work with changing content (= changing etags?).

> Then I saw Brian's email, where he put forward an excellent argument for 
> why every binding MUST show its own unique ETag.  I can entirely 

I haven't seen that argument. Please quote, link to or explain again.

> understand a server implementor reading these specs and making that 

Well, I can't, but I'm interested. Where is that argument?

> reported different ETags.

Well, that's an entirely different issue compared to: "Then I saw 
Brian's email, where he put forward an excellent argument for why every 
binding MUST show its own unique ETag."

There are good reasons why Etags for the same entity body accessed 
through different URIs *should* be the same, and draft 10 already says 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-10.html#rfc.issue.2.6_bindings_vs_properties>) 
that the value of a live property -- and this includes DAV:getetag -- 
SHOULD be the same. I'm not sure we can go any further than that, 
because Entity Tags are defined by RFC2616, not us. Maybe Roy can give 
some guidance here.

> wide range of possible implementations they might have to deal with.

That being said I do agree with the other comments Geoff made in 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0060.html> 
-- I'm just not convinced that BIND needs to decide either way at this 
stage of the standards process. Sometimes, when something is initially 
submitted, being silent on a particular thing can be the right thing to 
do. In particular, this seems to be an issue that actually affects 
RFC2616 itself and possibly should be clarified there.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 19 Jan 2005 07:13:55 -0500

I agree with Julian.  This is an existing RFC-2616 issue,
not an issue introduced by the BIND specification, since:
- RFC-2616 explicitly states that two URIs can be mapped to the same 
resource
- RFC-2616 is where entity tags are defined
Therefore whether or not two URIs that are mapped to the same resource
have the same entity tag is an existing RFC-2616 issue.

If there is current consensus on this question, then I'm OK with
adding a sentence to the bind specification about it.  But if there is
not consensus (and I suspect there is not), then I believe it makes
no sense to hold up the BIND specification because of an issue with the
etag specification in RFC-2616.

Cheers,
Geoff 

Julian wrote on 01/19/2005 03:18:38 AM:

[WRT whether or not the etag SHOULD/MUST be the same at different

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 19 Jan 2005 09:16:16 -0800

The need for extra specification is introduced in binding, because the  
bindings draft provides a way to identify whether two bindings map to  
the same resource.  That functionality could lead a client to take  
either valuable short-cuts or harmful short-cuts when caching ETags to  
synchronize resources.

Lisa

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 19 Jan 2005 09:16:33 -0800

DAV:getetag appears to justify allowing live property values to vary with
URI and/or binding used to access them, since it really describes the
on-the-wire entity, and 2518 defines it as the Etag returned by a GET
without accept headers.

- Jim

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 19 Jan 2005 14:08:47 -0800

On Jan 18, 2005, at 6:27 PM, Lisa Dusseault wrote:
> When I first considered ETags and bindings, I assumed that all 
> bindings to the same resource MUST show the same ETag.

Well, that assumption was in error.  Errors happen and no amount
of specification can prevent them.  In particular, specifying the
internal implementation of ETag just to prevent people from making
erroneous assumptions about the interface is contrary to the design
of HTTP. One person's need for etags will differ from the needs
of others.

In Apache httpd, for example, the contents of default etags are
configurable.  Some people will want the inode and last-mod,
other people cannot include the inode due to use of clusters,
while still others will use an MD5 hash of a pre-generated
response message because their content is backed by a CMS.
There is no way for the standard to guess all of the possible
implementations of etags.

There are two sections to consider in the bindings draft:

   2.6  PROPFIND and Bindings

    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.

which I consider to be in error because live properties are owned
by the server -- any requirement that they be consistent across
bindings is wrong.

and

   2.7  Determining Whether Two Bindings Are to the Same Resource

which tells the implementer the right way to test for equivalence.

> problems.

No, you would have errors.  There is a difference between making a
standard that enables interoperability and forcing implementations
to use it correctly.

> wide range of possible implementations they might have to deal with.

Why do you insist on violating the basic design principles
of an interface?  HTTP is supposed to support loose coupling
of software systems, which means the standards cannot specify
anything like what you describe above.  The specification is
not the place to put tutorials on server design or lecture notes
on potential implementations -- people can write books about that.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Jan 2005 00:10:01 +0100

> by the server -- any requirement that they be consistent across

I'm tempted to say "I told you so" (not to you, Roy :-). Although it 
would be certainly nice to be able to rely on that, we don't seem to 
able to mandate that.

> on potential implementations -- people can write books about that.

And they actually do that :-)

I'm also a bit concerned by attempts to turn WebDAV into something like 
NFS-over-HTTP. It can be used like that, but it's only *one* usage of 
it. Attempting to optimize WebDAV for that particular case (for 
instance, by adding new ETag requirements that in practice many servers 
will not be able to implement), IMHO is a bad idea, and I will continue 
to object to changes like that.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 19 Jan 2005 18:15:07 -0500

I heartily agree with everything Roy says here.

Roy: WRT your concern about the statement about live properties,
would it be OK instead to say:

     Consistent with [RFC2518] the value of a dead property of a
     given resource MUST be independent of path to that resource
     submitted to PROPFIND.  The value of a live property SHOULD
     be independent of the path submitted to PROPFIND, unless
     the definition of the property explicitly states otherwise.

In other words, we are requiring live property definers to include
in the live property definition the behavior of that property in
the context of a resource being identified by multiple URLs.

Or would you prefer that the spec just say nothing about the behavior
of live properties?

Cheers,
Geoff

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 19 Jan 2005 15:38:28 -0800

>      the definition of the property explicitly states otherwise.

I don't like meaningless SHOULDs.  How is an implementation supposed
to test compliance with such a requirement?  I would prefer that the
specification say nothing about the value of a live property,
since live properties are (by definition) not controlled by the
client and thus not subject to interoperability constraints aside
from whatever may be in their definition.  The only thing that can
be legitimately said is that

   "The value of a live property MUST comply with the definition
    of that property."

which is, of course, a completely vacuous statement and not
subject to the bindings specification.

....Roy

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 19 Jan 2005 18:38:28 -0500

A client cannot take such short-cuts unless the etag specification
states they can take those short cuts.  There is nothing in the etag
specification that allows them to make that assumption, and therefore
as Greg has pointed out, it is just an implementation error if they
base their implementation on something other than the specification.

Perhaps we should also state that the last segment of the etag does
not have to match the current modification date, to make sure they do
not optimize their implementation by making that assumption?  (:-)

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 19 Jan 2005 18:42:41 -0500

I agree with Roy's rationale and conclusion, and support the
removal of the reference to live properties in section 2.6.

Cheers,
Geoff

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 19 Jan 2005 15:56:23 -0800

With all due respect to the engineer from Day spending a couple of enjoyable
hours procrastinating on the DAV list today, I disagree.

I pressed for this language because:

- a statement about dead properties in this situation without a similar
statement about live properties begs the question of how live properties
should behave,
- not making a statement about live properties here is ambiguous, and could
reasonably be interpreted in multiple contradictory ways (silence = intended
assent, silence = intended prohibition), and leads to implementors trying to
read spec writers' minds,
- the additional language makes it clear that servers have this additional
design freedom, if they so desire.

The comment about testability is a red herring here, since the requirement
is at the design level. Given a specific live property, it is certainly
possible to test whether it has a different value for different bindings.

I'll point to the long discussions we've had on this issue as evidence that
lack of specification language on this issue does not lead to experienced
engineers drawing the same conclusion about the behavior of live properties
across multiple bindings.

> I don't like meaningless SHOULDs.  How is an implementation 
> supposed to test compliance with such a requirement?  I would 
> prefer that the specification say nothing about the value of 
> a live property, since live properties are (by definition) 
> not controlled by the client and thus not subject to 
> interoperability constraints aside from whatever may be in 
> their definition. 

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Jan 2005 01:24:54 +0100

> removal of the reference to live properties in section 2.6.

Just checking...:

for a server that does support both RFC3253 and BIND, the value of a 
WebDAV property MUST NOT vary across bindings unless it's reported as a 
live property through DAV:supported-live-property-set?

(That's something we all should be able to agree upon)

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 19 Jan 2005 17:07:10 -0800

> statement about live properties begs the question of how live 

So what?  Let the reader beg the question. In a specification, lack
of a requirement means there is no requirement.

> reasonably be interpreted in multiple contradictory ways
> (silence = intended assent, silence = intended prohibition),
> and leads to implementors trying to

How is it ambiguous?  Intentions here are irrelevant.

> design freedom, if they so desire.

No, the additional language was just plain wrong.  It introduced a
bug in the protocol due to overzealous specification of things outside
the control of this particular document.  That is why we try to
avoid adding such cruft to specifications in the first place.

> possible to test whether it has a different value for different 

The original text said that live properties SHOULD be the same,
which was a false requirement.  The replacement that Geoff
briefly mentioned was that they SHOULD be the same unless they
were defined not to be the same.  That text would be vacuous.
It cannot be tested because a client cannot know whether changes
(or lack of changes) in the live property value are due to the
bindings, the definition, or some other activity going on behind
the server interface. The only reasonable test, therefore, is that
the property remains true to its definition regardless of whatever
actions have taken place, which is a test of the property definition
and NOT a test of the bindings specification.

In other words, given any live property, whether or not it has a
different value after the binding change is of no use nor concern
of the client.

> across multiple bindings.

And I'll point to the same discussions as evidence that if the chairs
were not so persistently obstinate in ignoring actual working group
consensus on the issues then maybe they could make reasonable
progress on drafts that should have been completed four years ago.
This issue, like many others, is whether it is ever appropriate for
experienced engineers to draw conclusions about the implementation
behind an interface, as opposed to simply reading the specification,
concluding that it defines the interface, and not assuming anything
about what happens beyond what is required of that interface.

You can find the answer to that question in any basic text on
Software Engineering -- it does not need my opinion to justify it.

....Roy

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 19 Jan 2005 21:10:11 -0500

I certainly agree with that.

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 19 Jan 2005 21:44:17 -0500

I enthusiastically concur with everything Roy has stated in this message.

Answering a question about whether something is true is done by
quoting the normative section in the specification that states it is true.
Answering a question about whether something is forbidden is done by
quoting the normative section in the specification that states it is 
forbidden.

If it isn't stated in the specification, then it is neither required nor
forbidden.  You get interoperation between a wide range of implementations
by only requiring implementations to do what is explicitly required,
and to have implementations rely only on things that are explicitly 
required.

Cheers,
Geoff

Roy wrote on 01/19/2005 08:07:10 PM:
> > I'll point to the long discussions we've had on this issue as evidence 

> > that

---

From: Elias Sinderson <[email-masked]>
Date: Wed, 19 Jan 2005 18:53:43 -0800

Geoffrey M Clemm wrote:

> I agree with Roy's rationale and conclusion, and support the  removal 
> of the reference to live properties in section 2.6

So, in effect, the spec will state that dead properties MUST be the same 
across all bindings to a given resource, and that (by remaining silent 
on the issue) live properties MAY vary depending on server 
implementation. I am not oposed to this, however as a guide to client 
implementors it might be nice to point out that they can't neccessarily 
depend on live properties being the same across all bindings to a resource.

Cheers,
Elias

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 19 Jan 2005 22:24:25 -0500

If there were a well-defined (and finite) number of such "guidances",
I could live with it (and it was on that basis that I reluctantly
agreed to adding the "guidance" text about locking).

But as soon as we agree to one such "guidance", a new one is suggested.
I despair of ever getting the BIND protocol published if it is delayed
until it has become a complete "implementation guide".

I noticed that yet another such request for "guidance text" has just been 
posted to the
bug database [bug 71].  I also note that nothing in the "bug" has to
do with any of the methods or properties defined by the binding 
specification,
but is about access control. 

I have nothing against asking for guidance from the mailing list,
but holding a specification hostage until all of your implementation
issues have been addressed by the mailing list seems a bit unreasonable. 

Cheers,
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 19 Jan 2005 22:34:07 -0500

And just to be clear (and to apologize for being a bit testy
in the message below :-), Elias was not the one posting requests
for implementation help ... his posts have all been very reasonable (:-).

Cheers,
Geoff

Geoff wrote on 01/19/2005 10:24:25 PM:
> I noticed that yet another such request for "guidance text" has just
> been posted to the 
specification,

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 19 Jan 2005 21:53:30 -0800

I agree with Elias -- I'm not insisting on any particular requirements, 
but I have definitely found that when the spec is entirely silent on an 
issue (particularly on an issue where implementations may vary and the 
variations can affect interoperability), readers unconsciously fill in 
with their assumptions.

Lisa

On Jan 19, 2005, at 6:53 PM, Elias Sinderson wrote:

> So, in effect, the spec will state that dead properties MUST be the 
> same across all bindings to a given resource, and that (by remaining 
> silent on the issue) live properties MAY vary depending on server 
> implementors it might be nice to point out that they can't 
> neccessarily depend on live properties being the same across all 
> bindings to a resource.
>
>
> Cheers,
> Elias
>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 20 Jan 2005 07:24:42 -0500

Joe:

Please add bugzilla "products" for "WebDAV-RFC 3253" and "WebDAV-RFC 3744"

Thanks,
Geoff

---

From: Brian Korver <[email-masked]>
Date: Thu, 20 Jan 2005 09:52:24 -0800

> neccessarily depend on live properties being the same across all 

I agree.  I believe this change would make the spec better, not worse.

-brian
[email-masked]

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 20 Jan 2005 17:08:22 -0800

I can support this language as well.

- Jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Korver
> Sent: Thursday, January 20, 2005 9:52 AM
> To: WebDAV WG
> Subject: Re: ETags?
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 Jan 2005 22:44:51 +0100

> by the server -- any requirement that they be consistent across

OK, re-opening issue "2.6_bindings_vs_properties": 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.6_bindings_vs_properties>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 Jan 2005 22:48:54 +0100

> issues have been addressed by the mailing list seems a bit unreasonable.  

For the record: I completely agree with that statement.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 Jan 2005 22:55:24 +0100

> depend on live properties being the same across all bindings to a resource.

I'm not happy with this text, as it sort-of *encourages* people to 
define live properties that way.

So *if* the spec makes a statement about dead properties, but *doesn't* 
make statement about live properties, that should be clear enough ("if 
the spec author's would have wanted to make a statement about live 
properties, they would have done it here").

Having the choice between two text versions that technically say the 
same, I'm voting for the shorter and simpler one.

Best regards, Julian

---

From: Elias Sinderson <[email-masked]>
Date: Fri, 21 Jan 2005 14:36:38 -0800

Julian Reschke wrote:

>> implementation. [...]

Just to be clear, I wasn't proposing any specific text, but merely 
observing that a note to client implementors would probably be useful. I 
agree that the use of MAY as above would likely encourage the definition 
of live properties that vary across bindings.

> So *if* the spec makes a statement about dead properties, but 
> *doesn't* make statement about live properties, that should be clear 
> enough ("if the spec author's would have wanted to make a statement 
> about live properties, they would have done it here").

Hmm, I can imagine client implementors having discussions about this. 
Including a single sentence which states that clients can't necessarily 
depend on live properties being the same on different bindings to a 
given resource.

> same, I'm voting for the shorter and simpler one.

I generally agree, however this seems to be a case in which a little 
guidance could prevent a lot of headaches since the question will 
undoubtedly arise. OTOH, it does run dangerously close to Geoffs' 
statement regarding such guidances... I certainly don't feel strongly 
enough about the issue to hold up the BIND spec.

Cheers,
Elias

---

From: Elias Sinderson <[email-masked]>
Date: Fri, 21 Jan 2005 14:44:21 -0800

Elias Sinderson wrote:

> [...] Including a single sentence which states that clients can't 
> necessarily depend on live properties being the same on different 
> bindings to a given resource.

... doesn't seem like an undue amount of verbiage in the spec.

Again,
Elias

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 21 Jan 2005 16:37:37 -0800

> ... doesn't seem like an undue amount of verbiage in the spec.

It does to me, and I guess an explanation is in order.  Let's
say that a given live property definition does specify that its
value must remain the same on different bindings to the same
resource.  In that case, the client can depend on them being
the same and that simple little addition creates an unnecessary
contradiction between what should have been orthogonal
specifications.  There is no reason for the binding specification
to make blanket statements when there are no conditions that hold
for all live properties -- that is why we have property definitions.

Developers don't need any more guidance here.  What they need are
shorter specifications so that they don't have to waste their time
digging through meaningless tripe just to understand the interface.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Jan 2005 20:32:43 +0100

> digging through meaningless tripe just to understand the interface.

Thanks for the explanation. I do agree that the statement as proprosed 
is not only unnecessary but actually harmful.

Best regards, Julian

---

From: Elias Sinderson <[email-masked]>
Date: Sat, 22 Jan 2005 19:38:02 -0800

Thanks Roy, that's an excellent point that I hadn't considered. For the 
record, I am no longer opposed to the spec remaining silent on the issue.

Cheers,
Elias
________________________________

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 23 Jan 2005 07:50:50 -0800

I wish it were so easy to write short, clear specifications that could 
be unambiguously understood and implemented.  I wish features could be 
orthogonal.

However, bindings together with existing WebDAV features, while mostly 
orthogonal, have a few interesting, confusing or important 
interactions.

This isn't an unlimited set of work, folks.  All these issues have been 
raised before this last call period (except maybe one?) and it isn't an 
ever growing set.  We're talking about maybe half a page of new text to 
clarify important interactions to implementors, and then we're done and 
we'll have a really good spec.

Lisa

On Jan 22, 2005, at 7:38 PM, Elias Sinderson wrote:

>
> Thanks Roy, that's an excellent point that I hadn't considered. For 
> the record, I am no longer opposed to the spec remaining silent on the 
> issue.
>
>
> Cheers,
> Elias

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Jan 2005 00:25:18 +0100

> be unambiguously understood and implemented.  I wish features could be 

Features *can* be orthogonal. Sometimes they aren't (in which case a 
spec needs to say something about it). The more orthogonal you make 
them, the simpler the specs and the interdependencies.

> orthogonal, have a few interesting, confusing or important interactions.
> 

At this point, unless you have a *specific* proposal for specification 
text, I don't really find this comment really helpful...

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 24 Jan 2005 11:59:32 -0500

I agree with Elias and Julian about the excellence of Roy's point,
and would point out that in my opinion, it applies to most/all
of the other requests for "guidance" in the binding spec for the
behavior of functionality defined in other specifications.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Jan 2005 10:12:27 +0100

> record, I am no longer opposed to the spec remaining silent on the issue.

Ok, for the record: as Roy has explained to us, the current language is 
actively incorrect and harmful, so the first step is to remove it.

I'm open to suggestions about anything else we can do. Note that these 
suggestions should be made in the form of actual specification text. If 
we can get a consensus about one proposal, I'll be happy to make that 
change.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Jan 2005 22:54:56 +0100

> we can get a consensus about one proposal, I'll be happy to make that 

OK, as I haven't heard anything new (in particular no concrete proposal 
for specification text) I'm closing the issue for now (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.6_bindings_vs_properties>).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 27 Jan 2005 15:58:32 -0800

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

Also, I propose additional language for ETags:

"The value of the 'getetag' property (and thus the value of the ETag  
for a resource at that point in time) MAY change when a new binding is  
added to a resource. However, the value MUST be the same for that  
resource independent of the path submitted to PROPFIND."

Lisa

On Jan 27, 2005, at 1:54 PM, Julian Reschke wrote:

>>> the record, I am no longer opposed to the spec remaining silent on  
>>> the issue.
>> Ok, for the record: as Roy has explained to us, the current language  
>> is actively incorrect and harmful, so the first step is to remove it.
>> I'm open to suggestions about anything else we can do. Note that  
>> these suggestions should be made in the form of actual specification  
>> text. If we can get a consensus about one proposal, I'll be happy to  
>> make that change.
>
> OK, as I haven't heard anything new (in particular no concrete  
> proposal for specification text) I'm closing the issue for now (see  
> <http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind- 
> latest.html#rfc.issue.2.6_bindings_vs_properties>).
>
> Best regards, Julian
>
> --

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 27 Jan 2005 17:14:52 -0800

> resource independent of the path submitted to PROPFIND."

Absolutely not.  It effectively forbids the use of etags that
contain such info as the URI used to access the entity.  ETags
are specific to representations, not an identifier for resources.

....Roy

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 27 Jan 2005 17:26:46 -0800

Ok, then

"The value of the 'getetag' property (and thus the value of the ETag 
for a resource at that point in time) MAY change when a new binding is 
added to a resource. Also, the value of the 'getetag' property MAY be 
different for a single resource depending on which binding path is 
submitted to the PROPFIND request.

Lisa

On Jan 27, 2005, at 5:14 PM, Roy T. Fielding wrote:

>> for a resource at that point in time) MAY change when a new binding 
>> is added to a resource. However, the value MUST be the same for that

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 27 Jan 2005 17:29:51 -0800

> submitted to the PROPFIND request.

No, the getetag property and the ETag value have no relation
whatsoever with the bindings specification or its methods,
and there is no reason whatsoever to add meaningless statements
to reiterate that fact.

....Roy

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 27 Jan 2005 17:35:04 -0800

Well as you can see Roy, we disagree.  I would have been fairly likely 
to implement a client that assumed that the ETag would be the same for 
all bindings to a resource, because the servers I've worked on and 
worked with happened to work that way.

Sometimes what an implementer knows can blind them to what could be.

Lisa

On Jan 27, 2005, at 5:29 PM, Roy T. Fielding wrote:

>> is added to a resource. Also, the value of the 'getetag' property MAY 
>> be different for a single resource depending on which binding path is

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 27 Jan 2005 21:16:17 -0500

I completely agree with Roy. 

If something needs to be clarified about the behavior of etags, 
post a bug against the spec which defines the behavior of etags
(which is not the binding specification).

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 27 Jan 2005 18:31:00 -0800

Yes, but as I explained in this email --
http://lists.w3.org/Archives/Public/w3c-dist-auth/2005JanMar/0065.html

-- the bindings draft introduces the possibility for client behavior 
which could be harmful to interoperability unless the way that ETags 
interact with bindings is defined.

Since bindings first introduces this possibility, that's our best 
choice for a document in which to resolve that potential 
interoperability problem.

Lisa

On Jan 27, 2005, at 6:16 PM, Geoffrey M Clemm wrote:

>>> is

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 27 Jan 2005 21:33:25 -0500

I do not believe that any amount of guidance in the specification
will solve the problem of an implementor that assumes that
implementations they are familiar with define the interoperable
semantics of a feature, rather than looking to see what the
appropriate RFC says.

The only effective solution for this problem is to teach those 
implementors
to actually base their implementation on the specification.  Since this
means they actually will have to read the specification, the best way for 
us to
support that solution is to keep the specification clear and avoid
any bloat resulting from extraneous text.  In fact, sprinkling
"guidance" through a variety of specifications just encourages such
implementors to not go to the defining specification, but rather to
just assume that they "got it" from the partial information provided
by some guidance they happened to run across. 

Cheers,
Geoff

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 27 Jan 2005 19:27:19 -0800

> interact with bindings is defined.

And has been explained in multiple responses, bindings does not
introduce such behavior -- it is present in any implementation
that allows such things as Alias configurations -- and there
is absolutely nothing that bindings can say about it that isn't
already in the definition of etag in RFC 2616.

> interoperability problem.

There is no interoperability problem.  You are imagining that there
might be an interoperability problem if the client developer makes
an egregious mistake in assuming the implementation behind the
interface defined by HTTP.  Quite frankly, that is not our problem.

....Roy

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 27 Jan 2005 22:27:54 -0500

I understand your position.  I just disagree with it, for the
reasons that I (and Roy and Julian) have explained in our email.

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 28 Jan 2005 07:32:24 -0800

Thanks for continuing with this, but I think there's still a slight 
misunderstanding somewhere.

Of course you are correct that any implementation that allows 
functionality like bindings under the cover can have multiple URLs to 
the same resource, and the BIND spec doesn't introduce that.  I 
understand that, and I can see how that would leave the situation 
materially unchanged (although I can't see how clarification would be 
harmful).

What the BIND spec does is it adds the ability for a client to detect 
unambiguously that two different URLs are bindings to the same 
resource.  BIND introduces the possibility that a client may behave 
differently with respect to two URLs when it knows that they map to the 
same resource.

So by implementing RFC2616 alone, a client clearly has no option other 
than to cache one ETag per URL (and per variant, version, etc).  Now by 
implementing BIND, a client might believe that it can deal more 
directly with the resource because we've now provided the client a way 
to identify the resource.

---

Apparently I need to address the issue of why some client might believe 
they can cache 1 ETag per resource.  Looking at RFC2518:
"However the If header is intended for use with any URI which 
represents state information, referred to as a state token, about a 
resource as well as ETags.".
   -- This implies that ETag is about a resource.

" Every state token or ETag is either current, and hence describes the 
state of a resource, or is not current, and does not describe the state 
of a resource. The boolean operation of matching a state token or ETag 
to the current state of a resource thus resolves to a true or false 
value."
  -- This declares that an ETag describes the state of a resource.

"The getetag property MUST be defined on any DAV compliant resource 
that returns the Etag header."
  -- As with much other text about properties in RFC2518, this clearly 
defines that the property relates to the resource.

Looking at RFC2616: "Entity tags are used for comparing two or more 
entities from the same requested resource."
  and "The entity tag MAY be used for comparison with other entities 
from the same resource."
  -- and with BIND, the client can now compare with entities from 
another binding to the same resource.

Conclusion: At least one reader finds from reading specification text 
that it implies that ETags are consistent for a resource across 
bindings.  While I would slightly prefer BIND to make my conclusion 
clear to readers (would make synchronization easier), I would find it 
acceptable if BIND made Roy's answer clear in the spec.  We just need 
to come down on it on one side or another, and put that in the spec.

Lisa