W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2005

Re: WG process (was Re: I-D ACTION:draft-ietf-webdav-quota-07.txt)

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Thu, 26 May 2005 13:07:36 -0700
Message-Id: <6b088eb1e34aaec745b5c8f29b34e29c@osafoundation.org>
Cc: "'webdav' WG" <w3c-dist-auth@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

> If you think that, you really should either bring them up (if new), or  
> follow-up on the discussions we had on the mailing list. Claiming that  
> there are open issues but not participating in discussing them doesn't  
> seem productive to me. See (for instance):  
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005AprJun/ 
> 0001.html>.

At this point I'm willing to consider the Bind/DeltaV interaction  
issues to be closed, but I'm not satisfied with the latitude given to  
servers to behave entirely differently with respect to access control  
and certain key properties (getlastmodified and getetag), because I can  
foresee serious interoperability problems and burdens for client  
implementors.  I can keep repeating myself about this, and sometimes do  
so, but I see little point to get into "Yes it is" "no it isn't" "yes  
it is" conversations. I tend to simply leave the last email from me as  
a record of my continuing position.

>> difficult hurdle may well be the lack of reviews and implementors.  If
> We've got at least two implementations. How many do we need to for  
> "Proposed"?

That's an excellent question and we may find that there are different  
answers.  For peer-to-peer protocol I'd say 3 implementations in the  
works, because that means that it's not enough to simply have a  
bilateral agreement between two implementors -- with three you really  
need consensus and eventually can test three pairings of  
implementations.  For client/server standards like ours, I'd say two  
clients and two servers would ideally be in progress by the time you  
ask for a Proposed Standard.  If there's only one server in progress  
then the whole standard will be geared toward the architecture that one  
server happens to have.  Similarly if there's only one client in  
progress then there's serious risk that the standard will only reflect  
one set of use cases and environmental assumptions.  If you have no  
clients in progress then the standard will have a serious bias to  
reflect the needs of server implementors.

I note also that it seems to be difficult to get client implementations  
underway before an RFC is available (yet other WGs seem to do that) so  
sometimes it would be appropriate to settle for somewhat less -- e.g.  
thorough review by experienced client implementors who have considered  
what it would take to build an implementation and have some plans to do  
so later.

>> we don't have the energy as a WG to finish that properly, it's my  
>> opinion that we could instead bring  BIND immediately to submission  
>> as an Informative RFC, where it would be an exemplary and  
>> high-quality example of that class.
> That would indeed be preferrable to doing nothing at all (although,  
> shouldn't it be "Experimental" instead???); however I personally think  
> that the BIND spec really should be submitted for publication as  
> "Proposed" (in contrast to REDIRECT which *currently* seems to only  
> have one implementation).

Sorry; you're right, Experimental would probably be better.  REDIRECT  
could also go to experimental immediately.

Received on Thursday, 26 May 2005 20:08:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:34 UTC