Subject: RE: ETags?

From: "Cox, Roger" <[email-masked]>
Date: Mon, 24 Jan 2005 09:32:03 -0800

As an implementor, I found 2518 to be an excellent specification. But
sometimes, even though the authors knew what they meant, I didn't know
what they meant. Any time the authors of a spec undergo any confusion or
disagreement about the meaning of their spec, or discover such confusion
among the readers of that spec, they've received a hint that the
specification is not as clear as they might have thought, and therefore
vulnerable to interoperability problems.
 
It seems to me that if the time and effort to clarify the meaning have
been spent, it is an enourmous waste not to make that clarification
available to potential implementors.
 
  -- Roger

	-----Original Message-----
	From: Geoffrey M Clemm [mailto:[email-masked]] 
	Sent: Monday, January 24, 2005 9:00 AM
	To: WebDAV WG
	Subject: Re: ETags?

	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 
	
	Elias wrote on 01/22/2005 10:38:02 PM:
	
	> 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.
	> ________________________________
	> 
	> Roy T. Fielding wrote:
	> 
	> >
	> > On Jan 21, 2005, at 2:44 PM, 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.
	> >
	> >
	> > 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: Geoffrey M Clemm <[email-masked]>
Date: Mon, 24 Jan 2005 12:53:04 -0500

If we were discussing clarifications of what the BINDING spec is
saying about features introduced by the BINDING specification,
I would completely agree with you that those clarifications should
be added to the BINDING specification.

The question is whether the binding specification should clarify
features defined in another specification (e.g., LOCK's, ACL's,
live properties, etc.).  In particular, if there are clarifications,
should they be inserted into whatever specification is currently
being published, or should they be placed on the clarification list
for the "bis" version of the specification in which the feature
being clarified is defined?

Cheers,
Geoff

"Cox, Roger" <[email-masked]> wrote on 01/24/2005 12:32:03 PM:

> As an implementor, I found 2518 to be an excellent specification. 
> But sometimes, even though the authors knew what they meant, I 
> didn't know what they meant. Any time the authors of a spec undergo 
> any confusion or disagreement about the meaning of their spec, or 
> discover such confusion among the readers of that spec, they've 
> received a hint that the specification is not as clear as they might
> have thought, and therefore vulnerable to interoperability problems.
> 
> It seems to me that if the time and effort to clarify the meaning 
> have been spent, it is an enourmous waste not to make that 
> clarification available to potential implementors.
> 
>   -- Roger

> 
> I agree with Elias and Julian about the excellence of Roy's point, 
> > 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.
> > >>> [...] Including a single sentence which states that clients can't 
> > >>> necessarily depend on live properties being the same on different 
> > >> ... 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
> > > the same and that simple little addition creates an unnecessary
> > > 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
> > >
> > 
> >