Re: Process on open RFC2518bis issues

On 1/11/06 1:17 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> Cullen Jennings wrote:
>> ...
>>> OK, let me point to two specific ones:
>>> 
>>> Bug 188 (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188>),
>>> agreed upon on 2005-12-07
>>> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188#c2>),
>>> proposed text is in
>>> http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html
>>> #r
>>> fc.issue.bz188>).
>> This was one of the ones I was thinking about that seemed to require changes
>> in many sections of the draft.
> 
> Three sections, basically. And the complete diff is available, it just
> needs to be applied.
> 
>> ...
>>> OK, again two examples:
>>> 
>>> - The question of putting new requirements on ETags never was mentioned
>>> in that original WGLC.
>> 
>> It's very clear that the meaning of strong and weak ETags and how to
>> implement them and what clients can rely on has been unclear to many, if not
>> all, people for a long time. I'm not trying to put new requirements on
>> ETags, I am trying to get ETags to a point where the WG agrees that
>> 1) they are useful for clients
>> 2) it is clear how clients can use them
>> 3) and it is clear enough what they need to do that servers will implement
>> them correctly
> 
> I think *that* summary makes a lot of sense. The problem is that this
> falls into the generic HTTP area. So adding non-normative text
> (appendix) explaining authoring scenarios may be a good idea, but
> forcing (!) servers to do things they potentially can't do won't work.
> In particular, requiring servers to do something where RFC2616 is silent
> about what it means is problematic, unless we can gather consensus for
> an RFC2616 erratum on the HTTP mailing list.
>

Here you are pointing out why a particular solution can't be done by this WG
- but that does not seem to be a requirement issues.

> 
>>> - 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. 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.

> 
>> 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.

> 
>> ...
>>> 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. However, if neither A or B have consensus, then we don't
>> have consensus. And if we don't have consensus, then we don't have consensus
>> regardless of if the previous RFC did A,B, something else, or nothing at
>> all.
> 
> Well, I *urge* people who want to make normative changes to RFC2518 and
> who can't get consensus for these changes to reconsider that change
> requirement, and to consider to stick with the original protocol.
> Otherwise it will indeed be hard to agree on a common document.
> 
>> ...
>>> I think I clearly disagree here. If half of the people thinks the
>>> original requirements (A) are just fine, and the other half wants to add
>>> new requirements (B), going for (B) creates a spec that half of the
>>> people aren't happy with and may not implement. Sticking with (A) on the
>>> other hand means that we can go on as before, and those in favor of (B)
>>> still have the freedom to come up with a way to describe (B), and let
>>> clients discover that. Yes, that's a profile. Yes, I'm aware that
>>> profiles should be avoided. But if the cost of not having the profíle is
>>> that half of the implementors will either not implement the spec, and
>>> implement it incorrectly (claiming compliance when they don't), that's
>>> not better.
>> 
>> Yes, and in that case you need to get consensus that going with A is the
>> best path. I'm not disagree with you about why you might use the above
>> argument in favor of A - that is fine, it is appropriate to make, and the WG
>> might agree or disagree. But in the end I have to try and figure out if we
>> have consensus for A, B, or no consensus. Lack of consensus for B will not
>> imply a consensus for A. Only consensus for A will imply a consensus for A.
> 
>  From a practical point of view, I think we need to ask implementors of
> RFC2518 if they're willing/able/planning to implement RFC2518bis. If we
> can't get positive feedback from those implementors who *are* still
> active (so I'll explicitly exclude the Microsoft IIS developers here
> :-), then I think we have a problem.

Definitely. In the end this is what counts. Similarly if people think that
2518bis is not an improvement on 2518, then we are pretty unlikely to have
consensus on it. 

> 
>>>>> Unless somebody can explain why it's likely that we can resolve these
>>>>> issues
>>>>> between now and the end of the month, I propose to stop the discussion for
>>>>> now
>>>>> (as far as it affects RFC2518bis),
>>>>> 
>>>> Back in December I asked the people on the conference calls if we were
>>>> going
>>>> to be able to come to consensus on these issues. No one could guarantee
>>>> anything but they all felt we could. Based on that, Ted decided to keep the
>>>> working group open beyond the 2005. I sincerely hope we can come to
>>>> consensus on these hard issues. However, I encourage people to come to
>>>> agreement on something we can all live with - if that happens to be the
>>>> same
>>>> as what is in 2518, fine, but the idea that "if we can't agree, we use what
>>>> is in 2518" is not how consensus works. Like all WG drafts,  we can't come
>>>> to some form of consensus, it won't move forward.
>>> Understood. 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 no grow the scope of the
>> work. 
> 
> And that's why I was basically asking for a Feature Freeze.
> 

I think that Feature Freeze really is you key point you were trying to get
at all along and I encourage that. I separate that from a process problem.

Received on Wednesday, 11 January 2006 10:10:28 UTC