Re: [agenda] CT Call Tuesday 8 July 2008

Hi

There is a small chance that I won't make it on to the call tomorrow, 
and if I don't then I can only apologise.

I apologise also for the fact that there is no draft to review, as yet. 
I am currently working on it, flat out, or as flat out as having 
constantly to re-draft mobileOK Basic Tests allows. Those of you 
following the discussion on public-bpwg will know what I am referring 
to. Lots of songs come to mind.

That slight moan aside, I do appreciate that it's difficult for the 
group to make progress without a draft, and hence in effect I am the one 
standing in the doorway and blocking progress. I do aim to get a draft 
to you in the next few days.

Jo

On 07/07/2008 08:08, Francois Daoust wrote:
> 
> Hi CT TF!
> 
> I failed to send a summary of last week's discussion and further 
> thoughts on our remaining ISSUE-242. My apologies :-(
> 
> This week's agenda is again short in terms of topics. I don't expect 
> either that we'll take final resolutions on this right now.
> 
> 
> -----
> Chair: François
> Staff Contact: François
> Known regrets: none
> 
> Date: 2008-07-08T1400Z for 60mn
> Phone: +1.617.761.6200, +33.4.89.06.34.99, +44.117.370.6152
> Conference code: 2283 ("BCTF") followed by # key
> IRC channel: #bpwg on irc.w3.org, port 6665.
> 
> Latest draft:
> http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/CT/editors-drafts/Guidelines/080606 
> 
> 
> 
> 1. Allow-Disallow lists
> -----------------------
> - See minutes from last week:
> http://www.w3.org/2008/07/01-bpwg-minutes.html
> - See thread starting at:
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jun/0027.html
> 
> Possible choices:
> a/ leave mention of Allow/Disallow lists in the section on 
> administrative arrangements, and thus leave it out of scope of the 
> guidelines
> 
> I'm fine with that, but I just have the feeling that we can find a 
> reasonable solution to include them within the guidelines.
> 
> 
> b/ integrate Allow/Disallow lists in the 
> algorithm-that-is-not-to-be-an-algorithm for the treatment of HTTP 
> requests in 4.1.2. It would then be in scope.
> 
> The agreed (non-)algorithm for the treatment of the HTTP request states 
> (it may not be the final wording):
> "otherwise assess (by unspecified means) whether the 200 response is a 
> bogus one"
> 
> Allow/Disallow lists would naturally fit in "by unspecified means".
> Note that this would mean the scope of such lists is the assessment of 
> whether an HTTP response from the server is a "rejected" response or not.
> 
> In particular, it's not the same as having a list that says "for this 
> particular resource, do not take the Cache-Control: no-transform 
> directive into account and apply transformation".
> 
> 
> c/ do not mention Allow/Disallow lists at all.
> 
> If we have something such as "by unspecified means", we may as well not 
> mention Allow/Disallow lists at all.
> 
> My preference goes for b/ over a/ over c/
> 
> The note on intractability caused by such lists in current section 3.2.3 
> is:
> - relevant and carefully worded for some: it is impractical for a 
> content provider to register his site on many different operators.
> - irrelevant and far too strong for others: content providers already 
> have strong liaisons with mobile operators.
> 
> 
> 2. Persistent expression of user preferences
> --------------------------------------------
> See Jo's F2F points commented by Sean and me:
> http://lists.w3.org/Archives/Public/public-bpwg-ct/2008Jul/0002.html
> 
> 
> 3. AOB
> ------
> 
>

Received on Monday, 7 July 2008 13:51:42 UTC