Re: [Bug 12] Destination header "consistent"

I agree with Julian's points, and would add that there is significant
experience that shows that these "helpful hints" can end up being the
greatest source of implementation confusion.  A prime example is the
the suggestion that "MOVE" be thought of as a "COPY followed by a DELETE".
People confuse these hints with normative text, and then base their
implementations on these hints rather than on the normative text.
So it is not enough to say "would this text answer this particular 
question",
but also have to check "can this text be misinterpreted in a way that
conflicts with the normative text".  And if the spec is already very long,
each new paragraph introduces the chance that reader fatigue will prevent
them from ever getting to the normative text, because of the amount of
intervening non-normative text.

Cheers,
Geoff

Julian wrote on 10/27/2005 08:48:51 AM:

> 
> Cullen Jennings wrote:
> > ...
> > There is a fine line here. Someone skill in the art should be able to
> > correctly implement this by just reading the Spec and the documents it
> > normatively references. That does not mean we should right a basic 
tutorial
> > on how it all works or the sort of material that might be covered in 
WebDAV
> > book. It's a fine line to draw, but I tend to ask myself, if your 
average
> > implementer has a 20% chance of doing the wrong thing, you probably 
need
> > more advice or notes to keep them on the right path.
> 
> a) Yes, but...:
> 
> b) Even if it's not about RFC2518 itself, but a normatively referenced 
> spec? That is, do explanations/clarifications for HTTP belong into 
> RFC2518bis, or RFC2616bis?
> 
> > That is my somewhat philosophic answer, however, I have a far 
morepragmatic
> > thing you should keep in mind. The IESG has to read this, and if it 
makes no
> > sense to them, pain and suffering will ensue. This does not mean just 
the
> > apps ADs with an amazing background in the area has to read it, it 
means
> > that someone from a completely different area (say security) has to 
read it,
> > and understand it well enough to evaluate if it has significant 
issues. And
> > they are unlikely to read FAQs, Blogs etc because they are too busy.
> 
> Yes, and if information is *needed*, it should be in the spec.
> 
> On the other hand, we're revising a spec that already has been accepted 
> once. I would think it would make a lot of sense to keep changes to the 
> minimum needed to achieve our goals. As a matter of fact, RFC2518 has 
> had more contributors and reviewers than we can ever hope to find for 
> RFC2518bis, so my proposal is to avoid changes unless they clearly 
> enhance the spec.
> 
> > In the case you are taking about here, I have no idea what the right 
line is
> > and I'm not supporting Lisa's or Julian's or anyone else opinion on 
it. I'm
> > just pointing out that this is not black or white but is one of the 
many
> > things where the WG will have to find some sort of reasonable balance.
> 
> Back to this issue:
> 
> 1) I'm not aware of any interop problems.
> 
> 2) I'm not aware of anybody having asked about this.
> 
> 3) I don't see any benefit in RFC2518bis making statements about this, 
> even if we *did* agree on what to say.
> 
> Best regards, Julian
>