TAG teleconference

10 Jan 2008


See also: IRC log


Stuart, Ht, DanC, Raman, jar, Norm, TimBL, Noah, Dave_Orchard, DOrchard




<scribe> Scribe: DanC


SKW: I see regrets TBL 24 Jan

close ACTION-76

<trackbot-ng> ACTION-76 Put a bow on the Nov TAG ftf meeing record with photos in TAG blog closed

close ACTION-28

<trackbot-ng> ACTION-28 draft a blog item for review and, pending creation of a TAG blog mechanism, post it. closed

-> http://www.w3.org/2001/tag/2007/12/13-minutes minutes 13 Dec

<Zakim> ht, you wanted to mention agenda link

HT: I added some links to http://www.w3.org/2001/tag/ ... to rolling agenda and FTF page

RESOLUTION: to approve minutes 13 Dec

Next Telcon: Propose 17th January 2008; Chair: Stuart; Scribe DaveO

Issue binaryXML-30 (ISSUE-30)

-> http://lists.w3.org/Archives/Public/www-tag/2007Dec/0094 Re: TAG input to EXI WG on Efficient XML Interchange and EXI Measurements [ White 20 Dec ]

HT: read it a while ago... my memory says the discussion is in a terminal state

<scribe> ACTION: ht review EXI WDs since 20 Dec [recorded in http://www.w3.org/2001/tag/2008/01/10-minutes#action01]

<trackbot-ng> Created ACTION-93 - Review EXI WDs since 20 Dec [on Henry S. Thompson - due 2008-01-17].

<ht> DanC, here are the links for my action way higher up: http://www.w3.org/TR/exi-primer, http://www.w3.org/TR/exi-best-practices

'ping' attribute

SKW summarizes HTML 5 ping attribute

DC: main use case is auditing advertisement links

<Norm> I'm moved by Roy's arguments against that it's a bad idea.

TVR: what I know is mostly what was summarized... as to opinion... feels like feature creep

DC: my understanding is that the link auditing is widely practiced, using opaque javascript stuff, and that this is more declarative, which might allow you to turn it off easier. so I can see some benefit to a ping attribute, but I probably wouldn't miss it if it went away

NM: I'm sympathetic to several of the points here... the declarative win... RF suggesting the use case hasn't been studied sufficiently[?]...

DanC: some, e.g. JR, object to doing POST on behalf of a user who just followed a link, which is widely understood to be a safe operation

("hyperlink auditing requires use of unsafe HTTP method" ISSUE-1 PINGPOST http://www.w3.org/html/wg/tracker/issues/1 )

TBL: use of POST is coherent in that GET might be cached and not update a counter.

(DanC is not convinced; it's not like the world comes to a halt if the counter doesn't get updated some small percentage of the time; the advertising industry will come up with estimates and norms to compensate.)

<ht> I think Tim's point is a good one, and more general than caching -- GET should be repeatable w/o serious consequence, but using GET for the ping attr value would seem to contradict that, particularly in the advertising logging case. . .

<timbl> I wonder what other things one get a user to do by making them ping a location as an attack

"When the ping attribute is present, user agents should clearly indicate to the user that following the hyperlink will also cause secondary requests to be sent in the background, possibly including listing the actual target URIs." -- http://www.w3.org/html/wg/html5/#hyperlink0

DO: I gather the design in the spec doesn't meet real-world advertising network requirements.

SKW reminds us that we re-opened issue whenToUseGet-7 for this issue. (ISSUE-7)

NDW: I also don't find any of the existing use cases compelling; I don't see why advertisers would stop using scripts that work for them

discussion of communication from the TAG to the HTML WG shows less than a critical mass just yet.

(issue 7 remains open)

DO: isn't there a requirements issue about this ping attribute?

DanC: I'm not sure... checking... no, it looks like not. (http://www.w3.org/html/wg/tracker/issues/open )

TVR: perhaps www-tag hasn't been invited to discuss this sufficiently

. ACTION: Noah invite discussion of HTML 5 ping attribute in www-tag after some review by tag members

<scribe> ACTION: Noah invite discussion of HTML 5 ping attribute in www-tag after some review by tag members. (html WG mailing list is public-html@w3.org ) [recorded in http://www.w3.org/2001/tag/2008/01/10-minutes#action02]

<trackbot-ng> Created ACTION-94 - Invite discussion of HTML 5 ping attribute in www-tag after some review by tag members. (html WG mailing list is public-html@w3.org ) [on Noah Mendelsohn - due 2008-01-17].

NM: OK, yes, I'll bcc public-html and note that I've done so in order to avoid cross-posting

<Noah> I will bcc: public-html, and note in the body of the email that I have done so.

Review of "Access Control for Cross-site Requests"

SKW: Dave and I have sent comments on our own behalf and gotten some responses from the editor...

DO: the WebApp WG was chartered Nov 2005; the access control deliverable has come up since then...
... the access control work started in [?another wg]. WebApp was originally chartered to work on XBL2 and the like...

<Stuart> s/?other wg/VoiceBrowser WG/ I think.

DO: the AC hasn't been notified, nor has any requirements document been produced.
... so a lot of the comments on the design are motivated by different implicit requirements
... there hasn't been a community requirements discussion
... it's a bit awkward to collaborate on this work, because it comes up just occasionally between weeks of discussion of XBL2 etc.
... my main comments: (1) the browser is effectively a policy enforcement point (PEP). Why? It seems to me that the PEP can be moved to the server side. cf work by Tyler

TimBL: oh really? how?

DO: let's not get into the details of that just now; Tyler has proposed a number of designs to meet the server-side-move requirement
... comment (2) specifying it with an algorithm is awkward; I'd rather see definitions that could be met by lots of algorithms
... comment (3) they've introduced an authorization request... a GET with a Method-check header [?]
... the access control spec is silent on the body of the reply to that request [?]. this seems architecturally problematic. [scribe missed some details... involving SOAP must-understand...]
... [something about HEAD and OPTIONS... ]

TBL: Dave, your point on social process around implicit requirements is well made
... re moving the PEP to the server side... I'm skeptical... my discussion with some mozilla developers convinced me that the browser has to enforce these policies in order to protect the user [?]

DO: much of this browser sandbox stuff is obscure; a colleague of mine at BEA is an expert in related security work but is struggling to get up to speed in this context

<Zakim> ht, you wanted to point to Jon Ferraiolo's comments which support DO

<ht> http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0108.html

TVR: [somebody else; darn; scribe forgot already] sent comments that support DO's position about obscurity of browser sandbox model

HT: I'm sympathetic to the difficulty of writing this access control spec while the browser sandbox model is obscure

<Zakim> Stuart, you wanted to comment a little on interations with WG

HT: where one would expect to write "change from X to Y" the spec has to say "change from whatever it is to Y"

SKW: the editor is quite responsive, but it's not clear to what extent the WG has considered our comments

noted, ht

<Zakim> DanC, you wanted to say that what I learned at the W3C security workshop is that the browser sandbox models are many and changing and obscure on purpose

<Zakim> Noah, you wanted to say that doing things declaratively is more than editorially

<timbl> There are comments about the way the WG has behaved, the way the document is written, and the protocol. These should be clearly separately articulated.

<jar> aren't we saying: a proper technical review requires an expression of the criteria against which to evaluate it - and this means comprehensive requirements and use cases? so tell us what you're trying to do, then we can review?

(as much as I don't like algorithms either, I haven't heard "more than editorial" substantiated.)

<ht> Here's an example of a more declarative approach to a similar spec. problem (allow/deny from apache2): http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html

<Zakim> Noah, you wanted to talk about role of TAG

<Noah> Fropm TAG charter:

<Noah> The mission of the TAG is stewardship of the Web architecture. There are three aspects to this mission:

<Noah> 1. to document and build consensus around principles of Web architecture and to interpret and clarify these principles when necessary;

<Noah> 2. to resolve issues involving general Web architecture brought to the TAG;

<Noah> 3. to help coordinate cross-technology architecture developments inside and outside W3C.

DO: while much of this is process/editorial, the choice of GET [as opposed to OPTIONs or HEAD] is technical and architectural

<Noah> I think that only marginally gives us special status to raise an issue like "the spec your workgroup is doing doesn't have clear requirements, and is more imperative than we think is wise in presenting certain logic"

(pointer to focussed comment?)

DanC: I see GET / HEAD / OPTIONS Anne van Kesteren (Friday, 4 January) http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0045.html
... interesting... "One of our requirements is that you can simply put a file on the server and have it work."

<dorchard> http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0092.html

DO: in 0092, see "HTTP Method for Authorization Request"

<Stuart> HTTP Method for Authorization Request

<Stuart> The specification uses HTTP GET for the Authorization Request, with the

<Stuart> Method-Check HTTP Request Header. This seems an inappropriate HTTP

<Stuart> Method because the resource identified by the URI is not being

<Stuart> dereferenced, rather the intent is to retrieve either Access-Control

<Stuart> headers or the <?Access-Control?> Processing Instructions. There aren't

<Stuart> clear requirements that indicate why other HTTP methods such as HEAD or

<Stuart> OPTIONS aren't used instead or in addition to. I think this is closed

<Stuart> issue #7, but I'm not sure.

DanC: in http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0052.html barstow refers to ISSUE-19; I'm struggling to turn ISSUE-19 into a full URI
... http://www.w3.org/2005/06/tracker/waf/issues/19

Summary of Action Items

[NEW] ACTION: ht review EXI WDs since 20 Dec [recorded in http://www.w3.org/2001/tag/2008/01/10-minutes#action01]
[NEW] ACTION: Noah invite discussion of HTML 5 ping attribute in www-tag after some review by tag members. (html WG mailing list is public-html@w3.org ) [recorded in http://www.w3.org/2001/tag/2008/01/10-minutes#action02]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2008/01/16 15:02:46 $