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 16:34:46 UTC