RE: specification style; last call

As I just posted to the list, we've made our pitch for a rewrite at 
http://dev.w3.org/2006/waf/access-control/Overview-Declarative-20080116.
html

I do think there is a problem with the current spec because at least
myself and stuart find the current style of algorithm difficult to
understand.  We've done the right thing by putting pen to paper and made
a counter-proposal.

Cheers,
Dave

> -----Original Message-----
> From: public-appformats-request@w3.org 
> [mailto:public-appformats-request@w3.org] On Behalf Of Thomas Roessler
> Sent: Wednesday, January 16, 2008 8:35 AM
> To: public-appformats@w3.org
> Subject: specification style; last call
> 
> 
> Forwarding some material from the member-confidential list.  
> Note that the quoted text is from Anne and Art, both of whom 
> have agreed to it being public.
> --
> Thomas Roessler, W3C  <tlr@w3.org>
> 
> 
> 
> 
> ----- Forwarded message from Thomas Roessler <tlr@w3.org> -----
> 
> From: Thomas Roessler <tlr@w3.org>
> To: Arthur Barstow <art.barstow@nokia.com>
> Cc: ext Anne van Kesteren <annevk@opera.com>,
> 	ext Ian Hickson <ian@hixie.ch>,
> 	member-appformats WG <member-appformats@w3.org>,
> 	Doug Schepers <schepers@w3.org>
> Date: Sat, 12 Jan 2008 18:31:13 +0100
> Subject: Re: [waf] minutes from 9 January 2008 Voice Conf
> X-Spam-Level: 
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 
> On 2008-01-11 08:48:30 -0500, Arthur Barstow wrote:
> 
> >>> 1. GET / HEAD / OPTIONS - presumably, our requirements 
> will rationalize 
> >>> the design choices we made but I haven't seen the 
> requirements that do so
> 
> >> We have been over this a million times. We're constrained 
> by deployed 
> >> server software. If someone can demonstrate that this is 
> not an issue on, 
> >> e.g. DreamHost hosted sites, we will reconsider.
> 
> > Yes, questions about the spec's method choice have indeed 
> been discussed 
> > numerous times :-(.
> 
> > I'll repeat what I said at the VC regarding this topic since I
> > didn't scribe what I said -> I think it would be helpful if we
> > could point to a single place (e.g. wiki page, FAQ, design
> > constraints in the UC+Reqs doc, etc.) that describes the
> > rationale used to substantiate the current design e.g.  states
> > why HEAD and OPTIONS are not used, identifies the requirements
> > that justifies the current model, etc.
> 
> > Am I alone in thinking that given related questions are 
> repeatedly raised, 
> > that some documentation such as I describe above is 
> definitely needed?
> 
> In my view, a requirements document is the right place to put this
> documentation.  I'm indifferent whether the rationale for these
> kinds of decisions (when they are firmly made, that is) are put into
> the requirements document or into the specification proper.
> 
> >>> 3. Algorithms - we have ISSUE #11, Stuart Williams' 
> "intentional" comment 
> >>> and DO's related comment:
> 
> >>> 
> http://lists.w3.org/Archives/Public/public-appformats/2008Jan/
> 0092.html
> 
> >> There's no concrete proposal, the current text works, and I'm not 
> >> comfortable writing the variant myself. I don't think this 
> should delay 
> >> anything.
> 
> > Yeah, I understand your concerns; what do others think about this?
> 
> As a reminder, I believe there were relatively concrete proposals in
> January 2007 (writing this without the benefit of access to list
> archives).
> 
> Without having access to the current draft right now, I think
> something like this should be a fairly good starting point (leaving
> out the negation for the moment):
> 
> 	An access control rule set defines a set of origins.  An
> 	origin belongs to that set if it matches at least one allow
> 	clause without matching any of that allow clause's
> 	subordinate except clauses.
> 		
> 	An origin matches a clause if ...
> 	
> 	Implementations MUST NOT grant access if parsing of any of
> 	the clauses resulted in a syntax error.
> 
> > I agree we can't wait forever but OTOH if David and/or 
> Stuart were to 
> > propose something shortly (e.g. in a week or two), then it 
> may be worth a 
> > relatively short delay (given we started two years ago).
> 
> Take the above as a strawman, please.  It's easy enough to
> extrapolate from that.
> 
> >>>> Why have we not gone to LC and CR already? Can we please 
> stop running
> >>>> around in circles and move forwards?
> 
> >>> I think one of the reasons we're are starting to see the 
> same questions 
> >>> being asked again is because we haven't clearly documented the 
> >>> requirements and use cases.
> 
> >> That's not a reason to not go to Last Call in my opinion.
> 
> > Well I guess we disagree then on the interpretation of the 
> PD requirement I 
> > quoted above. Perhaps Mike or Doug can shed some light on 
> this process 
> > issue.
> 
> I think there's a sufficient number of open issues (in the form of
> repeated and [maybe notsurprisingly] similar questions from various
> quarters of the community) that going to LC would seem inappropriate.
> 
> Also note that the HTTP-related questions are still not dealt with
> properly.  Going to LC with a proposal that entails Overloading GET
> without having obtained useful review of that decision sounds rather
> unwise, too.
> 
> Regards,
> -- 
> Thomas Roessler, W3C  <tlr@w3.org>  +33-4-89063488
> 
> 
> 
> ----- End forwarded message -----
> 
>

Received on Wednesday, 16 January 2008 20:01:43 UTC