See also: IRC log
<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
-> 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
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
<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.
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