Re: Process on open RFC2518bis issues

Cullen wrote on 01/11/2006 05:10:36 AM:
> On 1/11/06 1:17 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> > Cullen Jennings wrote:

> >>> - The proposal to change the semantics for PROPPATCH (new issue 210,
> >>> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=210>) as far 
as
> >>> I can tell, even never have been raised *anywhere* until it suddenly
> >>> showed up in a recent draft -- and that's exactly the kind of change
> >>> discussion I'd like to avoid at this stage.

> >> Oddly, I view this as an example where I pretty happy with how things 
went.
> >> The editor of the document is writing down the details and considers 
the
> >> corner case where a client sent two contradictory statements in the 
same
> >> request (set X=1, set X=3), the editor decides to clarify this corner 
case

> > They are not contradictory. RFC2518 is clear about what it means
> > (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.2.p.3>):
> > 
> > "Instruction processing MUST occur in the order instructions are
> > received (i.e., from top to bottom). Instructions MUST either all be
> > executed or none executed."

> RFC2518 is clear about how to resolve this, but X=1 and X=3 are
> contradictory statements by any reasonable definition of contradictory.

No, they are not contradictory.  The user first set X=1, and then
set X=3.  It might be necessary to satisfy server constraints that
X first take on value 1 and then value 3 (for example, X cannot never
be increased by more than 2 by any particular request).  As Julian
says, RFC2518 makes it clear what a server must do in this case,
so it is not contradictory, undefined, or unclear.

> Now
> I'm not taking any position on we should allow this or should not, or
> reasons we may or may not want it. The WG can figure that out. But I 
will
> say that I don't think it was unreasonable for someone to think that we
> might want to say not to do this and propose text to say that. It's also 
not
> unreasonable to think that it was not be a big deal requiring 
significant
> discussion. This turned out to be wrong but it was not unreasonable,
> incompetent, or malicious.

I don't think anyone was suggesting this was malicious, but that at this
stage to make a normative change to the draft on a topic that has not even
been discussed on the mailing list wastes time that we don't have to 
waste.

> >> and puts in text suggesting that a client should not sent that. The 
draft
> >> gets published, some people read it and realize there may be reasons 
that a
> >> client does want to do that. Some quick discussion ensues and we 
decide how
> >> to resolve it. Presumably the editor will fix to reflect consensus on 
next
> >> draft.
> > 
> > I sure hope so, but the whole roundtrip could have been avoided.
> 
> I'm not sure how it could have been avoided - If the solution is that 
Lisa
> write some draft text and propose it to the email list to see if it is 
OK,
> well, that is isomorphic to what happened.

Finding an unannounced change to the draft text takes a lot more time than 

responding to an email message.

> >>> Yes. But if A and B are acceptable, and A was in RFC2518 and this is
> >>> what people have implemented, why move to B? I'd really like to
> >>> understand that.

> >> I think you are missing my point on this one - If A and B are 
acceptable,
> >> and A is what people have implemented, I'm sure the WG would come to
> >> consensus on A.

Not in the limited amount of time we have available to us, since many of 
the
implementors can only participate at infrequent intervals, and since the 
current
full-time participants do not have time to run every suggested normative 
change against all existing implementations.

> >>> So in this case, it would be nice if those who push for new
> >>> requirements for which there currently is no consensus is to 
re-consider
> >>> this.

> >> Yes, I agree. Perhaps I should say this in all caps or something but 
I
> >> really do agree - we need to be trying to shrink not grow the scope 
of the
> >> work. 

Julian was suggesting what I believe is the only effective approach to
resolving the last few blocking issues in the time available to us.
So I continue to support his proposal that in this final stage,
if there are any remaining proposed changes to RFC2518 that do
not have consensus, that they be dropped for consideration
for RFC2518bis (without further discussion). 

The reason I believe that what is in (or not in) RFC2518 should by default
be preferred over some suggested change to RFC2518 is that RFC2518
was the result of years of discussion and consensus-building by a very
active working group, and that without compelling evidence to the 
contrary,
it is reasonable to assume that implementors implemented what was in
RFC2518, and implemented in idiosyncratic ways anything that was not 
defined
by RFC2518.  So any change to RFC2518 (including the addition of 
constraints
that were not previously there) are likely to break at least some
implementations, and therefore any change to RFC2518 should by
default be rejected unless there is at least consensus amoung the current
group of active participants that the change is needed and is an 
improvement.

Cheers,
Geoff