Re: ETags?

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:
> 
> On Jan 19, 2005, at 3:56 PM, Jim Whitehead wrote:
> > 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,
> 
> So what?  Let the reader beg the question. In a specification, lack
> of a requirement means there is no requirement.
> 
> > - 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,
> 
> How is it ambiguous?  Intentions here are irrelevant.
> 
> > - the additional language makes it clear that servers have this 
> > additional
> > 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.
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.